Profiling FHIR in DSTU-2

As we mentioned in the previous post, profiles have changed significantly in the next DSTU.

Profiling is a really important part of FHIR. The resource themselves are designed to be quite generic ‘building blocks’ that can be used in many different contexts. If you take a look at one, you’ll notice that almost all of the properties are optional and even where coded properties have Terminologies assigned to them, these are often quite ‘loose’ and designed to be amended by a Profile

It’s the profiling process that takes these generic blocks and applies them to specific Use Cases. There are many references in the spec to Profiling – here’s the one to start at.

In DSTU-1 (the current version) the Profile resource is quite a large and complex beast that contains both the definitions of extensions and the restrictions on specific resource properties, and this complexity has caused a few issues for implementers. For this reason – but also to promote the simpler reuse of extensions, the profiling mechanism has been re-designed in the next DSTU.

The major changes can be summarized as follows (all links are to the draft spec and will likely change):

• Extension definitions are now a separate resource (previously they were just a part of the profile resource). This makes it simpler to re-use extension definitions for different Use Cases, which improves overall interoperability.
• The Profile resource is now just concerned with constraints on the base elements of the single resource that it describes. For example setting the multiplicity of an element, specifying a datatype or a different terminology for a coded element.
• The ValueSet is unchanged as the collection of options for a specific coded resource property – a process called ‘binding’.
• The term ‘Profile’ as an expression of describing how FHIR is used in a particular Use Case has been replaced by ‘Conformance Pack’. This is similar to an Implementation Guide (though an Implementation Guide is likely to be larger than that, and may well contain multiple Conformance packages). A Conformance Pack is actually a Bundle that contains a Composition resource describing the purpose, and all the artefacts (resources) needed to describe the implementation such as:
  • Profiles
  • ExtensionDefinitions
  • ValueSets

(There are other resources that can be used as well – we’ll look at them in a later post)

In summary, what was a single big resource that describes how to apply FHIR to a Use case in DSTU-1 is now a bundle of smaller, more re-usable resources.

Note that the way that a resource instance contains an extension that points to its definition hasn’t changed (though it now refers to an ExtensionDefinition rather than a Profile)

Let’s take a simple example of how this works.

In New Zealand the Maori population have the concept of iwi (tribe) and hapu (sub-tribe). These are characteristics of an individual, and so would apply to a Patient or to a Person resource. The values for each of these is drawn from a fixed set of values.

So the resources that we are going to need are as follows.

• 2 ValueSets – one for iwi and the other for hapu – that contain the possible values for these elements. As there isn’t (to my knowledge) an external terminology service that contains these values, we’ll define our own codes within the ValueSet. We’d probably propose that these ValueSets become the ‘official’ ones for New Zealand.
• 2 ExtensionDefinitions – again, one for iwi & the other for hapu. Each ExtensionDefinition describes its element, and contains a coded type with a binding to the ValueSet. We set the ExtensionDefinition.contextType to ‘resource’, and have 2 ExtensionDefinition.context elements (Patient & Person).
• 1 Composition resource that describes what this Conformance Pack is all about, and has the links (via the sections) to the other resources that comprise this pack.
• Optionally a couple of Profiles on Patient and Person. We don’t strictly need them for this example as we’re not constraining those resources, but it’s likely that in practice we’d create a pack that describes the ‘New Zealand’ interpretation of Patient/Person – for example constraining Patient.identifier to use our National Identifier – the NHI.
• Optionally a Bundle that contains the resources when viewing them as a group.

Here’s what it looks like as a Resource Graph:

So how do we refer to this pack? Ie when someone wants to know ‘how do you represent a patient in New Zealand’, how do we refer to this pack? Well, there are (at least) a couple of ways.

• We could package all the resources into a Bundle and send it to them (eg as a file)
• We could refer them to the Composition resource on line, and then they could follow the resources references (via Composition.section) to all the other required resources.

The second option seems the simplest – and more in keeping with the on-line/distributed nature of FHIR – though it’s up to the individual implementation of course.

So there you have it – the next iteration of Profiling in FHIR!

We’ll look at how the individual resources are defined in more detail in later posts, and the Viewing Tool will continue to be enhanced to make it simpler to find and visualize them, but hopefully this post gives an overview of how they have changed.

In the mean time I wish you all a very happy – and productive – New Year!