Profiling resources in DSTU2 – part 2.

Actually, on reviewing the previous post about profiling in DSTU-2, I realize that there is a simpler way of applying extensions to a profile (in addition to the Conformance package). If you look at the Profile resource, it contains 2 main parts:

  • Metadata about the Resource/Datatype being profiled (name, identifier publisher etc) plus the name of the resource and a link to the base profile that is being modified (eg the profile that describes the core resource in the spec).
  • A collection of elements (of type ElementDefinition) each of which describes one of the elements/properties within the resource.

(To be precise, there are 2 collections of elements in the profile:

  • The differential – which describes the difference between the base profile
  • The snapshot – which describes the profiled resource completely

the reason for the two is to support tooling – we’ll focus on the snapshot for now).

So, each element describes a single path within the resource being profiled (using a ‘dotted’ notation – eg Condition.stage.summary refers to the ‘summary’ child of the ‘stage’ element, itself a child of the ‘Condition’ element (the root in this case). You could make an element required by setting the ‘min’ property to 1 – or make it unavailable by setting the ‘max’ property to 0, and so on. (There’s lots more you can do that we’ll take a look at later).

What’s interesting for the purposes of this discussion is that the element has a ‘type’ property (which can be multiple) used to indicate the datatype/s permissible for this element. This can be any of the valid datatypes (or a reference to another resource of course) – but it can also be an extension! And when it’s an extension, then the type.profile element is a uri reference to the ExtensionDefinition that describes the extension (a slightly confusing name which suggests that you can use another Profile to describe the element – this would make sense for a resource reference datatype).

So if we go back to the example from the previous post where we wanted to add Iwi and Hapu to a Patient resource, we need:

  • 2 ExtensionDefinitions – Iwi & Hapu (same as before)
  • 2 ValueSets for the valid options (same as before)
  • A Profile resource on Patient, which has 2 extensions to the Iwi and Hapu ExtensionDefinitions

And here it looks as a graph:


So which style do you use and when? Well, I guess ‘it depends’.

This way works on a single resource at a time – you’d create a profile on both Patient and Person to cover both of those resources, whereas the Conformance Package we looked at last time covered both at the same time.

It’ll be interesting to see how this works out in practice – my guess is that the Profile approach (this one) is going to be more popular initially as it’s simpler and more like the ‘old way’ of profiling (though still splits out the ExtensionDefinition as a separate resource of course). And, of course, there’s no reason why you can’t put all of the resources into a bundle. And – I guess – no reason why you can’t mix the two – have a Conformance Package that included the Profiles, rather than the Composition resource referring directly to the ExtensionDefinitions. Spoiled for choice…

We still need to take a closer look (or likely more than one look – it’s a complex beastie) but just wanted to document this alternative way of applying extensionDefinitions to a Resource…

Addendum: a comment from Grahame:

The composition is a publishing thing – the logical model of profiles is the same either way, but the composition binds them together process wise

About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

7 Responses to Profiling resources in DSTU2 – part 2.

  1. Uwe says:

    Gee, there are a lot of issues to be studied and preferably to be applied. Thank you,David, for your insight.

  2. David Hay says:

    Thanks Uwe – though on properly reading the spec (and looking at the examples) it was pretty straight forward – I felt a bit of a D’oh moment 🙂 …


    • Pardha says:

      Thanks David,I’m new to FHIR and having experience on HL7 2.3.But Now i want to understand the resources and actual process. If you provide Video series then it really help full for me.

  3. Pardha says:

    Thanks David. iam using FHIR and created some resource on spark. i have some questions. Shall i send those questions to your personal mail id ?

    • Mirjam Baltus says:

      If the questions are Spark related, you can also send them to: spark (at) furore (dot) com.

    • David Hay says:

      Hi Parda – if they are general questions then just post them here – or to the FHIR list server – others may have input or be interested. If specifically related to spark (probably not) then Mirjam has kindly supplied a better location – spark (at) furore (dot) com


Leave a Reply

%d bloggers like this: