So I was talking with one of my colleagues at Orion Health today – a clinician who has just joined us and wanted to understand what FHIR was – to a reasonable degree of detail. I thought I’d summarize our conversation here as it’s useful to record what a clinician found interesting, and wanted to know about.
We mostly covered the content side of FHIR, rather than the API/Exchange side. Highlights were:
- FHIR contains resources, where each resource represents a ‘thing of interest in healthcare’ – which could be a clinical concept like a medication, an allergy or a problem (which are called ‘conditions’ in FHIR) or a supporting concept like Patient, Practitioner or Organization.
- The ‘core definition’ of each resource in the specification only includes the elements most commonly used by systems today. In the early days this was expressed as the 80% rule – if 80% of systems exchanged that element, it was included – otherwise it would be represented by an extension (see next point). The idea was to keep the core resources small and easy to understand, and avoid the bloating that occurred when a particular concept had to have all the elements that all countries in the world needed to exchange.
- To use a resource in a real world scenario you ‘tweak’ it by adding the elements that were missing from the core (like religion in the Patient resource for example) using ‘extensions’, removing things you don’t need, changing the multiplicity (how many there can be) of elements and setting the terminologies for coded items – for example specifying SNOMED as the way of coding condition codes. This ‘tweaked’ resource is described by a Profile.
- When you add a new element (using an Extension), the extension itself is described by an Extension Definition – a resource that describes what the extension means, the type of data it can contains, any terminology it can use, how many there can be in a resource and so forth. A resource that uses that extension must have a url link to the extension definition so that a recipient who doesn’t know what the extension means can always find out – this is an important clinical safety issue.
- If a clinical resource (like a Condition) matches a profile (it only has the elements allowed, uses the correct terminology etc) then it can claim to be conformant to that profile – and the server is able to check this if it wants to. This means that a server can say something like ‘If you send me a condition resource, you must use SNOMED as the code (or even a particular subset of SNOMED), you must indicate the encounter where the diagnosis was made and the onset must be an actual date – oh, and don’t bother including a stage’. This helps to improve the quality of information being exchanged.
- A server must publish (actually make available on request) a Conformance resource that informs a caller what its capabilities are. This could be the types of resources it supports (and what it can do with them), which profiles it supports, what version of FHIR it understands and so forth. This means a client application can always understand what a particular server can do.
We talked a bit about clinical safety and governance – especially with regard to extensions.
- While the specification describes the ‘mechanics’ of extensions and profiles – and in particular the need to make the extension definitions available on line to anyone who might need them using a registry of some sort – because they contain clinical data it is critical that the definition should ALWAYS be available, and must NEVER change – for reasons that are obvious. This places quite an onus on the implementer to make sure this happens (and, incidentally, is one of the reasons that HL7 is commissioning a publicly available registry).
- We didn’t really talk a lot about the governance – if I had remembered, I’d have also pointed out that the specification itself defines a fair number of extensions, and it’s likely that there will be National registries established to contain extensions specific to particular countries.
- It’s also important that an extension is able to say whether it is safe to be ignored – or not. If the extension is about eye colour and you don’t store than information then it doesn’t really matter if you don’t understand it. If the extension is stating that the patient does not have the Condition it is attached to do then it most certainly does. By default, extensions are ignorable, but FHIR has modifierExtensions for those that aren’t.
The whole concept of ‘profiling’ – adapting the core resources for real world use – was really the most interesting part of the conversation, and we agreed that it was important that clinicians need to be deeply involved in this process – it’s an integral part of the practice of medicine (at least the recording, reporting and sharing parts) so it’s important that those of us who are going to be the most affected (the clinicians) get involved early on. While there will be tooling to make this easier, it is important to understand the underlying concepts – and it’s not that hard (when expressed the right way 🙂 ).
We talked about how you could divide the resources into 2 main groups.
- Those that represent real ‘things’ – whether clinical concepts or supporting resources
- Those that are ‘definitional’ – they describe how things work
When it comes to profiling (or ‘tweaking’ as my colleague called it), it is useful to understand the ‘definitional’ resources. These are resources (just like the ‘real things’ ones) and are stored and retrieved from a server (just like the ‘real things’). The ones that people are most likely to need to understand are:
- StructureDefinition. This resource has 2 main purposes – it describes an extension (it is the ‘extension definition’ we referred to above), and it is also the ‘profile’ – it describes the alterations to the core resource that were made for a specific use case – the ‘tweaking’.
- ValueSet. This describes the set of possible values for a coded element.
- Conformance. This is how the server describes its capabilities.
(There are others – but these are enough for the moment)
The following diagram shows how these relate to each other (the ‘definitional’ resources are in yellow).
From this you can see that the profile (a StructureDefinition resource) is the conductor of the whole system.
- It constrains the core resource definitions – removes some things, makes some of them required and so forth. Note that both are actually StructureDefinition resources ‘under the hood’ (Actually, a profile can also constrain another profile in a hierarchy if you want to). And even the core resources are described by a profile (eating your own dogfood!)
- It adds new elements by including Extension Definitions (again a StructureDefinition resource under the hood)
- It specifies which ValueSets to use for coded elements – a process called ‘binding’ (and the ValueSet in turn refers to concepts from one or more terminologies)
And other resources, in turn, refer to the Profile.
- A server provides a Conformance resource that refers to the Profiles it supports.
- A resource instance – eg a condition resource for a patient – ‘claims conformance’ to the profile. (Of course, it’s up to the server to confirm that – it’s only a claim after all!)
And finally note that the extension in the resource instance still points to the extension definition. It’s important to be able to process a resource even without knowing what profile (or profiles) a resource instance is conformant to.
You can see this working using clinFHIR. Start the application then select the Resource builder. After selecting a patient, choose a resource type – say ‘Condition’ – and clinFHIR will display all the elements of Condition. Now, behind the scenes clinFHIR has loaded the profile (StructureDefinition) for the core Condition resource from the registry server, then parsed that resource to produce the display you see. There is enough information in the profile to create the complete rendering – the datatypes, descriptions, multiplicity, required fields and so forth.
Select the ‘code’ element (by clicking on the CodeableConcept datatype) and enter a search term into the text box on the right side – say ‘asthma’. After a short delay you get a list of matching elements and you can make your selection from the list. To do this, clinFHIR examines the profile entry for this element which has a reference to the ValueSet that has been bound to it. It then calls the Terminology server which uses the ValueSet to retrieve the list of matching values to present to the user.
All of this can be done programmatically by examining information in the Profile.
What’s really cool is that because profiling uses the same mechanism, it works just as well for ‘tweaked’ (profiled) resources.
In the top bar, select the radio button ‘profiled resources’ then click the ‘Find New’ link that appears just to the right. In the dialog that is presented, select the patient resource as the resource type and click search. The profile ‘US Data Access Framework (DAF) Patient Profile should appear. Click on it, and then click Select in the upper right hand corner. (Behind the scenes clinFHIR is performing a query against the registry for all Profiles that have been made against Patient).
When the elements of the profile are displayed, note that some parts of the resource shows quickly while other parts have a delay. What’s happening is that clinFHIR first loads the profile you selected, and then for each extension described in the profile loads the extension definition for that extension from the registry. It can then use that information to build the display in exactly the same way as for the ‘normal’ elements. And notice that most of the extensions are in red – they are required. So, to be conformant with this profile you need to provide values for those extensions.
Oh, and take a look at the resource instance that is being created:
See how the extension ‘mothers maiden name’ has the value (Smith), but also has a url that points to the extension definition? The recipient can always find out what an extension means.
So – an enjoyable conversation worth recording!
Oh – we’ve been referring to the ‘Terminology Server’ and the ‘Registry’. These are the ‘roles’ that a server can assume, we we discussed in the last post.