Rules and the Library resources that contain their logic are provided in the eHealth Infrastructure through the Library Service. Once created as Library resources, they can be made part of the PlanDefinition/ActivityDefinition complex (defined as templates). The PlanDefinition/ActivityDefinition and Library complex becomes interesting when applied to particular Patient resources in the form of CarePlan/ServiceRequest resources. Library resources, whether of calculation or automated processing type, come into use immediately prior or after submission of measurement. Before delving into details on the life cycle of rules and Library resources, the described ways in which Library resources are involved have an impact on some ground rules described in the following.

Rule and Library Governance

• A Library resource (and the rule contained in it) is immutable. The only element allowed to change is the Library.status which can change from active to retired. Change to retired status does not affect how it is used and is solely to signify that the Library should no longer be used in future CarePlan/ServiceRequest.
• Multiple versions and revisions of a rule can co-exist, each in a Library resource of their own.

Creating and updating of Library resources is controlled through privileges and authorization based on ownership and co-author specified in Library.ehealth-modifier-role .

Preparing a New Rule/Library

A rule expresses clinical desired outcome(s) given input and a set of decisions.

1. Identify the organizational scope and individuals participating in the rule definition

2. Provide a definition of input, decisions and desired outcome expressed in the participants' own wording

   1. If answer(s) to a questionnaire is involved (as QuestionnaireResponse), provide the questionnaire definition.

   2. Hint: Provide a description that covers as many ‘what-ifs’ as possible (software developers/testers tend to uncover edge cases/additional what ifs)

3. State a point-of-contact that can elaborate and provide further decisions

4. Identify the organization(s) to be set as owner of the rule

Writing a Rule and Creating a Library

Rules are expressed as Drools Rules Language (DRL) described in DRL (Drools Rules Language) rules. The eHealth Infrastructure processing of rules has been tested with rule code expressed in Java.

Further context is available in DRL (Drools Rules Language) rules.

Writing DRL for a Calculation Type Library

package

Specify this as:

package rules

import

For a modern Integrated Development Environment (IDE), java imports are typically automatically generated or suggested.

global

The variable to hold output is defined as a global (see DRL Globals), for instance to return a Coding:

global org.hl7.fhir.dstu3.model.CodeableConcept ruleResult

The type specified must correspond to that defined as output type in Library.parameter.

function (optional)

A number of functions supporting the rule logic can be added. See examples in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/562692264/Example+Library+Resources#Automated-Processing-Type-Library-Resource-Examples .

rule

Specify the rule name as:

rule "name of rule"

A convention is to let this type of rule end in “CalculationRule”.

dialect

Specify this as:

dialect "java"

when

This part must correspond to a collection for each type defined as input type in Library.parameter. It can also contain variables that contain the first entry of such collection, for instance:

when
  $questionnaireResponses : Collection()
  $listQrs : ArrayList() from collect (QuestionnaireResponse() from $questionnaireResponses)
  qr : EHealthQuestionnaireResponse() from listQrs.get(0)

then

Here the main part of the rule is described.

Writing DRL for an Automated Processing Type Library

package

Specify this as:

package rules

import

For a modern Integrated Development Environment (IDE), java imports are typically automatically generated or suggested.

global

An automated processing type rule specifies a global (see DRL Globals) for the instructions governing what is created as:

global com.systematic.ehealth.automatedprocessing.AutomatedProcessingDTO ruleResult

function (optional)

A number of functions supporting the rule logic can be added. See examples in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/562692264/Example+Library+Resources#Automated-Processing-Type-Library-Resource-Examples .

rule

Specify the rule name as:

rule "name of rule"

dialect

Specify this as:

dialect "java"

when

See Establishing of Facts for the extra variables that can be established for a rule to be used for an automated processing type Library.

then

Here the main part of the rule is described.

Testing a Rule/Library

The rule logic can be tested in the “library” codebase repository. In the current test harness, the rule can be subjected to different input and assertions can be made against instructions (for automated processing type rule) and/or GuidanceResponse returned upon invoking the evaluate operation.

Deploying a Library for Use

Once adequately tested, a Library can be deployed to the eHealth Infrastructure. Currently this is performed by including the rule and creating the Library in the “kol-rules” codebase repository.

Modifying a Library

A Library (and its contained rule logic) cannot be modified. Instead, new versions and revisions of a Library can be created.

Decommissioning a Library

The Library can be slated for retirement by setting the Library.status to retired. As mentioned this signifies that future use should be prevented and does not affect current use of the Library neither in the PlanDefinition/ActivityDefinition complex nor in CarePlan/ServiceRequest. To immediately stop use of a Library, all ServiceRequest defined by ActivityDefinition referencing the Library must be de-activated and possibly replaced by new, active ServiceRequest.