Healthcare organisations and institutions have traditionally set their own conventions for data exchange across the Internet and with each other. This leads to the problem where the same core resources which exist in the healthcare world (patients, practitioners, organisations, and more) follow entirely different conventions in the way that data is modelled at the database level – and how that data is exchanged across the web via APIs.
FHIR is introduced to overcome this problem by acting as an interoperability standard that can be adopted by organisations that want to open themselves to opportunities to integrate with other organisations to augment the services they provide. iPLATO aims to be a part of this initiative.
For some background, HL7 FHIR was introduced to emerge from a document-based environment where interoperability was based on documents no matter how they were sent (physically or electronically). The health care providers had to choose information from those documents and then transmit the data, but the industry wanted faster, easier and better way to exchange the electronic health records. The growth of the industry and the monumental amount of new data being generated created a need to share the data in real time using modern web technologies and protocols without any barrier with help of FHIR. Sharing medical documents such as test results can help improve patient health and care.
Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. FHIR aims to simplify implementation without sacrificing informational integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.
Overview of FHIR
The FHIR specification consist of two parts:
- Resources: This is the basic component in FHIR and all the exchangeable data is defined as resource (such as diagnoses and medications, and other clinical entities). Resources all share the following set of characteristics:
- A common way to define and represent them, building them from data types that define common reusable patterns of elements
- A common set of metadata
- A human readable part
This will ensure that, for instance, the way a patient is modelled in iPLATO’s systems will not be too dissimilar from the way it’s modelled by other implementers of FHIR.
2. Exchange – Rest API: Standards about data exchange on how to build REST APIs that access or manipulate FHIR Resources. Broadly we can divide them into three main categories messages, documents and real time. Messages will be used if one system wants to update another system regarding any event or want to trigger one. Documents will be used for clinical data or any other information which could be in form of document. Real time interaction happens between various system or persons via APIs. iPLATO will support all of these exchanges to be FHIR compliant.
The biggest challenge in the FHIR implementation is that two different application might implement different version of FHIR or developers have only partially implemented the FHIR api which means they are not interoperable despite implementing FHIR. Fortunately, FHIR provides a CapabilityStatement resource that lets each implementer specify their level of FHIR adherence.
FHIR in iplato
FHIR will enable an ecosystem of connected health care applications developed by different vendors. iplato will be able to integrate with solutions developed by different companies and bring them together into an ecosystem of connected healthcare applications.
A successful transition to FHIR compliance for iPlato is predicated on the following objectives being met:
- FHIR REST API conventions applied to each new endpoint which will also be documented in Swagger
- A database per microservice with a logical schema that has been modelled after the microservice’s problem domain and in alignment with FHIR’s specification for Resources
- Preserving database transactional integrity for legacy system during migration
- Deprecation of monolithic APIs and databases
Because there are multiple objectives to be met adjacent to project work, a phased approach has been determined to help with the transition. Some steps will be applied on each project, to ensure we are becoming compliant in a commercially viable manner. And other steps will be applied once the majority of our APIs have been transitioned.
Phase 1 – Applied project by project
Becoming FHIR compliant with HAPI
This data will be exposed through endpoints that follow FHIR’s REST API conventions. HAPI model objects will be used to present a materialised view that conforms to FHIR’s definition of healthcare resources. The usage of HAPI is as a stepping stone towards schema discovery and faster FHIR compliance.
Phase 2 – Completing the transition
Become fully FHIR compliant with HAPI
Once the schema has been discovered, HAPI model objects are no longer required to translate from our data to a FHIR compliant standard – because our data is modelled according to FHIR compliant Resources by now!
For iPLATO, FHIR is enabling smarter exchange and acquisition of data, mobility and new types of connected solutions.
FHIR future with distributed ledger, blockchain.
Blockchain can have some scope in interoperability use cases. The real challenge here is to achieve integrity and trust in a distributed system and this is the problem that blockchain might solve.
We can create a distributed peer to peer system of ledgers ( Medical data) by making copies of it available who asks for it in a secure way (cryptography). Another challenge solved by blockchain is to keep system open to everyone while ensuring only valid and authorisation data is added. Smart contracts (Ethereum based) can be used for critical operations like signing of documents or other operation that require some level of trust .
The services and registries needed to implement FHIR :
• An agreed definition (model) of the information we’re going to share expressed as FHIR profiles with the supporting conformance artefacts (resources) openly available
• A FHIR conformance registry that holds those artefacts
• Record Locator services
• Applications registry
• Recommendation and Decision Support Services
• Scheduling services
• Workflow services
• Audit Services
It is an exciting time for the healthcare industry. FHIR adoption will mean healthcare companies operating in completely different spaces can integrate with other healthcare companies to provide technology solutions that could not be conceived in the past.