-
Notifications
You must be signed in to change notification settings - Fork 1
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
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.
(Put a brief summary of the CPG IG and FHIR clinical reasoning module here. Copious links encouraged)
Note: the hierarchy of profiles within the CPG IG is Shareable < Computable < Shareable < Executable. We should always aim to implement the highest level (i.e., Executable) whenever possible, unless there is a compelling reason not to.
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 for a patient's cancer
These can both be created using two 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 or their condition drives the path of care in one of multiple directions
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.
The central resource in all of this is the PlanDefinition, with ActivityDefinition, Library, and CarePlan resources also involved.
| Name | Description |
|---|---|
CPGPublishablePathwayDefinition |
... |
CPGPathwayDefinition |
... |
CPGStrategyDefinition |
... |
CPGRecommendationDefinition |
... |
The ActivityDefinition resources represent the detailed definition of "actions" as described above. If an activity is determined to be applicable, then the code and/or product[x] fields will be used to populate a corresponding Request resource.
The CarePlan resource is the result of applying a Patient resource against a PlanDefinition.