Some notes on FHIR, healthcare information exchange standard
The electronic medical record also called EMR (or EHR) are software systems used by hospitals to record and maintain patient information. These systems store administrative (e.g. demographics, insurance, etc.) as well as clinical ( procedures, diagnosis, etc.) information. Hence, at the core of these systems is a database. These electronic medical systems being transactional usually employ an RDBMS as a database, e.g. Cerner uses Oracle, Allscripts uses SQL Server etc. On the other hand, software like Epic uses Cache.
Up to about 2014–2015, there was no orderly standard for exchanging healthcare data over REST and developing a web/mobile application on EMR data required inventing data model each time.
Integrating mobile app with different EMR will require developing API against those EMR. These EMR are often COTS.
Around 2015, FHIR was introduced by Hl7. It is a standard for exchanging healthcare data. This standard prescribes specific data/information model to create information to be conveyed from one system to other or read/write data from a modern web/mobile application using RestFUL API.
Fhir supports various formats including json, xml and several transport mechanism i.e. messaging, API etc.
Note that FHIR is an information exchange model and standard. It does not suggest any particular persistence type, i.e. relational or document/NoSQL etc.
Most EMR does not store data in FHIR friendly format, and hence FHIR server will transform data from non-FHIR to FHIR composition. Transformation in both directions ( read/write) are usually compute-intensive.
Some of these frequent transation ( FHIR to non-FHIR) can be reduced by pre-loading or caching data into FHIR formatted data store.
So what does a FHIR friendly storage looks like?
FHIR on the other hand is resource bases information model. These resources are payload of informaion.
A FHIR resource format looks like below
{ "resourceType" : "[name]", // e.g. Patient, Procedure, Claim
"id" : "<id>", // Unique ID of resource
"meta" : { Meta }, // Metadata about the resource e.g. version
"implicitRules" : "<uri>", // A set of rules under which this content was created
"language" : "<code>", // Language of the resource content ...... //resource specific elements
......}
A complete list of FHIR resource types can be found here.
Some of the common resource types are Person, Patient,Observation, Procedure, Medication, DiagnosticReport etc.
Each resource type has it’s own list of elements those are added into payload e.g. Procedure Resource Type can contain following additional elements.
Typically, in an EMR these information are stored in a dozens of normalized tables. Creating JSON/XML payload for FHIR will require querying all these information ( or using EMR provided custom APIs)
Alternative is to create a FHIR friendly data store next to FHIR server. This data store can be created using JSON/XML friendly data stores e.g. Mongo DB. You still have to manage data synchronization between EMR database and FHIR db. Which can be complicated. EMR database is remains primary system of record while FHIR db acts as cache.
There are several open source projects providing Fhir server
Google cloud healthcare API includes fhir store. As mentioned above you will have to load/import data into fhir store.
Microsoft and Google also offers Fhir API in the cloud, which includes Fhir database and API. These products most likely use spanner, CosmosDB under the covers for storing pre-generated Fhir resources.
