O3 & CDS: A Way Forward for Implementing PlanDefinitions , ActivityDefinitions and CarePlans in OpenMRS with FHIR

Following the previous work on a Proof of Concept for the Implementation SMART Guidelines in OpenMRS , theres need to find an aproach for Implementing more Complex CDS rules beyond just creating Alerts and Reminders ie Patient Flags.

Existing Approach

Here is the current Simple Implementaion of CDS in OpenMRS

Currently , CarePlans are simply translated into Patient Flags by the PatientFlags Module which are displayed on the Patient Dashboard as Alerts and Reminders

Proposed Approach

Here is the proposed aproach to implementing more Complex CDS to support Creating Orders and Loading Clinical Forms based on FHIR PlanDefinitions , ActivityDefinitions and CarePlans

PlanDefinitions and Activity Definitions are loaded from the Knowledge base (SMART Guidelines )ie a published SMART FHIR IG and then processed by the decision Engine to generate FHIR CarePlans and Tasks.

The Tasks can then be consumed in OpenMRS to perfome the necesary activities like Drug Orders , Test Orders ,Loading o3 Forms .

Way Forward

  • Add Support for Processing ActivityDefinitions to the CQL module
  • Improving the Task API to support referencial integrity with OpenMRS Domain Objects and add support for querying Tasks with more Search params
  • Adding support for FHIR Questionares in the FHIR2 module to translate Quetionares to OpenMRS Forms

CC @ibacher @grace @janflowers @dkayiwa @caseynth2 @Intellisoft @UWash

3 Likes

Do you mind explaining a bit more how this is related to PlanDefinitions, ActivityDefinitions, and CarePlans?

One posible Scenario of SMART Guidelines would be to capture some specific patient information based on some conditions during Patient Care.
In FHIR spec, that would be a Questionare associated to a Task defined by the ActvityDefinition

We will need to consume the Task in OpenMRS and be able to translate the Questionare to a clinical form and load the form in order for the clinician to Capture the required information as part of the defined Guidelines.

In the above proposed aproach , a Task can either be based on a ServiceRequest , a MedicationRequest or a Questionare

Thanks @mozzy for the great post! I have a few detailed notes on it and thoughts.

First, CarePlans, i.e., a resource that describes planned actions to be taken for a specific patient related to their care in a specific clinic, program, etc. are the Archimedean point of the whole FHIR-CDS ecosystem. PlanDefinitions describe the overall structure of a possible CarePlan while ActivityDefinitions provide a way of giving structured inputs to the “activities” in that plan. Concretely, for example, a PlanDefinition describes one or more “actions” that can be applied, these then become planned activities in the CarePlan. ActivityDefinitions can be used to populate those planned activities with other FHIR resources, i.e., MedicationRequests for any recommended drug orders or ServiceRequests for other kinds of orders, CommunicationRequests to include draft guidance either to the clinician or someone else.

You might note, though, that nothing I said was about “Task”. This is because “Task” is best viewed as a limited resource. A Task is a mechanism for connecting one or more resources to a process that is in a specific state. In other words, its basically a workflow-tracking component. The potential feature in OpenMRS that we’ve been calling “task lists” are not actually best represented as FHIR Task resources, but as activities with an active CarePlan.

I’d also like to separate out Questionnaires from this whole thing. While Questionnaires are a semi-important part of how SMART Guidelines are delivered as IGs, I don’t know that they are straight-forward to adopt, for the same reasons that “standardized forms” are really hard to adopt; different clinics, MOHs, etc. will have different requirements (and the vision of SMART Guidelines has always included some degree of country-specific adaptation). (There are more technical issue where I don’t think that there’s a realistic way to actually convert Questionnaires into OpenMRS Forms; inter alia, there’s no direct way to transform, e.g., any form behaviours—like hiding specific fields for specific conditions—from the languages the Questionnaire is likely to use—CQL and FHIRPath—to anything the form engine would understand; it’s also not clear how this fits specifically into CDS, since that’s generally driven by triggers, which may be forms but may be other events).

Finally, as a policy note, its important to understand the role of the FHIR2 module. The FHIR2 module provides an extensible FHIR layer for OpenMRS and resources representing core OpenMRS types. It should only be used to implement resources that are representable by OpenMRS-core. Anything else can be added via an extension module. In particular, especially given the experience with the disaster that is the Task resource, I would prefer that we do not try to add custom tables or support for custom models. Instead, we should, similar to the work done with MedicationDispense, work to create OpenMRS-specific models that handle the parts of the FHIR specification that we want to implement and then add a conversion API. None of this work, though, needs to or should be done in the FHIR2 module. Instead, we might have a openmrs-module-careplan or openmrs-module-fhircareplan to implement the necessary resources.

3 Likes

What are the next steps in this piece of work? Is it actively moving forward this next quarter?