Creating a Profile

clinFHIR can also be used to create simple FHIR profiles. Note that the emphasis is on ‘simple’ here, as only a subset of the profiling capabilities in FHIR are supported – indeed in many cases you will use clinFHIR to work up the requirements, and use the Forge tool to generate the actual profile.

To create a profile, you also use the Logical Modeler. Because a Profile is a ‘statement of use’ for a single resource, unlike the other models (Information Model & Resources Model), when you create the profile you select a ‘Single Resource’ type, and the type you wish to profile. In the screenshot below, we’ve selected the Condition as the base type – in other words we’re creating a customized Condition profile. Note that we’ve left the ‘Copy elements into model’ checkbox checked.

After saving the profile, we get a model that is a copy of the base Condition resource type – which we can then modify as we need. Let’s go through the possible changes we might make.

By the way, we don’t have to pre-populate the model with items from the base resource type. If we wanted to, we can unselect the ‘Copy elements…’ checkbox and create the model in whatever structure we want to. But for each element we add, we need to ‘map’ it to an element from the underlying resource type. Otherwise, it is the same process described here.

Removing an element we don’t want to support

Simply select the element in the designer, then click the ‘Remove Element’ that appears to the right in the detail pane.

‘Fixing’ part of an element

Sometimes you want to indicate that a particular element (or part of an element) has a fixed value. A common example of this is for an identifier where you want to indicate that it must be a known type – eg a National Identifier like the NHI in New Zealand. This means that the ‘system’ child element of the identifier has a specific value.

To do this, we create a new element in the tree, and map it to the underlying ‘identifier’ element. Here’s a screen shot of doing that. Note how clinFHIR is able to give you a list of possible values – because you indicated that the model is based on Condition (technically we call this a ‘constraint’)

Next, we create a ‘child’ element for the new identifier, bind it to Identifier.system, set the fixed value and we’re done. Here’s what it looks like in the designer.

 

So we now have 2 elements in the model that are mapped to Condition.identifier – one that has a fixed value for system, and one that does not. So this allows for multiple identifiers, but specifies the system for one of them. When clinFHIR generates the profile, it will create a ‘slice’ that represents this in the profile.

Changing the multiplicity of an element 

Following on from the example above, what if we wanted to indicate that the nationalIdentifier was required to be there, and that there should only be one of them? To do this, edit the nationalIdentifier element, and set the multiplicity to ‘1..1’. This specifies that there can only be one – but it must be present.

Adding a new element

Often, we’ll want to add a new element to our profile – we call this an ‘extension’ in FHIR. All extensions need to have an ‘Extension Definition’ that describes what it means (and an ‘instance’ of a resource based on our profile will point to that definition). You don’t need to have this definition available at the time of creating the model – but it will need to be there before the profile can be generated.

Start by adding an element to the model, setting the mapping to ‘extension’ as shown here:

Note that after entering this path, we have the ability to specify the url of the Extension Definition or find it if it is on the currently configured Conformance server. We can also enter a Concept map – this can be ignored for the purposes of this discussion.

Changing a binding for a coded element

Coded elements in FHIR are ‘bound’ to a ValueSet that describes the possible values for that element. (It’s a bit more complex than that – take a look at Binding and a more general discussion on coded elements). Most of the elements in the spec have a ValueSet specified, but we can generally change this in our profile if that suits – the exception being ‘required’ bindings that cannot be changed.

For example, the profile that we are creating might be for use in an Emergency Department and we might want to have a ‘default’ set of the most common conditions to be used – it might be used to populate a ‘pick list’ for example. Our profile then ‘binds’ to that ValueSet with a given strength.

To do this, select the element in the designer and click edit. If it’s a coded datatype, then there will be a link (to the upper right) that allows you to select the ValueSet from the ones on the Terminology server (or to enter a url directly). Again, it’s not something you need when creating the model, but it is needed before the profile can be generated.

 

So these are the main ways to profile a resource. There are a number of views (tabs in the middle panel) that are helpful as you build the model. In particular the ‘Map’ view (shown below) gives a nice summary (Note that I’ve hidden the selector (left) and detail (right) panes to give more screen real-estate as the view can be quite large.

Once the model has been built, generating the profile is almost an anti-climax. Select the ‘Model’ tab in the right pane, and click the ‘Generate Profile’ button on the bottom. Provided that there are no errors found (missing mappings, missing extension definitions & ValueSets being the most common) a summary of the profile is displayed, and the actual profile can be generated and saved.

and we’re done!