HealthCare Interoperability with FHIR

Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must also be structured and standardized.

HL7 has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. FHIR (Fast Healthcare Interoperability Resources) is a new specification based on emerging industry approaches, but informed by years of lessons around requirements, successes and challenges. FHIR combines the best features of HL7’s v2 , HL7 v3 and CDA product lines while leveraging the latest web standards and applying a tight focus on implementability. FHIR is designed to enable information exchange to support the provision of healthcare in a wide variety of settings covering human and veterinary, clinical care (ambulatory care, in-patient, acute care, long-term care, community care, allied health), public health, clinical trials, administration and financial aspects.

FHIR aims to simplify implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.

FHIR’s primary components:

1. Resources – a collection of information models that define the data elements, constraints and relationships for the “business objects” most relevant to healthcare. From a model-driven architecture perspective, FHIR resources are notionally equivalent to a physical model implemented in XML, JSON or RDF.

FHIR solutions are built from a set of modular components called “Resources”. These resources can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternatives. FHIR is suitable for use in a wide variety of contexts – mobile phone apps, cloud communications, EHR-based data sharing and server communication.

All resources have the following features in common:
1. A URL that identifies the resource
2. Common metadata
3. Human-readable XHTML summary
4. Set of defined data elements – a different set for each type of resource
5. Extensibility framework to support variation in healthcare

FHIR Resource operations : For manipulation of resources, FHIR provides a REST API with a rich but simple set of interactions: Create , Read, Update, Delete, Search, History, Transaction & Operation.

2. APIs – a collection of well-defined interfaces for interoperating between two applications. Although not required, the FHIR specification targets RESTful interfaces for API implementation.

FHIR Advantages:

1. Strong focus on implementation: fast and easy to implement (multiple developers have had simple interfaces working in a single day).
2. Multiple implementation libraries, many examples available to kick-start development Specification is free for use with no restrictions
3. Interoperability out-of-the-box: base resources can be used as is, but can also be adapted as needed – which happens a lot – for local requirements using Profiles, Extensions, Terminologies and more.
4. Evolutionary development path from HL7 Version 2 and CDA: standards can co-exist and leverage each other.
5. Strong foundation in Web standards: XML, JSON, HTTP, OAuth, etc.
6. Support for RESTful architectures, seamless exchange of information using messages or documents, and service-based architectures.
7. Concise and easily understood specifications.
8. Human-readable serialization format for ease of use by developers.

FHIR and Architectural Principles:

FHIR’s primary purpose is to address interoperability with well-structured, expressive data models and simple, efficient data exchange mechanisms. In addition, FHIR aligns to the following architectural principles:
3. Reuse and Composability FHIR resources are designed with the 80/20 rule in mind – focus on the 20% of requirements that satisfy 80% of the interoperability needs. To this end, resources are designed to meet the general or common data requirements of many use cases to avoid the proliferation of numerous, overlapping and redundant resources. In addition, FHIR resources are highly composable in that resources commonly refer to other resources. This further promotes reuse and allows for complex structures to be built from more atomic resources.


4. Scalability – Aligning FHIR APIs to the REST architectural style ensure that all transactions are stateless which reduces memory usage, eliminates the needs for sticky sessions within a server farm and therefore supports horizontal scalability.


5. Performance – FHIR resources are lean and suitable for exchange across the network. Highly optimized formats are available, which has the potential to improve performance in complex transactions across multiple systems connected via a shared and finite network, though most implementers find the standard JSON / XML formats adequate.


6. Usability – FHIR resources are understood by technical experts and non-technical people alike. Even if the details of XML or JSON syntax are not understood, non-technical people can view these in any browser or text reader and understand the contents within them.


7. Data Fidelity – FHIR is strongly typed and has mechanisms built in for clinical terminology linkage and validation. In addition, XML and JSON documents can be validated syntactically as well as against a defined set of business rules. This promotes high data fidelity and goes a long way towards using FHIR to achieve semantic interoperability.


8. Implementability – One of the driving forces for FHIR is the need to create a standard with high adoption across disparate developer communities. FHIR is easily understood and readily implemented using industry standards and common mark-up and data exchange technologies.

Share on