Building a profile in the new clinFHIR

So I had a question from someone who was wanting to develop some profiles using clinFHIR and not sure of the best way to approach this. I’ll write in more detail later on, but as there has been a substantial change in process and User Interface from the previous version, I thought I’d just do a quick post about how the new process is intended to work.

Because the focus is really on helping folk new to FHIR rather than being a comprehensive profiling tool (use Forge for that), the starting point is a Logical Model, from which the real profiles can be generated. To do this, there are some constraints in the way that the logical models are created – and the generated profiles themselves cover only a small subset of the profiling functionality that FHIR supports.

There are a number of clinFHIR modules that you can use for this. These include:

  • The Logical Modeller – builds the model and generates the profile (StructureDefinition resource)
  • The Scenario Builder – allows you to assemble resources based on profiles (and logical models for that matter) to represent a particular Use Care case
  • The Extension Definition builder will create a – well – Extension Definition (actually a StructureDefinition resource
  • The CodeSystem builder allows an ‘ad-hoc’ CodeSystem resource (with associated ValueSet) to be built. The idea is to allow you to build a ‘quick and dirty’ ValueSet that you can bind to an Extension Definition as part of the design process (again, clinFHIR is intended as a training & analysis tool). See here for more detail.
  • The ValueSet builder for simple SNOMED based ValueSets.

Here’s a link to a bit more detail, and here are some videos

So the overall process goes something like this (assuming you are wanting to profile a single resource).

  • Select the servers (I use HAPI STU-3 myself, others should work but this is the one I test on).
  • Create a new logical model, with a model type of ‘Single Resource’. Select your base resource and check the ‘copy elements into model’ checkbox. This will create a new Logical Model that has all the fields from the core resource.
  • In the designer, remove the elements you are not supporting and add a new element for each ‘extra’ property you want to save (this will become an extension)
  • For each of the extra elements, set the FHIR mapping path (bottom left of the edit dialog) to an extension path (eg Encounter.extension) and a ‘find’ button will appear that will allow you to select the extension definition. You can type in the url directly if you know it, but it’s better to select it. If necessary, you can save the model, use the Extension Definition builder to create it, then come back and select it.
  • Once all the changes have been made and saved, select the ‘Model’ tab to the upper right, and then the ‘Generate Profile’ link which is at the lower right. All being well (for example all elements in the model have a FHIR mapping path), the app will generate a standard FHIR profile based on the logical model (with a name derived from the logical model name)
  • You can then use the Scenario Builder to build resource instances based on that profile.

If you want to create a new ValueSet to bind to a coded element – either an extension or a core element, then you have a couple of options.

The ValueSet builder is good for building simple SNOMED based ValueSets, and the CodeSystem builder is useful for ‘ad hoc’ code systems (it automatically builds an associated ‘select all’ ValueSet), good when you just want to put something together to illustrate a point, or to list the potential values and have someone else find them in SNOMED. Note that there are much more advanced tooling available for building ValueSets – like Ontoserver for example

You don’t need to use clinFHIR to create the extension definition (or you shouldn’t), but you’ll need to upload them to the Conformance server yourself.

As always this is a work in progress – I’ve only just got the basic functionality working so there’s a way to go before it is robust enough for use (with the May ‘Clinicians on FHIR’ event at the next Working Group Meeting being the deadline) but I did want to let people know the development direction. The scenario builder in particular right now will choke on complex extensions at the moment, and support for the more complex resource types (like CarePlan) need some attention (though it will now save resources to the Data Server).

I intend to add a bit more capability to the profile generation – in particular simple slicing – but it will never be a match for Forge! I also intend to connect the Extension definition builder to Simplifier – so that Extension Definitions you create can be easily saved there, and also to enhance the ‘find an extension definition’ capabilities – this will be really important moving forward to minimise the creation of extension definitions that represent the same thing.

But I think (hope) this is going to represent the ‘final’ version of clinFHIR (from an overall functionality / UI perspective)!

This is really short description, I’ll do a longer post – or maybe a video – when the dust has settled on the FHIR QA process!

Comments welcomed…


About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

2 Responses to Building a profile in the new clinFHIR

  1. Miguel Angel Fonticiella Torre says:

    Hi David,

    using Logical Modeller, can I extend a complex dataType? I want to create an extension for to include the second family name, but following this post I can only know how to extend Resources.


    • David Hay says:

      Hi Miguel – right now you can’t – and it’s kinda complicated to implement, so not sure if I’ll go there. You’d be better off using the official tool (Forge) for this stuff (and remember that clinFHIR has a focus on education / design rather than attempting to be feature complete)…

      Can you give more detail on the use case? The family name multiplicity was reduced to 0..1 in R3 to make it simpler to use – if this isn’t working for you, then the Patient Administration committee would be interested in knowing why, I’m sure…

      Also note that there are some common extensions here: . (though CF won’t support them I’m afraid)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: