EMR/EHR on top of HL7 FHIR Server - Is it possible?

Fast Healthcare Interoperability Resources (FHIR, pronounced as fire) is a standard data format and elements that are suitable for exchange of healthcare data in and across the healthcare organizations developed and maintained by Health Level 7 (HL7). It will definitely solve one of the main problems and challenges of healthcare IT systems – “Interoperability”.

Electronic Health Records or information should be exchanged with different systems for better care coordination. Otherwise, there will be no benefit of digitalizing health sectors rather than saying “Our health system is fully digitalized!”. There will be no difference between digital data vs paper-based data if it cannot be exchanged. Effective data exchange is necessary to timely communicate with different systems operated by different departments of health organizations. It will also help physicians to quickly and correctly diagnose and manage the patient by the use of CDSS (clinical decision support system) which ultimately improve patient outcome.

Different level of healthcare facility use or planning to use a different kind of EHR/EMR systems as there are some adoption related issues. It also varies from country to country. For simplicity, let’s imagine a scenario. The country named “LaLa Land” is in a process of digitalizing its health sector. Most of the tertiary care facilities successfully adopted the world’s best EHR solution, EPiQ. The rest of the tertiary centers uses AGhA. In some cases, within one facility, they are using a mixture of systems. Now for the primary and secondary care facilities, Government initiates a project to develop a custom EHR system in order to engage their own talented, skilled people (of course including medical informaticians!) that suits country’s internal needs and which will be meaningfully interoperable.

Back to FHIR. It defines standards of healthcare data model, called resources like Patient, CodeSystem, Observation, Allergy, Problem, Medication etc. The standard defines every possible element that is needed to maintain perfect healthcare workflow. For example, Patient resource or Model have elements like Name, DOB, Gender, Address, Marital status etc. Each element has a clearcut definition of data type (string, number, boolean etc), flags (required or not) and how many times this element can appear on a resource (Multiple addresses can be assigned to single Patient etc). This type of data modeling is the most critical part of designing any software application. FHIR already have this.

Using this FHIR defined specifications, it’s really easy to design own data model, develop own EHR system with suitable tech stalk (like LAMP – Linux, Apache, MySQL, PHP). But wait, HL7 FHIR has an easy solution, FHIR Server which is a web server with built-in relational database (Apache Derby) written with JAVA that has a RESTful interface for every resource. Great!

For those who are new to RESTful term, here is my simplified explanation. When you enter some forms in the web, usually your data is sent to a server for creating or updating a record in a database. For example, when you post an ad in ebay-kleinanzeigen for the first time, your ad is created and stored in eBay database. When you edit something and save, stored data is updated. When the viewer sees your ad, data is being read from the database. When you delete, data is deleted from the database. So there are 4 basic types of database operation, CRUD (create, read, update, delete). When this operation is done through HTTP protocol, it requires some verbs (GET, POST, PUT, DELETE) which actually told the server what to do. For example, to perform create operation – POST is used etc. There are others specification of RESTful term but I think you got the point. So, in general, RESTful is some defined specifications that are required and used to send/receive data to/from a database via http protocol. With this concept, API (Application Programming Interface) is being developed so that different interface (web, mobile) can interact with the API directly. Normally when you use a LAMP stalk, this kind of API needs to be developed by writing thousands line of code using PHP language. But in FHIR Server, RESTful API is already there. You just need to make an interface (Desktop, Web or Mobile) to interact with the FHIR API. Isn’t it interesting? This will save time and money but retain all the standard of developing EHR system.

Back to LaLa Land. The project of developing EHR is on-going, completed their in-depth requirement analysis and documented every workflow, data model by UML (unified modeling language) diagram. Then they subdivide the project into 3 groups – GR1, Gr2, Gr3. Gr1 will use traditional tech stack to build the EHR. Gr2 will build API for the EHR with the FHIR specifications. Gr3 will use FHIR Server, they only build the interface (desktop, web, mobile).

Now the question is for you.

• What do you think which group will ultimately end up with a success?
• Which group need less time and money without compromising interoperability standard?

Possible challenges for Gr3

• Data security and encryption
• Require 3rd party authentication provider database
• Roles and access control
• Data Backup and recovery
• Hardening the FHIR server
• Load balancing, co-location, and replication

Thank you for your time.