In the previous week, we have the Part 1: From HL7 to FHIR, where we discussed about HL7 and the shortcomings which we have all come across while working with it in today’s times. The changing times needed a better and well equipped interoperability standard, from where we have FHIR.
Here we shall go deeper into understanding FHIR, the building blocks of this system and more
The Holy Grail – What is a part of FHIR?
New artifacts, data types, tools methodology built on existing RIM, vocabularies and data types
Pre-defined Resources and API
A common way to represent data as building blocks
Rules for connecting them
Target support for common scenarios
Implementer friendly
Strong focus on implementation
Design for 80% – Only include data elements in the artifacts
Extension for 20% – allows easy extension of data elements
Simple to understand and access with examples
Familiar tooling and technologies using web standards – XML/JSON, HTTP, SSL, oAuth, Atom, RESTful API
Multiple Libraries available for faster implementations – HAPI, Furore, CDS hooks
Open source demo servers
Human-readable wire format to ease the use for developers
Mobile friendly
Concise and easily understood specifications, RESTful API and JSON
Leverages cross industry web technologies
Multi-paradigm, all architectures, all clients
Thick client, browser or mobile devices
Supports human readability as base level of interoperability
Large community for support
Heaps of open source software
Free for use specifications with no restrictions
Specification feedback welcomed, including update requests-tracker
Training events, webinars, connectathons
Out-of-the-box interoperability
Base resources can be used as it is, can also be adopted for local requirements
Seamless exchange of information using messages or document
Is it for me?
The digital world has evolved, and interoperability plays a major role for healthcare today and in the coming times. There are innumerable instances where we need a set of standards followed across healthcare scenarios.
If someone is building a new iOS healthcare app (and thousands are), what standard do we point them to?
If someone wants to provide a cloud based health app that integrates with social networks, what standard should they use?
If a vendor wants to provide a simple to use standards based API to cloud based health integration services, what standard should they extend?
If a government wants to implement a national EHR, who should they talk to?
The answer to all these is FHIR
FHIR – Nuts and Bolts
Interoperability paradigms
FHIR supports 4 interoperability paradigms. FHIR implementation may implement one or many paradigms according to the design and requirement of the workflow involved.
FHIR leverages the same data models and profiles (everywhere regardless of interoperability approach) REST, Documents, Messages, and Services. These are lessons learned from HL7 version 3, where different models are being used depending on the integration approach, leading to additional implementation challenges.
Building blocks
What does FHIR entail? Let us take a look at the basic building blocks of FHIR
Resources
FHIR solutions are built from a set of modular components called “Resources”. An instance of data that is stored or exchanged can be termed as a resource.
A resource is an entity that-
Has a known identity (a URL) by which it can be addressed
Identifies itself as one of the types of ‘resources’ defined in this specification
Contains a set of structured data items as described by the definition of the resource type
Contains a human-readable XHTML representation of the content of resource
Has an identified version that changes if the contents of the resource changes
Resources have multiple representations and can be represented as JSON/XML. FHIR based systems can then map the clinical and administrative actions by performing a search/read/create/update/delete of the interlinked resources.
Examples – ‘Patient’, ‘Procedure’, ‘Document’, ‘Message’, etc.
Bundling
One common operation performed with resources is to gather a collection of resources into a single XML instance. In FHIR this is referred to as “Bundling” the resources together. The resource bundle is not just a list of references to resources, but includes their whole content.
These resource bundles are useful for a variety of different reasons, including:
Returning a set of resources that meet some criteria as part of a server operation; this interaction searches a set of resources based on some filter criteria, which can be performed by several different HTTP commands
Returning a set of versions of resources as part of the history operation on a server
Storing a collection of resources
Exchanging a set of resources as part of a message transaction; where a ‘request message’ is sent from a source application to a destination application when an event happens
Grouping a self-contained set of resources to act as an exchangeable and persist-able group with clinical integrity (i.e. a clinical document)
Extensions
Every element in a resource or data type includes an optional “extension” child element that may be present any number of times.
It is a three step process:
Define the extension
Register the extension
Use it in the instance
Example: A social web provider of personal healthcare record (PHR) services might be obliged to keep track of the particular policy under which a patient has created their relationship with the PHR provider, and share this with their participants via their FHIR API. If they wish, they can extend the patient resource to represent the patient’s participation agreement.
Modifier Extension
Extensions also allow modification of the meaning of the resource that contains it (Example – to negate the meaning of the resource).
An anti-prescription: recording an instruction not to take a medication
Asserting that a performer was not actually involved in a Procedure
Recording that a Supply was not provided (i.e. refusal to fill)
Profiles
Profile is a special resource that provides additional rules about how a type of resource is utilized in particular context of use or for a particular use case.
Profile resources have 3 main parts:
A metadata section that describes the purpose of profile & helps with location & versioning of profile
Structure that define and describe how a resource or data type is used
Extension definitions that define extensions (if required) that can be used in structures
Examples: A Laboratory service producing a set of different reports – general chemistry, blood count, etc. Typical labs would support several hundred different reports which form a Conformance profile.
Security mechanisms
FHIR is not a security protocol, nor does it define any security related functionality. However FHIR does define exchange protocols and content models that need to be used with various security protocols defined elsewhere.
Security standards defined as part of FHIR
Communications Security – all exchange of production data should be secured using TLS/SSL (e.g. https)
Authentication – Users/Clients may be authenticated in any way desired. For web-centric use, oAuth is recommended.
Authorization/Access Control – FHIR defines a Security Label infrastructure to support access control management.
FHIR may also define a set of resources to administer access control management, but currently nothing is defined.
Audit – FHIR defines provenance and security event resources suitable for tracking the origins, authorship, history, status and access of resources
Digital Signatures – FHIR includes several specifically reserved locations for digital signatures
Attachments – FHIR allows for binary resources and attachments. These have their own concerns
Labels – FHIR allows for set of security related tags that affect the way resources are handled
Data Management Policies – FHIR defines a set of capabilities to support data exchange.