Pathways on FHIR

Pathways on FHIR

This page serves as documentation of our approach to representing oncology clinical pathways with mCODE, using the Clinical Practice Guidelines Implementation Guide (CPG IG) and related FHIR Clinical Reasoning resources

Background

The fundamental goal of this project is to bring the mCODE data standard into the world of oncology clinical pathways. Camino is a mature prototype intended to demonstrate the art of the possible with mCODE - automatically reading a patient's record and applying a pathway to see what's already been completed, and highlight the next recommendation for action from the user. But Camino's data model is not a standard - it's a very simple JSON structure, inspired heavily by Synthea's generic modules, and designed purely to support the features of the prototype. In order to drive true interoperability we need to work within existing standards where possible.

FHIR Clinical Reasoning

The Clinical Reasoning module provides resources and operations to enable the representation, distribution, and evaluation of clinical knowledge artifacts such as clinical decision support rules, quality measures, public health indicators, order sets, and clinical protocols. In addition, the module describes how expression languages can be used throughout the specification to provide dynamic capabilities.

Clinical Reasoning involves the ability to represent and encode clinical knowledge in a very broad sense so that it can be integrated into clinical systems. This encoding may be as simple as controlling whether or not a particular section of an order set appears based on the conditions that a patient has, or it may be as complex as representing the care pathway for a patient with multiple conditions.

ref: http://www.hl7.org/fhir/clinicalreasoning-module.html

FHIR Clinical Reasoning provides the baseline resources that we will be using to represent pathways on FHIR, including but not limited to PlanDefinition, ActivityDefinition, and Library.

FHIR Clinical Guidelines IG

[The CPG IG] supports the development of standards-based computable representations of the content of clinical care guidelines. Its content pertains to technical aspects of digital guidelines implementation and is intended to be usable across multiple use cases across clinical domains as well as in the International Realm.

The CPG IG builds profiles on top of the Clinical Reasoning resources to ensure that clinical decision support artifacts are shareable, computable, and executable.

The IG's goals are:

• Direct:
  • Reduce duplicate development effort involved in the implementation of clinical practice guideline recommendations in clinical systems
  • Reduce unnecessary and/or unintentional variability in clinical practice guideline implementation
• Indirect:
  • Minimize the time needed to implement clinical practice guideline recommendations in clinical systems

By translating the recommendations in clinical practice guidelines at the source, and disseminating a computable version along with the narrative version of the guidelines, the effort of translation would not be repeated across every organization that intends to apply the recommendations. Likewise, unnecessary or unintentional variations as a result of duplicative translation efforts could be prevented with a standard, computable version that is ready to be implemented.

The CPG IG is currently under active development, but has contributors from leading organizations, most notably the CDC: http://build.fhir.org/ig/HL7/cqf-recommendations/index.html#acknowledgements

Note: the hierarchy of profiles within the CPG IG is Shareable < Computable < Publishable < Executable. We should generally aim to implement the highest level (i.e., Executable) whenever possible, unless there is a compelling reason not to.

Approach

We want to support two basic paradigms for pathway creation:

• Small, modularized pathways, which represent a single phase of "action" and can be linked together in various ways
• Large, longitudinal pathways, which represent an entire sequence of care, with branching options, for a certain kind of cancer

These can both be created using three basic concepts:

• "actions", where a clinical activity, such as a prescription, procedure, or chemo regimen may be requested
• "branches", where some aspect of the patient's demographics or their condition drives the path of care in one of multiple directions
• "references" to other pathways or pathway pieces

Because the FHIR resources depend on boolean-valued expressions as well as allow for more complex logic to drive dynamic values, there are multiple approaches that pathways could be represented using FHIR and CQL.
One extreme is to include all branching and evaluation logic within the CQL itself, and the FHIR only represents a single action of "do whatever the CQL says to do next". That's generally against the spirit of the CPG data model though, and probably not easy to maintain either. The ideal approach would logically split out the FHIR and CQL to leverage each one's strengths.

For a detailed approach on how to map the internal pathways data model to CPG see the Pathways on FHIR Mapping page.

Notes on CQF Ruler

cqf-ruler "is an implementation of FHIR's Clinical Reasoning Module and serves as a knowledge artifact repository and clinical decision support service." In practical terms, cqf-ruler is the only* FHIR server that will allow us to use the PlanDefinition$apply operation with a Patient and get back a CarePlan resource with appropriate actions.

( * = the IBM FHIR server may also support some of what we want to do based on this discussion and linked PR, but the docker image doesn't seem to work out of the box)

The implementation of the PlanDefinition$apply operation is here: https://github.com/DBCG/cqf-ruler/blob/master/r4/src/main/java/org/opencds/cqf/r4/providers/PlanDefinitionApplyProvider.java and the implementation of ActivityDefinition$apply, which PlanDefinition$apply calls for each action, is here: https://github.com/DBCG/cqf-ruler/blob/master/r4/src/main/java/org/opencds/cqf/r4/providers/ActivityDefinitionApplyProvider.java

The basic flow of PlanDefinition$apply is as follows:

• for each action in PlanDefinition:
  • if all "applicability" conditions with type "text/cql" in condition are met:
    • note it only appears to support CQL, not ELM
    • note that nested sub-actions are evaluated, presumably to for exceptions, but their applicability is not used anywhere, nor are nested sub-actions ever "applied"
    • find the referenced ActivityDefinition from definitionCanonical
      • note: the spec allows this to be a PlanDefinition, but only ActivityDefinitions are currently supported
    • call ActivityDefinition$apply:
      • note at this point the ActivityDefinition is completely standalone, it has no link back to the PlanDefinition
      • depending on kind, one of the following resource types will be populated:
        • ServiceRequest
          • requires code or dynamicValue
          • dosage and product not allowed
        • MedicationRequest
          • requires product
          • bodySite, code, and quantity not allowed
        • SupplyRequest
        • Procedure*
        • DiagnosticReport*
        • Communication*
        • CommunicationRequest
          • sets ActivityDefinition.code.text as CommunicationRequest.payload.content
        • ( * = not actually allowed by the spec? see https://www.hl7.org/fhir/activitydefinition-definitions.html#ActivityDefinition.kind)
        • note: the FHIR spec allows additional types, noted below, but the above are the only types supported in cqf-ruler
        • Appointment
        • AppointmentResponse
        • CarePlan
        • Claim
        • Contract
        • DeviceRequest
        • EnrollmentRequest
        • ImmunizationRecommendation
        • NutritionOrder
        • Task
        • VisionPrescription
      • apply any dynamicValues from the ActivityDefinition, if any, to the activity result
      • return the activity result
    • apply any dynamicValues from the PlanDefinition.action, if any, to the result
    • note it does not use any other fields on PlanDefinition.action, such as relatedAction, trigger, input/output, etc...

There is also a resolveCdsHooksPlanDefinition function, which is never actually directly called in the code that I can see, and it has the comment "For library use". At a glance it seems much more robust, including for example generating RequestGroups which the $apply version does not, and this comment on an issue in the repo confirms that: https://github.com/DBCG/cqf-ruler/issues/45#issuecomment-389242647