FHIR a Strategic Initiative for Healthcare Providers to build Clinical Data Repositories

Today’s Hospitals are collecting vast  amounts of data from their day to day operations on Patients like Clinical Observations, Conditions, Encounters, Medication, Pharmacy, Imaging including vital signs using sensors to support both Operational and Research requirements. They are also looking at ways and means to map their internal data with external data which conform to some standards for ease of mapping and contextualize the data.

However the major problem they face is in their inability to combine the data from multitude of silos created by different applications for any meaningful and well-rounded analysis either for research perspective or to support any policy decision making or provide better and cost effective analysis to improve Patient care.

Many major hospitals have built healthcare data storage repositories in their native format with metadata tags to identify the context of the data what they call Data lakes which can be queried and extracted based on questions they wish to answer.

The success and utilization of these Data lakes depends upon how lighter they have been designed and built in comparison to dark data silos and to minimize its inherent drawback limitations to address questions such as; how the data was brought in; how and where it can be found; how to explore; and what and how it needs to be transformed to be of use. This task of identifying, preparing, combining several data sets from different hierarchical depths is equally challenging for a NON-IT-STAFF members like Researcher and Business users if not equally easy for the IT folks without Health Domain knowledge.

What and How FHIR (FAST Healthcare Interoperability Resource) an Open Industry Standard from HL7 comes handy to elevate such and many other bottlenecks?

HL7 a Non Profit Organization accredited in building Healthcare Standards, introduced FHIR (pronounced as “FIRE”) www.hl7.org/fhir/ . 

Healthcare providers have been using various HL7 Open Standards for Exchange of Information in the past since 1987 like HL7 V1, V2, V3, CDA, CCDA. FHIR Framework standards were written to address various pitfalls of their earlier specifications and standards and also keeping in view advances in IT technologies that can be leveraged for its effective implementation.

FHIR is the new Open standard getting lot of traction in the Healthcare Industry that has defined more than 180 Granular and Normalized Entities with attributes with defined formats. These “Containerized” entities are called Resources and in NoSQL World called Collections and its rows as Documents. FHIR also provides RESTful API protocols for exchanging of information between legacy healthcare systems and for integrating with different application systems. 

The common data format standard used in FHIR are XML and JSON. The concept 80/20 rule is applied when Industry identified these distinct resources in the current draft of HL7 Version 3.x from value proposition to mean 80% of the Clinical data needs can be accomplished using 20% of the Resources identified by the Industry.

These FHIR Resources are grouped under various heads such as Individuals (Patient, Practitioner, Person, Group), Diagnostic (Observation, Specimen, ImagingStudy), Medications (Medication, Immunzation, MedicationRequest),  Care Provision (CarePlan, ReferralRequest, RiskAssessment), Management (Encounter, EpisodeOfCare), Workflow(Appointment, Schedule, Task) for Clinical data sets and many more to support Financial Domain Coverages like Billing, Payment and various Specialized Health Research domains.

FHIR Specifications and Standards are exhaustive and detailed and provides standards how Profiles and Extensions for Elements and Data Types can be extended for attributes in Resources and to combine Resources for different Use Cases.

The most conspicuous benefits of FHIR is the ability to  build a conformed standardized yet unified view of common data sets/documents that are interoperable and shared with precise definitions both internally and with external systems and vendors.

The other benefits includes its support for Clinical Terminologies and Ontologies for SNOWMED, ICD9/10, LOINC and other Open Standards thus avoiding to design a separate Terminology Services with Codes for Lab noting’s, Diagnostics, Medications, Imaging and others.

Lastly, the most important one for me, FHIR Resources can also be presented in an RDF format (Linked Data) specification by serializing property information using Turtle format or as JSON-LD and presenting data in RDF (Resource Description Framework) data model to support Graph DB. A RDF Graph DB(SPARQL)  can help and enhances Healthcare provider’s ability to identify complex patterns of relationship in real or near real time that could save lives and decrease costs to Patients.

FHIR Implementation

FHIR can be implemented in a phased manner depending upon how many different domain repositories and areas of interest that Healthcare provider intends to build and leverage insights. HL7 also provides HAPI pronounced “happy” a JAVA based health care package library to enable adding FHIR messaging to your applications in building different FHIR Resources.

NoSQL Database

Todays, Key Value store are the norm for its flexibility in building a schemaless and horizontally scalable databases that supports object oriented paradigm. To this add performance compared to RDBMS as you scale up data volumes into billions of rows or terabytes/petabytes data and also to meet high demand throughput with low latency traffic there is no next best alternative to NoSQL.So In my opinion, a NoSQL data store is a perfect match for FHIR.

Conclusion: Containerizing data using FHIR Standards as Resource Types (Collections/Documents) from Data Lakes, HL7 Messaging into a NoSQL Database work as a self-contained, documented, standardized basic building blocks which can be readily utilized by both Research and Business Users to meet their Operational and Research needs with ease.