The IG and reference implementation were initially vetted against a Logica Sandbox preloaded with resources to trigger all possible recommendations. As we integrated the system into the OHSU Epic instance, we faced a number of challenges due to restrictions in the May 2021 version. This page summarizes those challenges and how the CQL was modified to address them.

Resource Summary

This is the summary of Incoming APIs to request when integrating this IG with an Epic instance and what the IG uses them for.

Epic Incoming API	Usage
Patient.Read (R4)	Basic demographics
Condition.Read (Encounter Diagnosis) (R4)	Examine conditions for a patient (e.g., look for preexisting hypertension diagnosis, recent adverse events, or exclusionary criteria such as end-stage renal disease).
Condition.Search (Encounter Diagnosis) (R4)	Find encounter diagnosis conditions for a patient.
Condition.Read (Problems) (R4)	Examine conditions for a patient (e.g., look for preexisting hypertension diagnosis, recent adverse events, or exclusionary criteria such as end-stage renal disease).
Condition.Search (Problems) (R4)	Find problem list item conditions for a patient.
Goal.Read (Patient) (R4)	Examine goals, looking for active Blood Pressure target.
Goal.Search (Patient) (R4)	Find all patient goals.
Observation.Read (Core Characteristics) (R4)	Examine observations found through search.
Observation.Search (Core Characteristics) (R4)	Search for observations providing a value set. This is used to find blood pressure and BMI observations.
Observation.Read (Social History) (R4)	Examine observations found through search.
Observation.Search (Social History) (R4)	Search for smoking observations using LOINC 72166-2.
Procedure.Read (R4)	Examine patient procedures for counseling related to drinking, smoking, and weight loss.
Procedure.Search (R4)	Search for all procedures for a patient.
Medication.Read (R4)	Get medication information referenced by MedicationRequest.
MedicationRequest.Read (R4)	Examine medication requests found in search, join with Medication, and determine if any are considered antihypertensive meds.
MedicationRequest.Search (R4)	Get medication requests for a patient.
Encounter.Read (R4)	This is not currently used, but may be helpful in the future for determining an onset date for encounter diagnosis conditions when none is provided. See discussion in Condition Search section below.

Condition Search

The decision support system searches for several conditions by code, to identify things like a Hypertension diagnosis or exclusion conditions such as end stage renal disease. Epic does not allow a search for conditions by code. A category must be provided, and the codes need to be post-filtered from the FHIR response. The IG searches the condition categories 'encounter-diagnosis' and 'problem-list-item' to try and identify active conditions. So the queries to Epic look like this:

/Condition?subject={{context.patientId}}&category='problem-list-item'
/Condition?subject={{context.patientId}}&category='encounter-diagnosis'

Unfortunately, Epic does not provide an onset date for encounter diagnosis conditions, nor is there any way to link to the encounter to retrieve the date there. In the absence of this information, it is assumed that all encounter-diagnosis conditions are active. Neither date nor clinical status are considered.

There is also a reported bug in Epic (QA note 6575473) with problem list conditions. The code system provided is the oid of the system rather than the url. So the condition code might look something like this where the SNOMED url is replaced by its oid:

...
"code": {
  "coding": [
    {
      "system": "urn:oid:2.16.840.1.113883.6.96",
      "code": "59621000",
      "display": "Hypertension"
    }
  ],
  "text": "Hypertension"
},...

The CQL has special processing to handle the oids for ICD-10 and SNOMED.

Distinguishing Home/Office/Ambulatory Blood Pressure Observations

The decision support system scores blood pressure observations based on how they were collected to ensure enough readings are present to make decisions. However, these types are not easily distinguishable in Epic. Patient entered Blood Pressure observations generally don't flow in Epic - the only exception being a video visit where the patient takes their own blood pressure and it is recorded by the physician. A nonstandard coding is used in the FHIR resource in this rare case. Ambulatory blood pressures would normally reference an Ambulatory Blood Pressure Monitoring Procedure, but Epic does not reference Procedures or Encounters from Observations. As a result, this implementation will simply treat all BP observations coming from Epic as "Office" observations.

Home observations can still be provided by the implementing application using the prefetch object during plan definition execution. To create a home observation use a MeasurementSettingExt extension and SNOMED code 264362003 as shown in this example. Please note that if you plan to send home blood pressure observations through the prefetch, you will need to send ALL blood pressure observations through, including any from the FHIR server. CQF Ruler will not query the FHIR server directly if it gets any Observations back from the prefetch.

Alcohol Use Observations

To make a determination about a patient's drinking habits, the implementation looks specifically for observations with the LOINC code 11287-0 and a value with unit drinks/day. This is not how alcohol consumption is tracked in OHSU's instance of Epic. We did attempt to map other comparable codes from the AUDIT-C questionnaire, but the Epic mappings were not consistent or fine-grained enough to make any judgments about whether the patient might need recommendations regarding alcohol use. The implementation does map a set of Alcohol Abuse conditions, so those may still trigger recommendations.

Determining if a Condition is Active

Originally, we used CQL borrowed from the FHIR Common file in the CQ Framework to determine whether a condition was active. In practice, we found many conditions falling through the cracks that a clinician would still deem current.

The original logic expected both a clinical status and verification status, but in practice these are not always present and not required by FHIR. Condition FHIR resources also don't require an onset and abatement date, and in our instance of Epic these are provided as dates with no timestamp information, causing additional issues with the original logic.

Ultimately, we modified the logic to use information from any fields that are present but to err on the side of including the condition if we didn't have enough information. For a condition of pregnancy, however, we made the choice to only consider a patient actively pregnant only if the condition onset was within the last 44 weeks. Active pregnancy excludes the patient from the intervention, so without this logic, many patients who'd been pregnant in the passed were not receiving recommendations.