Security in FHIR

FHIR is the next generation HL7® standard for healthcare data integration. It focuses on removing barriers to interoperability and unlocking technical innovation in healthcare.

FHIR achieves this by supporting an ecosystem where providers and consumers share data via open APIs. Within such an environment, particularly one that deals with Personal Health Information (PHI), security aspects are paramount.

Even when FHIR does not define security capabilities, it indicates protocols and protection measures to adopt for sharing clinical resources.

SMART on FHIR for secure integrations

The SMART (Substitutable Medical Applications and Reusable Technologies) on FHIR project has worked towards a platform where innovative apps can be built once and reused anywhere in the healthcare system.

Expectations around security are defined in order to safely integrate with mobile devices, cloud-based platforms and EHR systems.

The SMART App Launch Framework Implementation Guide supports the connection to third party systems from inside or outside of the EHR systems.

The framework provides a secure authorisation protocol, where FHIR resources are shared amongst users such as clinicians and patients (once they have been given permission) to launch an app.

The implementation guide requires OAuth2 and OpenId Connect compliance to manage appropriate access to FHIR APIs when launching an app connected to the EHR.

Patient participation and FHIR resources to watch

Traditionally, access to clinical resources has been driven by the relationship that exists between the owner of the data (i.e. patient) and the consumer of it, which most of the time is represented by a healthcare provider.

The Patient Access API rule, published earlier this year by CMS, officially breaks this paradigm, by enabling individuals to take advantage of their information and make informed decisions in their clinical journey.

Through the FHIR Consent resource, a patient can declare the policy of choice, indicating, for example, which parties should be allowed to access their data, under which circumstances and for how long.

Amongst other resources, FHIR provides the Provenance resource, which is crucial in an ecosystem where data contributors proliferate (e.g. patient and personal smart devices).

In order to correctly manage clinical information in a world of emerging data sources, the indication of authorship, authenticity and reliability are fundamental to execute security and privacy policies.

Security labels for privacy evaluation

FHIR allows for a set of security-related tags that can be used to execute more granular and effective privacy policies.

A security label is a tag attached to a resource, providing additional details around the security classification of the information.

Five groups of tags are defined, in order to meet the Healthcare Privacy and Security Classification System (HCS), including confidentiality classification and sensitivity categorisation. The first expresses the level of security that the author wants applied to resources (e.g. low, normal, restricted) and the second indicates the vulnerability and eventual social discrimination that comes with disclosure of clinical data (e.g. substance abuse, mental health, genetic details, …).

The purpose of a security label is to enforce the handling of such caveats to ensure patient data is accessed according to organisational privacy policies and jurisdictional requirements.

The integration of behavioural data in the patient longitudinal record stress the importance of adopting sensitivity tags to disclose information only to appropriate healthcare providers.

The 42 CFR Part 2 in the US legislation, highlights the need for tools like the security labels to safely manage substance use disorders.

How is Orion Health involved in this?

Orion Health has been working with the FHIR standard since the earliest versions and understands the value that it brings in an open and innovative ecosystem.

At Orion Health we have included confidentiality as well as sensitivity tagging of FHIR resources to enable evaluation of privacy at a granular level.

Behavioural specialists can be assigned a policy to access mental health information while keeping unauthorized users unaware of conditions that might put patients in a vulnerable position.

Organisations can determine the most appropriate set of sensitivity categories for their use cases) and apply the relevant access controls to users based on their responsibilities or functions.

While supporting the OAuth2 authorization protocol, the Orion Health FHIR APIs will soon comply with the de facto standard OpenId Connect for authenticating apps in the SMART on FHIR ecosystem.

Interested in learning more about how Orion Health incorporates security in FHIR?

This blog is the fifth in the series on all things FHIR. The next in the series is focused on why FHIR APIs are better.

Read our previous blog on “What’s the big deal with FHIR 4?”