FHIR®, or Fast Healthcare Interoperability Resources, is the next generation HL7® standard for healthcare data integration. It focuses on decreasing interoperability costs, and unlocking technical innovation in healthcare. FHIR does this by supporting an ecosystem of information providers and consumers via open APIs. But with any API and particularly one that exposes Personal Health Information (PHI), security issues need consideration.

In a recent whitepaper, we­ discussed the role of SMART on FHIR in establishing a layer or security around FHIR applications, and identifying users and applications to sources of information. SMART (standing for Substitutable Medical Applications and Reusable Technologies) describes how to use OAuth2 in a healthcare setting, and describes a number of server ‘roles’ that are needed.

But security is only part of the story, there are other server roles that can play an important part of a FHIR based ecosystem, and this post describes some of them.

The following roles are described.

  1. Repositories of data that applications will use. Each one will potentially be different, and can tell us their capabilities by using their CapabilityStatement. This is a specialised FHIR resource that describes what resources are stored in the repository, and what operations can be performed on them.
  2. Provider/Patient Registries provide the ability to consistently identify the target of healthcare, this is a critical component.
  3. A Conformance Server stores all the profiles and extension definitions that are used to create customised FHIR interfaces. Placing these in a single location improves the ability to locate them.
  4. The Terminology Server is a critical part of any information-sharing environment by improving the ability to facilitate consistent coding of data by the applications in the ecosystem. It can store the ValueSets, but should also expose key terminology services such as the ‘expand’ operation that takes in a filter string and returns a list of matching concepts. This is a very helpful feature for context specific drop downs.
  5. Decision Support is something that both assists users in the delivery of quality healthcare, and also helps with consistency. For example, you could imagine an immunisation protocol service that receives the child’s Date of Birth, gender and current immunisation history and returns the required immunisations.
  6. Workflow is required to support a number of functions such as referrals between providers or ordering Laboratory tests. The latest version of FHIR supports a separate server that can be used to manage and track these activities within the ecosystem.
  7. Services Directory and Provider Registry will help locate the people and places that will need to used.
  8. The Authorisation Server and an Identity Source which SMART uses to identify users to repositories, and helps a repository decide what data can be released to a user of an application.

These are all servers with specific FHIR API interfaces. Each one could be a separate ‘physical’ server, or a single server could support multiple roles.

SMART on FHIR has a role in securing a ‘FHIR ecosystem’ and supporting safe access to data. It is unlikely that an ecosystem would be created from scratch, in the real world it is a lot more complex and migrating from all the current infrastructure will take time. But it’s good to have an idea of what the future might be!

Learn about how to maximise security by adding SMART(s) to your FHIR APIs. Download the white paper now.

Click below to find out more about Amadeus, our open data platform.

Learn more