“Can I see your blood test reports from last month” – the doctor asked me. “I have it on my mobile” – I told him. I showed him the pdf report the lab had mail me on my email id. “Do you have earlier reports?”– he asked. I started searching my mailbox for previous reports but was unable to locate them. I asked him “Sir, if I give you my hospital Id, can you fetch it from your system. some tests were done in another branch of your hospital”.
He took my hospital id , searched on his EMR and found my old records. Relieved I wondered if I had my tests done in another hospital how would had I shown the reports. This hospital has a centralized information management system connecting all the branches and an universal patient identifier. However the doctor was able to see all my tests and note of my encounters with other doctors in the hospital, which I felt was violation of my privacy.
I used to go to a hospital when I lived in another part of the city, when I changed my residence I preferred a different hospital near to me. People are mobile, they move within cities and across cities for jobs, for better commute ,for better school for kids or for various other reasons. It is quite natural that preferred care facility a person chooses to go to for day to day care also changes as a result of relocation, this leads to broken medical history. There is no way for me to consolidate my electronic health record today. Lets us assume that hospitals do want to share patient records with each other for the better good of the patient, but limitations of their existing systems don’t allow them to do so. Their existing infrastructure was designed to work well within the boundary of the enterprise.
HL7 FHIR (Fast Healthcare Interoperability Resources) standard promises to enable these healthcare enterprises have mechanism to exchange data with third parties outside their corporate network cost effectively and efficiently. FHIR supports structured healthcare data exchange over standard web via restful APIs.Setting up a FHIR server can as simple as hosting a web server. No need to punch a hole in corporate IT firewall to open a custom port, no need for point to point vpn tunnel. In the Indian context, adopting FHIR makes a lot of sense. Following are some of the reasons why FHIR can be the go to healthcare data exchange standard for India.
- FHIR Standard is free.
- FHIR doesn’t require specialized knowledge. FHIR makes use of several well-known web standards, the skills required to develop applications with FHIR are directly transferable from anyone working in website or web app development.
- Multiple opensource implementations available. Its vibrant community of developers , implementers and supporters can be tapped into for any support.
- Supports mobility. Strong focus on web technologies and implement-ability makes FHIR the standard for building Healthcare Apps for internet, cloud and mobile.
- Standard is flexible and adaptable. FHIR provides flexibility to extend and adapt it according to local needs.
- Standard is fairly stable and is being actively adopted across the world.
- FHIR is listed as healthcare data exchange standard in National Digital Health Blueprint (NDHB) 2019
When implementing FHIR in your systems, it is important to keep in mind that two FHIR complaint systems may actually be not interoperable. The main reason for this is the inherent deliberate flexibility of the specification to allow it to be used in different diverse scenarios across the globe. To illustrate the flexibility let me tell that a blank patient resource with no elements is still a valid patient resource. Almost every element in the base FHIR specification is optional. Interoperablity will be guaranteed if both sender and receiver of the FHIR resource(s) agree on the content of the data and what operations are allowed on the resource(s). FHIR profiling is a way to build this consensus on content, operations & search parameters supported. Two systems supporting a FHIR profile mean that they agree to the content rules specified in the profile and therefore they know what data to expect or send. In essence due its flexibility FHIR specification usually requires further adaptation to particular contexts of use. Typically, these adaptations specify:
- Rules about which resource elements are or are not used, and what additional elements are added that are not part of the base specification
- Rules about which API features are used, and how
- Rules about which terminologies are used in particular elements
- Descriptions of how the Resource elements and API features map to local requirements and/or implementations.
As observed globally national FHIR initiatives typically start with Profiling at national level- Studying and adapting FHIR specification to meet the specific requirements of the country and targeted use cases. Creating a community , building human capital , enlisting support from key stakeholders , establishing tooling & infrastructure for implementers also go in parallel. Profiling is a community activity, it typically involves following activities
Use Case selection,
Definition of behaviors & data models required,
Mapping of resources & creation of profiles,
implementation in products,
testing to validate & refine as required, demonstrate maturity and then finally publish a stable version
National profiles are just the beginning, local regional & specialized domains would require further adaptations to suit their specific needs and use cases. States may find a need to further adapt the National profiles to suit local regulations or uniqueness. Mental health & Cardiology may need different set of data elements hence domain experts may choose to further adapt National or regional profiles. FHIR profiles are layered in sense that national profiles adapt from base (core ) , states or regions adapt from national profiles and specialized domain or organizations further adapt the regional profiles. The levels of layering depends on the context and the usecase. Following picture depicts the concept of layering. Given the diversity of Indian context, proliferation of profiles is very likely therefore a governance infrastructure is a must.
In the next article I will share the efforts underway to make FHIR work for India. The intent of this article is to get feedback and support from everyone as we embark on the journey of lighting the FHIR in India.
This article was first published on Kumar Satyam’s LinkedIn Pulse Blog, its been published here with the author’s permission