FHIR Project - Design Discussion

Challenges

Let us discuss about the various challenges to solve in FHIR implementation design today

FHIR - Terms Paradigm mismatch

A FHIR resource CANNOT be directly mapped to a single term or entity in Meridian DAP always
A FHIR resource is actually a composition of data from multiple terms and entities from Meridian. Example, Observation resource contains lab data, Patient info, Performing person, Specimen info, Reference ranges, Terminologies, Value set
In FHIR world, the patient information, performing provider and specimen information are also referenced as Contained Resources / Resource Links with FHIR resource ID values. In addition to that, the coded systems and value sets need to represented as Codeable concepts in FHIR

Version History

We might have to maintain multiple versions of FHIR resource in our systems to track how the resource got changed over the period of time. we have to maintain the resource's last updated timestamp as well

Bundle

In the Initial phase, the Centralized FHIR service is going to request data for a collection of Patients referring their identifiers to our FHIR server. We will have to collect and group data for the patients and send them back as 'Bundle' - A Container for a collection of Resources. Example : List Bundle<OperationOutcome> - Each item will be Patient Resource
The time complexity will be exponential if we are going to iterate the cohort of patients and get the relevant data by aggregating terms from Meridian and do the Term to FHIR conversion (including the Resource links and Codeable concepts mapping) for each operation and then form the bundle response for sending back. we will be pay the price in terms of Performance badly

Search

Searching for resources is fundamental to the mechanics of FHIR. It is assumed that search operations traverse through an existing set of resources filtering by parameters supplied to the search operation. The FHIR clients send the search request to us assuming that we have the FHIR resources stored somewhere.

The search examples can be as follows

Example :
To search for all the procedures in a patient compartment that occurred over a 2-year period:

GET [base]/Patient/23/Procedure?date=ge2010-01-01&date=le2011-12-31

In Query string, '23' represents the Patient resource ID (Link needed to find the terms) and the date should fall in between 2010-01-01 and 2012-12-31.

If we don't have FHIR resources stored somewhere, we will have to parse the search query and understand the different conditions and then trigger calls with parsed data to meridian to gather results and then perform TERMS to FHIR resource conversions as always. This is huge in terms of computation load.

FHIR spec provides a huge list of parameters that need to be supported in search for each FHIR resource. There are other query types that are pattern based like 'Allergy.Condition.type' contains 'f*' and also based on resource types

GET [base]/?_type=Observation,Condition&other search params...

to restrict the search within the give resource types. If we don't have FHIR resources stored and organized by resource type, it will also need high computation

Create,Update & Delete

When any of our clients want to create a FHIR resource, we should store it somewhere physically. It should also trigger updates / creates to Meridian data as well. This scenario will create the data in two formats - FHIR data model and Terms model.
There should be a pipeline ON that always does data sync conversion from FHIR to Terms and vice-versa to keep things up to date. This data sync is very critical to rely for a single source of truth
When a FHIR client sends an update to a resource, we should fully update the entire FHIR data (because that is how it is being sent) instead of changing elements and increase the version. we can do this only we have stored the resource readily somewhere in database
When a client sends a delete request providing the resource identifier, we should be able to delete / deactivate the FHIR resource. This operation also needs storage of FHIR resources

FHIR Data formats

As per FHIR spec, the client can request for a FHIR resource in a format, they prefer. The formats can be

1) JSON

2) XML

3) Turtle (Trial use)

We have been considering that our FHIR server is going to support JSON data formats. How are we going to support XML based formats?

Summary

As per spec, the clients can request the FHIR server for just the summary information of resources

* There is a qualifier named 'isSummary' for every element in the FHIR resource. If the value of 'isSummary' is true, then it belongs to the summary information

The client request will be as follows

GET [base]/ValueSet?_summary=true

we have to return the resources only with elements that belong to summary

_elements

The clients can request for resources only with specified set of elements in it. In this case, we will have to return the FHIR resource having only the requested elements. For example,

GET [base]/Patient?_elements=identifier,active,link

We will have to return a Bundle of Resources having Patient resource with (identifier,active,link)

Use cases -SHIN-NY FHIR spec

• For a group of patients, get most recent specific Lab result (A1C, Lipid panel).
• For a group of patients, get the latest vital signs (Blood pressure is the primary example)
• For a group of patients, get the inpatient and emergency visits for a time frame (Can be used as a back up for alert notifications).
• For a group of patients, get list of outpatient visits following an Inpatient or Emergency Room visit.
• For a group of patients, get list of procedures for a time frame.
• For a group of patients, get a list of all MRN/Facilities for each patient.
• For a group of patients, get all associated allergies.
• For group of patients, get list of all documents or specific category of document.
• For a group of patients, get medications prescribed.

For Group of Patients

The selection criteria can be expressed in multiple different forms by FHIR clients. For example, use case 1 : For a group of patients, get most recent specific Lab result (A1C, Lipid panel).

The request will be like

GET /[base]/Observation?patient.gender=male&code=loinc|59261-8

examples :

GET [base]/Patient?given:contains=eve

GET [base]/Observation?value-quantity=5.4|http://unitsofmeasure.org|mg

GET Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN

GET [base]/Condition?_text=(bone OR liver) and metastases

Thoughts I have

Considering the various use cases involved in FHIR implementation, we should prefer storing all our information in a dedicated FHIR server database with all information and then provide services to FHIR clients in a faster manner without dependency on Meridian DAP. The Terms data from Meridian DAP should be ingested continuously into FHIR data storage. The FHIR server should directly apply criteria on top of FHIR data and return results.

Solely depending upon (Terms to FHIR conversion) to serve the FHIR clients wouldn't scale and lead to tight coupling issues.