The regulators still publish laws and regulations as text. Just as it has been for thousands of years. Regulation as Code means a radical break with this practice.

Is it possible to translate laws into algorithms? Why did you want to do this? As a regulator, manufacturer, authority or notified body, how should you prepare for this?

This article provides answers.

1. Advantages of "Regulation as Code" a) Comprehensibility, clarity, unambiguity facts and legal consequences

A law is unambiguous when it is unmistakably clear to everyone what the facts and what the legal consequences are that the law describes.

What facts and legal consequences are

Many laws - lawyers usually speak of "legal norms" - consist of two parts: the facts and the legal consequences.

The facts formulate the "if". These are the criteria and requirements that must be met for the legal consequences to occur. These are the "then".

example

§ 1 BGB: "The legal capacity of man begins with the completion of birth." The legal consequence here is legal capacity. The fact is that it must be a human being whose birth is accomplished.

Consequences of unclear facts and legal consequences

Legal texts, especially the facts, are often not sufficiently precise, understandable and unambiguously formulated. Sometimes an incorrectly placed comma, sometimes a translation error, sometimes a missing definition means that the meaning of the sentence no longer corresponds to the goal of the legislator.

Countless publications testify to this lack of ambiguity, which they try to remedy. Examples of such publications are:

  • Scientific articles, e.g. B. in legal journals
  • Guidance (such as the MDCG and FDA Guidance Documents)
  • norms
  • court judgments

Regulatory specifications published as computer-readable algorithms would eliminate these ambiguities and ambiguities.

b) identifiability of requirements

A computer algorithm can be identified and referenced more clearly with a unique ID than is possible with legal texts:

References like the following would then be obsolete:

" MDR Annex XIV, Part A, Clause 1, Sub-item a), eighth indent, last clause ".

c) freedom from redundancy

The regulatory requirements overlap both with each other and within the individual requirement.

example

The requirements for risk management describe the MDR, the ISO 13485, the ISO 14971 and hundreds of other standards, all of which require the definition of acceptance criteria.

There are also redundancies within the individual regulations. ISO 13485, for example, requires the validation of computerized systems in three places in almost letter-identical texts.

These redundancies can be eliminated with "Regulation as Code".

d) Consistency, freedom from contradiction

Contradictions in legal requirements are not so easy to spot as long as they are published in text form. Unfortunately, these contradictions exist not only between the specifications from different legal areas, but also within the respective legal areas.

Logic breaks can be found, for example, in IEC 62304, in the documents of the Team NB and in the interpretations of state authorities.

Such contradictions can be uncovered and eliminated with formally testable algorithms.

e) completeness

Laws often do not claim to fully reflect the amount of facts. At least they often do not live up to this claim.

Gaps can be identified with "Regulation as Code".

f) Automatability The quality of regulations can be checked automatically

The ability to automate all of the quality aspects mentioned above (completeness, cons

...

To the original article