How Can You Create a Secure FHIR® Ecosystem?

SMART on FHIR® (Substitutable Medical Applications and Reusable Technologies on Fast Healthcare Interoperability Resources) has an important role in securing a “FHIR® ecosystem” and supporting safe access to data which enables the open healthcare ecosystem. What else is required?

FHIR® is the next generation HL7® standard for healthcare data integration. It focuses on decreasing interoperability costs and unlocking technical innovation in healthcare, and it 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 of security around FHIR® applications and identifying users and applications with sources of information. SMART describes how to use OAuth2 in a healthcare setting and 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 in a FHIR®-based ecosystem, and this post describes some of them. The following diagram illustrates:

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 specialized 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 customized 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. It improves 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 immunization protocol service that receives the child’s date of birth, gender, and current immunization history and returns the required immunizations.
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 Provider Registry will help locate the people and places that will need to be used.
8. The Authorization Server and an Identity Source which SMART uses to identify users to repositories help a repository decide which 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 infrastructures will take time. But it’s good to have an idea of what the future might bring

®Health Level Seven, HL7, FHIR and the FHIR [FLAME DESIGN] are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. The use of these trademarks does not reflect HL7’s endorsement.