What is a FHIR profile and how is it different to a FHIR API?
The core FHIR specification from HL7 is built around a set of “resources”, which are the atomic building blocks of information in anything that claims to conform to the FHIR specification. An example would be a “Patient” – this is a resource with some attributes defined internationally as part of the HL7 FHIR specification.
A profile is a way of specialising a FHIR resource for a particular use-case. This specialisation can take the form of constraining it (e.g. in our profile of “Patient” we don’t ever want to see a species, as we are only ever interested in humans), but can also include “extensions” that add additional attributes to the patient (e.g. we want to add a new field to hold the patient’s nominated pharmacy to support our national electronic prescribing solution. It is important to note that a profile is simply a set of rules, and the actual FHIR “patient” resource you send from one system to another will still conform to the international HL7 definition, but may also conform to your more specific profile.
We are working with INTEROPen to agree a set of NHS England-wide “Care Connect” profiles to give us a level of consistency in how these resources are represented across FHIR implementations in England.
All the profiles do however is define the information that each resource can contain – which leads us onto the second part of this discussion – FHIR APIs.
As well as defining a set of resources, and a mechanism for creating profiles, the HL7 FHIR specification also provides a set of rules for how those resources can be used in both traditional messaging (e.g. bundling up a group of profiles into a message or FHIR document to send to another system), and also in ReST APIs. The latter part – ReST APIs are where a lot of the focus is in the FHIR community.
In terms of ReST APIs, the FHIR standard sets out a set of standard HTTP operations that an implementor can expose on their “FHIR Server” to allow others to interact with those resources. This includes the usual Create, Read, Update and Delete operations, and sets out specific rules on how those should be exposed through standard HTTP verbs on specific paths. For example, any FHIR compliant ReSTful API that exposes “Patient” resources would do so through a specific path –
[BaseURL]/Patient. The standard also provides a set of standard search parameters that should be used to search for resources – for example to search for a patient by ID would always look like:
[BaseURL]/Patient?identifier=12345. In addition, the standard provides a range of other standard mechanisms for more complex searches, and to retrieve groups of related resources in the response that is returned. Any system would choose how much of this they implement, and declare that in a CapabilityStatement which is also published on their FHIR server.
In addition to these standard operations on individual FHIR resources, the FHIR standard provides a mechanism for defining your own custom operations (in the form of an “OperationDefinition”). This allows a more remote-procedure-call style of API to be defined. An example might be a “Refer Patient” API, which takes a set of inputs, operates on a number of resources in a single transaction, and returns a specific set of output information. This has the benefit of hiding the complexity from the consumer, but it requires the consumer to read and understand the details of your custom operation before they can make use of it. It may also limit the flexibility of that the consumer can do with your APIs as they can only do the specific operations you have defined, and may not be able to use the underlying resources in other ways to solve the problems they want to solve. Custom operations can however be used alongside the standard operations on individual resources, so the important thing is to use them when sparingly and only when there’s a clear need for them.
This provides the basis for an API which each system could implement relatively consistently to provide access to these FHIR resources. It does not however provide a complete definition of everything you would need to build an implementation in a real system. There are a few areas which FHIR does not try to define – for example security. There are other complementary standards such as “SMART-on-FHIR” which define an approach to using FHIR alongside OAuth to secure an API. These other specific details would typically be defined by the implementor of an API in an Implementation Guide, which sets out all the details someone would need to make use of the API.
Was this article useful?17