Using the HL7 FHIR Standard for Clinical Variation Management

Healthcare data interoperability is a known challenge. The fragmented nature of data in the provider and payer domains adds complexity to an already challenging picture. Further compounding the problem are the varying database systems deployed within organizations that capture cost, billing, pharmacy, orders, labs etc.

With a handful of vendors dominating both EHR and billing systems, there is little incentive to interoperate and develop a common standard. To address this challenge, innovative healthcare pioneers  developed an open standard called FHIR (Fast Healthcare Interoperability Resources) to facilitate data sharing. The standard uses modern web technologies and opens the door for others to adopt and build on their work.

We quickly realized the potential of this standard to benefit our work and became an early adopter.

While advocates for FHIR, we encountered some limitations. As a result, Ayasdi has developed a FHIR “based” standard schema for its applications. This augmented approach underpins our award-winning clinical variation management application.

The standard FHIR elements are admitting diagnosis codes, encounter start, encounter end etc. They can be found in the specification here.

The areas that we needed to extend were around user-defined constructs such as direct cost, fixed cost, total cost or patient metadata (eg: BMI, risk scores, response variables etc.) The key is to make the addition of and mapping of these features simple and straightforward. By doing so, we facilitate the addition of these potentially valuable features, while simultaneously creating the flexibility to grow and expand down the road.

How exactly does Ayasdi use FHIR?

As part of the CVM application we typically follow a process of mapping customer data to the FHIR schema, followed by syntactic validation, transformation and platform load. The final step is semantic validation which is typically performed by a subject matter or domain expert.

Let’s consider a provider with an Epic medical record system. The EMR will have captured relevant encounters, interventions, and interactions with the patient. These elements will serve as the basis for our FHIR implementation.

For example, using the patient encounter data we can capture the start and stop time of encounter, the cost, length of stay and any other relevant outcome variable we choose. These are all individually mapped over to our FHIR schema to be used as the meta-data for analysis.

For the specific treatment path information, we can take medication, diagnostics, nutrition orders for example, and map over important columns, such as the class of medication (ie Analgesic, Antibiotic, Cardiac etc.) The classes could very well be ATC classes, NDC drug codes or any other system used by the provider. In addition, we typically we require the unique codes for each medication (eg oxycodone 5mg or cefazolin 2000 ML IV etc.) within a class. This process is repeated for each of the required FHIR resource files.


This mapping process is a one-time effort and can be leveraged for any type of episode, acute or non-acute. The data architect/analyst can create the necessary SQL queries and extracts to generate this data or they could choose to use an ETL tool accelerate this effort. Here is an example of sample worksheet an analyst would create to in order to populate the patient ENCOUNTER resource. The items in red are required, while all others are optional.

After all the files have been mapped, the extracts are validated against our schema. To do this validation we have built a simple utility called CARE-ETL. The utility takes the data, validates it, transforms it and loads it into the Ayasdi platform. We will take each one of these in turn.


The first step in validation is inherently visual. The screenshot below profiles each file, allowing the analyst to quickly identify any glaring issues, before running a detailed validation on the data.

This screenshot below shows a detailed resource by resource validation of the data files.


The transformation step is a critical component for analysis. When we think about multiple patients and their treatment paths, we need to consider how to align patients with each other. In order to do so, we must choose an “index” point which is selected during the ETL process. This index point could be the start of surgery, or the diagnosis of a condition, or the first admission to the hospital etc. After this choice is made, all patients pathways are calibrated to time zero as the index point.

The transformation step is also critical to finding windows of time for activity for each event category/class summary features are created. These summary elements are used by our core algorithms in the platform to create treatment groups and consensus carepaths.

Semantic Validation

The final step is a semantic validation step where the clinician or subject matter expert is involved to ensure the data is ready for analysis – this is done in the CVM application itself. Often we look a specific patient pathway to determine if it truly aligns with what the EMR records are telling us. In addition, we also examine if the mapping process successfully captured all our required elements.

Now the real fun begins as our unsupervised AI can find treatment groups to begin the discovery process!

In closing, we welcome the arrival of FHIR v4.0 and as we work with our customers we will consider augmenting the our schema as necessary to align with this latest version of FHIR. We continue to evangelize the need for our customers to become FHIR compliant as this will reduce (or maybe eliminate!) much of the fragmentation that is holding healthcare back from truly reducing costs and improving outcomes.