Managing and Using Library Rules
Managing Library Rules
For guidance in Library Rule management and governance, please consult Rule and Library Management.
Library Rule Evaluation in Automated Processing in the Infrastructure
For further details and to assist in understanding intended use and capabilities, please consult Example Library Resources.
Input
The Library.parameter
element specifies what resources are to be made available to the Library’s rule execution as input and what is returned as output. Typically, a measurement resource - be that an Observation, QuestionnaireResponse, or Media - is provided as input as part of the evaluate
operation.
It is possible to state further input for both calculation-type Library (where Library.type
is logic-library
) and automated processing-type Library (where Library.type
is automated-processing
). For the calculation-type, all input resources must be provided as part of the evaluate
operation.
For automated processing type, the following can be specified as input but are not provided as they are resolved by the Library service as part of establishing facts:
Resource Type | Description |
---|---|
Patient | The patient for which the measurement was applied. |
EpisodeOfCare | EpisodeOfCare to which the measurement is related. |
CarePlan | CarePlan to which the measurement is related. |
ServiceRequest | ServiceRequest referred from measurement (Observation|QuestionnaireResponse|Media) |
PlanDefinition | PlanDefinition to which the measurement is related. |
ActivityDefinition | ActivityDefinition to which the measurement is related. |
Questionnaire | Questionnaire to which a measurement of type QuestionnaireResponse is a response to. |
Establishing of Facts
If specified as an input parameter, the following resources are fetched and made available to an automated processing type Library rule by the Library service. In the rule, the resources can be accessed by adding the variable declaration to the when
part.
Resource Type | Resolved As | Variable Declaration |
---|---|---|
Patient | Fetched as Patient referenced in |
|
EpisodeOfCare | Fetched as EpisodeOfCare referenced in |
|
CarePlan | Fetched as CarePlan where |
|
ServiceRequest | Fetched as ServiceRequest referenced in |
|
PlanDefinition | Fetched as PlanDefinition referenced in |
|
ActivityDefinition | Fetched as ActivityDefinition referenced in |
|
Questionnaire | Fetched as Questionnaire referenced in |
|
Execution of Rule and Output
For automated processing rules, there is a structure, AutomatedProcessingDTO
, which lets the rule control aspects of the outcome of evaluating the rule. By adding to the structure, the rule controls if and in what number of ClinicalImpression, Task, and Communication resources are created. A special case is the property activateSelfTreatment which controls whether a check on certain ServiceRequest resources should be made, possibly leading to an update of the status of eligible ServiceRequest resources (see further details in Activation of suspended Self-treatment type ServiceRequest ).
AutomatedProcessingDTO
Property | Type | Description |
---|---|---|
ClinicalImpressions | List of | Each entry is an instruction to create a resource, and each entry specifies certain details. |
Tasks | List of | Each entry is an instruction to create a resource, and each entry specifies certain details. |
activateSelfTreatment | boolean | Set to true instructs that sibling ServiceRequests of self-treatment kind should be activated if currently suspended. |
ClinicalImpressionDTO
Property | Type | Description |
---|---|---|
Code |
| Used for |
Description | String | Used for |
CodeableConceptFindings | List of | Used for |
ObservationFindings | List of | Used for |
Tasks | List of | Each entry is an instruction to create a Task resource, and each entry specifies certain details. Each created Task refers to the ClinicalImpression through |
FindingBasis | List of | Used for |
TaskDTO
Property | Type | Description |
---|---|---|
Category |
| Used for |
Description | String | Used for |
Priority | String | Used for It must be ensured that the priority is entered in lower-case as defined for |
RestrictionCategories | List of | Used for |
Communications | List of | Each entry is an instruction to create a Communication resource, and each entry specifies certain details. By default, the |
QuestionnaireResponseFindingBasisDTO
Property | Type | Description |
---|---|---|
LinkId | String | Used for |
Finding |
| Used for |
ValueString | String | One of the value elements is populated and used for |
ValueDecimal | Double | |
ValueInteger | Integer | |
ValueBoolean | Boolean | |
ValueCoding |
| |
AnswerSignificance |
| Used for |
AnswerSignificanceDTO
Property | Type | Description |
---|---|---|
Significance |
| Used for |
AnswerConditions | List of | Used for Must be a list of size 1 or 2. |
AnswerConditionDTO
Property | Type | Description |
---|---|---|
Operator | String | Used for |
ValueString | String | One of the value elements is populated and used for |
ValueDecimal | Double | |
ValueInteger | Integer | |
ValueBoolean | Boolean | |
ValueCoding |
|
CommunicationDTO
Property | Type | Description |
---|---|---|
Categories | List of | Used for |
Text | String | Used for |
RestrictionCategories | List of | Used for |
CodingDTO
Property | Type | Description |
---|---|---|
system | String | Corresponds to |
code | String | Corresponds to |
display | String | Corresponds to |
It is the responsibility of the rule writer to ensure that a CodingDTO reflects a valid concept in a CodeSystem existing in the eHealth infrastructure and that the concept is part of the expanded ValueSet for which there is a binding to the particular resource element where it is used.
ObservationDTO
Property | Type | Description |
---|---|---|
Status | String | Used for |
Code |
| Used for |
ValueString | String | One of the value elements is populated and used for |
ValueBoolean | Boolean | |
ValueQuantity |
|
Output from automated processing
For each automated processing type Library evaluated, the returned GuidanceResponse typically contains an AutomatedProcessingDTO
with instructions for further processing.
The handling is shown in the sequence diagram Automated Processing of Measurements - Handling.
Resources created
When populated by the Library in the AutomatedProcessingDTO
, it results in the following resources being created. Please note that Communication resources described below are subjected to the handling described in Taking applicable CommunicationRequest into account, which further influences the number of Communication resources created and their recipient.
For every ClinicalImpressionDTO
in AutomatedProcessingDTO.ClinicalImpressions
:
Resource | Element | Value |
---|---|---|
ClinicalImpression | code |
|
| status |
|
| description |
|
| investigation.code | Coding with:
|
| investigation.item | One version-less reference to the measurement, one versioned referenced to the measurement |
| finding.itemCodeableConcept | Coding added for each |
| finding.itemReference | For each
|
| date | current date/time |
| subject | Same as |
| episodeOfCare | Same as |
| effective | Same as measurement effective (which is |
| ehealth-clinicalimpression-decisionContext | A reference to a contained Parameters with:
|
| ehealth-questionnaireresponse-finding-basis | For each
|
For every | ||
Task | ehealth-task-responsible | List of CareTeam from the CarePlan |
| ehealth-restriction-category |
|
| category |
|
| status |
|
| intent |
|
| priority |
|
| description |
|
| focus | The ClinicalImpression created for the current |
| episodeOfCare | Same as |
| authoredOn | current date/time |
For every | ||
Communication (of profile ehealth-message) | category | Coding for |
| status |
|
| reasonCode | Coding for each |
| payload.content |
|
| ehealth-title |
|
| ehealth-restriction-category | Coding for each |
| subject | Same as GuidanceResponse (and CarePlan) |
| episodeOfCare | Same as GuidanceResponse (and CarePlan) |
| topic | Reference to Task created for current |
| sent | current date/time |
For every TaskDTO
in AutomatedProcessingDTO.Tasks
:
Resource | Element | Value |
---|---|---|
Task | ehealth-task-responsible | List of CareTeam from the CarePlan |
| ehealth-restriction-category |
|
| category |
|
| status |
|
| intent |
|
| priority |
|
| description |
|
| focus | Reference to the measurement |
| episodeOfCare | Same as |
| authoredOn | current date/time |
For every | ||
Communication (of profile ehealth-message) | category | Coding for |
| status |
|
| reasonCode | Coding for each |
| payload.content |
|
| ehealth-title |
|
| ehealth-restriction-category | Coding for each |
| subject | Same as GuidanceResponse (and CarePlan) |
| episodeOfCare | Same as GuidanceResponse (and CarePlan) |
| topic | Reference to Task created for current |
| sent | current date/time |
Taking applicable CommunicationRequest into account
When Communication resources (of ehealth-message profile) are created by automated processing, the intended receivers would typically be one or more CareTeam designated as CarePlan.careTeam
on the involved CarePlan. As Communication can have at most a single CareTeam as the recipient (through Communication.ehealth-communication-recipientCareTeam
), this involves duplication of the original Communication where the duplicates vary by the recipient.
The recipient(s) and duplication made for Communication created by automated processing are influenced by CommunicationRequest. By creating appropriately crafted CommunicationRequest, a Practitioner can control whether:
to suppress automated processing’s default creation of a Communication for a particular CareTeam
to duplicate Communication with the Patient as the recipient
The handling is shown in the sequence diagram Automated Processing of Measurements - Create Communications.
See Controlling Creation of Messages on what values to use when creating CommunicationRequest.
Activation of suspended Self-treatment type ServiceRequest
When the AutomatedProcessingDTO
specifies activation through the element activateSelfTreatment
set to true, automated processing performs a lookup for all sibling ServiceRequest resources which have:
ServiceRequest.status
set tosuspended
ServiceRequest.definition
referencing an ActivityDefinition whereActivityDefinition.topic
has valueself-treatment
.
The sibling ServiceRequest resources are those referenced fromCarePlan.activity.reference
for the same CarePlan that references the ServiceRequest referenced from the measurement (be that Observation, QuestionnaireResponse or Media).
For those ServiceRequest meeting the criteria above, the ServiceRequest.status
is updated to active
.