Blog Layout

FHIR-an incremental and RESTful approach to health data interoperability

FHIR, the acronym for Fast Healthcare Interoperability Resource, takes the internet-based approach to connect different health systems and is a data standard developed and nurtured by HL7 International.

FHIR enables building of standardized "browser" applications that will enable access to data no matter what EHR "operating system" underpins the user's infrastructure.

It is often difficult to reconcile health information between healthcare IT systems due to the independent data models used by the systems and is seen to be an expensive and time-consuming challenge. FHIR addresses this issue by defining an open interoperability standard, compatible with the latest web standards built upon service-based architecture.

FHIR: Health interoperability standard designed for the future

Interoperability in today’s context really means being able to access data from multiple health systems in real time. FHIR represents a mature standard for health data interoperability that is ready for the healthcare industry’s pent-up demands.

What makes FHIR different from other health interoperability standards

Currently, most of the health information exchange is document based which is limiting for meaningful care coordination, decision making, or data analytics. Also, standards like C-CDA although contains a great deal of critical information, but data is relatively static, and it takes a special effort to extract the information and make it usable in any other format. Also, document-based information exchange is complete but does not allow a provider to delve into the context of the data received. Just sending some lab results or a list of allergies is not enough when the user does not have the story of the patient at his disposal. With the use of FHIR, applications can be plugged into an EHR and feed information directly into the provider workflow, avoiding pitfalls of document-based exchange, which often requires providers to access data separately.

The healthcare Internet of Things is growing, but so far, no technology has been able to connect the patient-generated health data (PGHD) coming from millions of FitBits, Apple Watches, Bluetooth scales, blood glucose monitors, diet apps, and fitness trackers streamlined into the provider workflows. Such a pool of PGHD is meaningless if the providers are not able to access the same quickly and easily. FHIR can enable accessing these otherwise “locked” PGHD on a FHIR platform such that users will be able to perform various downstream activities like data analytics and present trends relevant to aspects of say, chronic disease management or patient wellness.

FHIR standard is now widely used in mobile applications, cloud communications, EHR-based data sharing, and server communications across the healthcare industry.

Components of FHIR standard specification

FHIR as a data exchange standard is composed of 4 basic components:

Information model:

Comprises of data content and format. The data content is in the form of well-structured expressive data models. Formats include the common industry standards such as JSON, XML, Turtle RDF. Therefore, FHIR provides flexibility in the way the data can be exchanged and either of the above-mentioned standards can be used. Most servers utilize JSON format as the exchange standard.

Usage:

Usage includes the mechanisms of data exchange. FHIR uses RESTful API for data exchange. Information Model and Usage comprises the core components of the FHIR Specifications.

Conformance:

FHIR Specifications includes a set of rules with regards to how the resources and their exchange paradigms need to be used to satisfy specific use cases.

Terminology:

FHIR Specifications provide a mechanism to support clinical terminologies a detailed description of which is available in the FHIR specifications. In FHIR, each terminology is represented by a code system resource within a FHIR server. Some examples of large, standardized terminologies are SNOMED CT, RxNorm and LOINC.

Components of FHIR

Following is the snapshot of the components that make up the FHIR structure

FHIR Resources

Resources can be considered as the atomic piece of information exchange that makes up the FHIR structure. Resource is a collection of data elements, and each element is of a data type and is the basic unit of interoperability. Health care data is broken down into categories such as patients, laboratory results, and insurance claims, among many others, each of which is represented by a FHIR Resource.

Resources can be represented in multiple formats (UML, XML, JSON). They can also contain normal text with explanations.

A FHIR resource can be an individual packet of information that includes metadata, text, or data elements but can also be bundled into collections that create clinical documents, similar to the Consolidated Clinical Document Architecture (C-CDA), but with more flexibility.

Types of Resources :

Administrative: Patient, Practitioner, Location, Organization, Coverage, Invoice.
Clinical: Allergy Intolerance, Condition, Family History, Care Plan

References

FHIR resource references are directional links from a source resource to a target resource. FHIR resource references can be used to connect resources. References are always defined and represented from one resource (source) to another (target).

Example by linking Patient to Observation (which stores assertions made about a patient), Condition (problem or diagnosis) and Medication (ingredients, amount, strength of medications), one can implement and tailor specific scenarios.

References are provided either as a URL, via an explicit identifier for the target resource, or in text description.

In FHIR, resources are referenced, or linked, in one direction only. For example, if there are two resources - a Patient and an Observation - a Patient will not be linked to any of the Observations; instead, all Observations will be linked to the Patient.

FHIR Profiles

FHIR “Profile” serves to provide customization to a resource by specifying a set of rules on the base resource per use case basis.

A profile lays constraints over the top of the base Resource or another profile to either:

Constrain it further (Constraints)
Extend it (with extensions)

An example of profiling a base resource would be to specify an identifier for a Patient Resource.

To suit the needs of a particular use case, one needs to apply edits/constraints on existing Resources and is referred to as Profiles

Profiles serve as documentation of the use case that can be published and shared so that others can reuse them in similar use cases

Constraints can also be applied on existing Profiles and referred to as “Derived Profiles”. This customization is done to suit the needs of specific clinical use cases.

The standard base resources have very generic definitions. A FHIR profile allows

to author and publish a customized, more specific resource definition, by specifying a set of constraints and/or extensions on the base resource.

Architectural Principles of FHIR

FHIR Architectural principles are comprised of 6 principles namely Reuse and Composability, Performance, Usability, Data fidelity, Scalability and implementability. The first four principles are aligned to the data structure, scalability is linked with the exchange mechanism and implementability is both structure as well as data exchange.

FHIR Architectural principles - Reuse and Composability,

Maturity stages of FHIR Resources

FHIR Resources undergoes the following stages in its life cycle, in which “Normative” is considered to be the most stable stage.

FHIR API

FHIR includes specifications for an Application Programming Interface, or API, based on established web standards. Many modern applications, both desktop and mobile, use APIs to retrieve, store, and update data.

An API is an entry point, or “interface,” that allows another software to access the features and data of a different software.

Understanding REST Architecture

Many applications that run on a mobile device or web browser use the information exchange standard REST (Representational State Transfer) as the basis for their APIs. REST is a method of exchanging information using the World Wide Web standard transfer protocol HTTP, which is the underlying internet standard that forms the basis for all website data exchange.

REST comprises of a request from a client and response from the server. The exchange of data using REST is termed a “RESTful” exchange. The advantages of RESTful architectures include light-weight interfaces allowing fast transmission and processing of data which suits mobile and tablet devices.

FHIR uses REST as the basis for data exchange in its API. The interoperable data units within FHIR termed as Resources are requested from the servers via a RESTful HTTP command. Servers, such as those behind an electronic health records system, are programmed with the types of Resources and interactions they can support.

By using the REST architectural style, FHIR takes the best of existing health information technology and common internet standards to create a modern method of interoperability. This allows health care systems to implement FHIR without steep learning curves and leading to faster application design.

Understanding FHIR Server

A FHIR Server can be defined as being able to perform the following activities:

Accept a RESTful API request
Interpret the RESTful API request
Act upon the request
Return a response

The FHIR Server is expected to return at a minimum a Capability Statement which lists down the capabilities of the server.

No previous FHIR messages are stored in the server hence the messages passed must be self-descriptive.

Resources are represented by formats like JSON, XML, which the client and server can understand.

Resource identity (URI) should also be represented in a way that both client and server can understand.

Understanding FHIR Request to Server

A FHIR Request to the server consists of 3 components:

Request line: Comprised of the [HTTP method] and [URI]. This is mandatory in the Request structure.
The HTTP method tells the server what it has to do.
URI: stands for Uniform Resource Identity. URI points to the desired Resource. Resource identity specifies the resource type e.g Patient Resource.

Header Fields: They consist of key value pairs [key1]: [value1]. Some of which may be required.·
Body: Comprised of Resource. It is optional in the request structure.

Understanding FHIR Response from Server

FHIR response has 3 components:

Status line: This informs the status of the interaction and consists of [status code] and [Reason]. It is required in the structure of the response. It consists of information like Success/failure.
Header fields: They are key value pairs [key1]: [value1] similar to the request Header fields. Some of which may be required.
Body: Comprised of Resource. It is optional.

FHIR API interactions

Most common FHIR interactions include the following:

FHIR is poised to become the underlying ‘network’ that links disparate health applications. As FHIR continues to underpin health data interoperability, providers and patients will be served with access to an incredibly rich set of functionalities within a secure healthcare ecosystem in which patients can access their data effortlessly, and clinicians can access information from external systems efficiently and seamlessly. Owing to the ease of use and adoption due to its alignment with the internet, FHIR is primed to be the future of global healthcare interoperability.

< Older Post

Newer Post >