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
- Strong focus on implementation
- 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.
Kiran Sangem
Latest posts by Kiran Sangem (see all)
- Part 3 – FHIR: Why every EHR should follow the FHIR path - October 28, 2016
1 thought on “Part 2: FHIR – The Holy Grail”