. Page versions: R5 R4B R4 R3 R2This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
Fast Healthcare Interoperability Resources (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. This section gathers all information about security in one section. A summary:
Time critical concerns regarding security flaws in the FHIR specification should be addressed to the FHIR email list for prompt consideration. Alternatively, issues can be raised through the community input mechanism.
Implementers should track the developing IHE IUA Profile for additional security considerations.
A production FHIR system will need some kind of security sub-system that administers users, user authentication and user-authorization. Where this sub-system fits into the deployment architecture is a matter for system design:
|
|
In this diagram, the red lines represent FHIR interfaces. From the perspective of the FHIR API, the client (consumer of FHIR services) may either interact with a security system that manifests as a FHIR server, and which depends on a subsequent FHIR interface to provide the actual storage, or either the client or server interacts with the security system independently. In each of these 3 scenarios, the different components may be assembled into applications or network components differently, but the same logical layout applies.
The FHIR specification assumes that a security system exists, and that it may be deployed in front of or behind the FHIR API. Because there are a plethora of standards relating to the administration and functionality of the security system, FHIR does not provide user, profile, or other such administration resources. Instead, the FHIR resources are the targets of the policies expressed in these other approaches. What FHIR does specify is a way to apply security labels to resources so that a security system may use these (along with the contents of the resources if appropriate) to determine whether a user is authorised to perform a particular FHIR operation or not.
For the RESTful API, normal HTTP security rules apply. The Service Root URL will specify whether SSL is required. Client authentication may be required by the server, possibly including the requirement for client certificates.
Other than testing systems, FHIR servers should authenticate the clients. The server may choose to authenticate the client system and trust it, or to authenticate the individual user by a vareity of techniques. For web-centric use, OAuth may be used to authenticate and/or authorise the users.
Correctly identifying people, devices, locations and organizations is one of the foundations that any security system is built on. Most uses of security protocols, whether authentication, access control, digital signatures, etc. rely on the correct mapping between the relevant resources and the underlying systems. Note that this isn't necessary: there is nothing in FHIR that requires or relies on any security being in place, or any particular implementation. But real world usage will generally require this.
Todo.. outline general considerations. Note: this is under active investigation through connectathons running parallel to the ballot process, and further work is expected on this section. Interested parties should track the joint security / FHIR work in this area.
RBAC notes go here
This specification recommends the use of W3C Digital Signatures to sign resources, and provides an element in the Provenance resource to carry a detached digital signature for a resource. This does not prohibit other ways of using digital signatures.
Additional work is anticipated in this area, including alignment with the IHE DSG profile.
Several FHIR resources include attachments. Attachments can either be references to content found elsewhere, or included inline encoded in base64. Attachments represent security risks in a way that FHIR resources do not, since some attachments contain executable code. Implementers should always use caution when handling resources.
