PlanDefinition Activity Scheduler

[vitorpamplona]

Is your feature request related to a problem? Please describe.

As part of the Clinical Reasoning Module, each action in a PlanDefinition can specify when and whether the action should take place. For when the action should be taken, the trigger element specifies the action should be taken in response to some trigger occurring (such as a particular point in a workflow being reached, or as the result of a prescription being ordered). For whether the action should be taken, the condition element can be used to provide an expression that evaluates to true or false to indicate the applicability of the action to the specific context. The $apply operation is used to apply a plan definition, and the parameters to apply are available as context to expressions within the plan definition, including the applicable condition and the dynamic value expressions.

The TriggerDefinition structure defines when a knowledge artifact is expected to be evaluated. The structure can represent three main kinds of triggering events, depending on the value of type:

• Named Event
• Scheduled Event
• Data Event

Scheduled Event

A recurring action can be set by ActivityDefinition.timing[x]. As an example, to specify that medication A has to be taken every morning, one would define an action once, and specify that it repeats every day using the Timing element. The SDK should automatically generate these CarePlans according to the element. Example:

"dosage": [
  {
    "text": "AUC 5 IV over 30 minutes",
    "timing": {
      "repeat": {
        "duration": 30,
        "durationUnit": "min"
      }
    },
    "route": {
      "text": "IV"
    }
  }
]

A complete ActivityDefinition:

{
  "resourceType": "ActivityDefinition",
  "id": "citalopramPrescription",
  "status": "draft",
  "kind": "MedicationRequest",
  "dosage": [
    {
      "text": "1 tablet oral 1 time daily",
      "timing": {
        "repeat": {
          "frequency": 1,
          "period": 1,
          "periodUnit": "d"
        }
      },
      "route": {
        "coding": [
          {
            "code": "26643006",
            "display": "Oral route (qualifier value)"
          }
        ],
        "text": "Oral route (qualifier value)"
      }
    }
  ]
}

Named Event

A named event is an event identified by the implementation environment. This allows any event generated within the implementation environment to be used as a trigger, but it requires pre-coordination of the names involved with the consuming environments. HL7 v2 events are assigned the URI http://terminology.hl7.org/CodeSystem/v2-0003#code e.g. http://terminology.hl7.org/CodeSystem/v2-0003/A01, and reference any data change that would trigger the sending of the matching HL7 v2 version, if the application providing the FHIR API supports v2 events internally. Here's an example:

"trigger": [
  {
    "type": "named-event",
    "name": "medication-prescribe"
  }
],
"condition": [
  {
    "kind": "applicability",
    "expression": {
      "description": "Patient has not had a urine screening in the past 12 months",
      "language": "text/cql",
      "expression": "No Screenings in Past Year"
    }
  }
],

Another example:

"trigger": [
  {
    "type": "named-event",
    "name": "patient-view"
  }
],
"condition": [
  {
    "kind": "applicability",
    "expression": {
      "language": "text/cql",
      "expression": "Is Patient Pregnant"
    }
  }
],

Data Event

And finally, a data event occurs in response to some data-related event in the integrated environment such as a record being added or updated. The data-of-interest for a data event is described using a DataRequirement. This allows for systems to automatically invoke based on data activity occurring within the system. A condition may also be specified to further refine the trigger

Possible event types are: data-changed, data-added, data-modified, data-removed, data-accessed, data-access-ended.

Example:

"trigger": [
  {
    "type": "data-added",
    "data": {
      "type": "Condition",
      "codeFilter": {
         "path": "code" 
         "valueSet": "urn:oid:2.16.840.1.113883.3.464.1003.111.12.1006"
      }
    }
  }
]

Describe the solution you'd like

1. Map and parse a Timing element into a WorkManager configuration upon creation/save of the object into the SDK.
2. Built a hook capacity for the SDK. Create, update and delete events in the SDK should trigger PlanDefinitions.$apply in certain cases.

Describe alternatives you've considered

Additional context
There might be other uses of the Timing element.

Would you like to work on the issue?
No.