Skip to content

Pathways on FHIR Resources

Jump to bottom
blangley28 edited this page Sep 8, 2020 · 2 revisions

Pathways on FHIR Resources

Resources/Profiles

The central resource in all of this is the PlanDefinition, with ActivityDefinition, Library, and CarePlan resources also involved.

PlanDefinition

A plan definition is a pre-defined group of actions to be taken in particular circumstances, often including conditional elements, options, and other decision points.

In short, a PlanDefinition is a very generic resource type that allows for a lot of flexibility in what it represents. We will be using PlanDefinition as the foundation of our guidelines, in a few different ways.

The basic concept of a PlanDefinition is that it links together actions. An action is a single "step", which includes the specific "thing" to do as well as applicability statement that evaluates whether or not that "thing" is appropriate. Actions may represent sequential steps, as determined by action.relatedAction.relationship, or all actions may be concurrent if no links are provided. Actions can refer to specific activities which generate Request-type resources via an ActivityDefinition, or to other PlanDefinitions. Actions can also have nested sub-actions.

Profiles

CPGPublishablePlanDefinition

The "publishable" level profile for PlanDefinition, which is the minimal level we should aim for.

Required fields:

  • title, date
  • url, version, name, experimental, publisher, description
  • extension cpg-knowledgeCapability = shareable | computable | publishable | executable

Further profiles (below) build on this one, to define a "Pathway", a "Strategy", and a "Recommendation".

In short, a "Pathway" groups together "Strategies", and a "Strategy" groups together "Recommendations". One "Recommendation" would align with one or more actions and the direct preconditions for whether those actions were applicable. The "Strategy" would link together those recommendations sequentially, and then the "Pathway" would represent a comprehensive grouping of all strategies. For example, one might imagine a "Pathway" for Breast Cancer, a "Strategy" for "Neoadjuvant Therapy for HER2 Positive" (aligning with how we currently define a "pathway" within Camino), and a "Recommendation" for a chemotherapy regimen (aligns with a single action node or multiple sequential action nodes within Camino).

CPG-12-02

The most complete resource for explaining the relationship between the "Pathway", "Strategy", and "Recommendation" is at http://build.fhir.org/ig/HL7/cqf-recommendations/documentation-approach-12-03-cpg-plan.html

From conversations with Bryn Rhodes each BINV in the NCCN guidelines would map to a "Recommendation". Due to complexities in programmatically splitting "Strategy" into "Recommendation", the current approach is to map each pathway in the builder to a "Recommendation".

CPGPathwayDefinition

"A pathway provides groupings of strategies to provide a longitudinal view of the guideline"

Profile diff:

  • type =
  • each action:
    • definition[x] fixed to canonical(PlanDefinition), not ActivityDefinition. So a Pathway only groups together other PlanDefinitions, it doesn't define specific actions by itself
    • title, description, code required
    • some other fields disallowed: input, output, relatedAction, type, *Behavior, transform, dynamicValue
CPGStrategyDefinition

"Strategies are used to group recommendations together, typically focused on a particular condition or state within the overall guideline or pathway"

Profile diff:

  • type =
  • each action:
    • definition[x] fixed to canonical(PlanDefinition), not ActivityDefinition. So a Strategy also only groups together other PlanDefinitions, it doesn't define specific actions by itself
    • title, description, code required
    • some other fields disallowed: type, *Behavior (except selectionBehavior), transform, dynamicValue
CPGRecommendationDefinition

Profile diff:

  • type =
  • each action:
    • definition[x] fixed to canonical(ActivityDefinition), not PlanDefinition. So a Recommendation must be self-contained, and does not link to others (Any links to "subsequent" actions must be represented in a parent Strategy or Pathway definition)

Mapping Camino Pathways into Recommendations Screen Shot 2020-08-06 at 2 45 22 PM

Camino "transitions" map into PlanDefinition as well, as the "applicability"-type conditions on actions. This is where the CQL determining whether an action is appropriate will be placed.

image

$apply operation

The operation that makes the PlanDefinition useful is the $apply operation. This operation takes a PlanDefinition, a Patient, and optionally a few other fields as context, and evaluates the PlanDefinition against the Patient to return a CarePlan. (Note the CarePlan is only returned as the result of the operaition, not automatically saved to the Patient's record.) The resulting CarePlan will contain one single RequestGroup, with nested requests for applicable actions within the PlanDefinition.

The CPG IG does not constrain or affect the PlanDefinition$apply operation in any way. The core FHIR specification on the operation is here: https://www.hl7.org/fhir/plandefinition-operation-apply.html

ActivityDefinition

The ActivityDefinition resources represent the detailed definition of "actions" as described above. If an activity is determined to be applicable, then the fields will be used to populate a corresponding Request resource, such as a ServiceRequest or MedicationRequest.

ActivityDefinition maps fairly cleanly to the details within "Action Nodes" in Camino today.

Screen Shot 2020-08-06 at 2 43 44 PM

ActivityDefinition allows for a "statically" defined resource to be produced, using the code, product, and supporting fields to define a template for a resource of the right kind, but also allows for dynamic values and transformations, using the dynamicValue and transform fields. My recommendation is we stick to "static" resources for simplicity.

Profiles

CPGPublishableActivity

The IG also defines "kind"-based profiles for the specific types of requests that can be produced with an ActivityDefinition. The two key ones for us are for MedicationRequests and ServiceRequests, highlighted below.

CPGMedicationRequestActivity

Defines the minimum expectations and behavior for the definition of a medication request activity for use with content conforming to the CPG implementation guide

  • sets kind = "MedicationRequest"
  • sets profile = "http://hl7.org/fhir/uv/cpg/StructureDefinition/cpg-medicationrequest"
    • note: profile is 1..1, but there is no mCODE profile for MedicationRequest so this should be fine
  • sets intent = "proposal"
  • note: product[x] is not required (still 0..1) but we should expect to always include a productCodeableConcept with the appropriate RxNorm code here
CPGServiceRequestActivity

Defines the minimum expectations and behavior for the definition of a service request activity for use with content conforming to the CPG implementation guide

  • sets kind = "ServiceRequest"
  • sets profile = "http://hl7.org/fhir/uv/cpg/StructureDefinition/cpg-servicerequest"
    • note: profile is 1..1, but there is no mCODE profile for ServiceRequest so this should be fine
  • sets intent = "proposal"
  • note: code is not required (still 0..1) but we should expect to always include a procedure code with an appropriate SNOMED code here

TODO: how do we want to represent "start a chemo regimen"? or do we want to represent the chemo regimen directly within CPG? Technically we can continue to represent a chemo regimen as a CarePlan, as CarePlan is a supported "kind" within ActivityDefinition.

Library

The Library resource is referenced from PlanDefinition resources to include the executable logic that drives the plan.

Key fields:

  • content: Attachment - where the actual CQL containing expressions that drive the pathway will be contained, in base64.
    • note that content is cardinality 0..* so we can probably include both the CQL as well as the compiled ELM here

We should aim for CPGExecutableLibrary which expects:

  • title, type, and date
  • content to include
    • one attachment for CQL (i.e., the "computable" level)
    • one for ELM JSON or XML (i.e., the "executable" level)
  • extension cpg-knowledgeCapability = "executable"

CarePlan

The CarePlan resource is the result of applying a Patient resource against a PlanDefinition. According to the FHIR spec:

The result of [the PlanDefinition$apply] operation is a CarePlan resource with a single activity represented by a RequestGroup. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context.

(ref: https://www.hl7.org/fhir/operation-plandefinition-apply.html , at the bottom)

Note there is a profile CPGCarePlan however since we don't expect to generate the CarePlan ourselves, we'll use cqf-ruler or another library, the details of that profile are omitted here. Similarly there are profiles on other activities which will come out of the CarePlan: http://build.fhir.org/ig/HL7/cqf-recommendations/profiles.html#activity-profiles which we may have to review if we build a system that directly uses CPG pathways.

Note there are currently no profiles on RequestGroup.

Clone this wiki locally