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.
