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