Terminology services

Just a short post to call peoples attention to terminology services in FHIR. Rob Hausam (who co-ordinates the Terminology track at the connectathon) made the excellent comment in the Zulip chat that terminology is a ‘cross-cutting’ concern that can be integrated into many different applications – and tracks at connectathon.

Read more of this post

Supporting SNAPP: Accessing New Zealand Medicines Terminologies With FHIR Terminology Services

A guest post from Peter Jordan – author of the Patients First Terminology server that will be available for use at SNApp, and frequent HL7 FHIR Connectathon attender…

Take it away Peter…

As those developing healthcare applications for the local market are well aware, and overseas developers preparing for the ‘SNAPP’ event at the upcoming SNOMED conference in Wellington, are becoming aware, New Zealand has its own medicines terminology. Interacting with this terminology – broadly known at the NZ Universal List of Medicines (NZULM) – is one of the many challenges facing SNAPP participants.

Read more of this post

‘Extending’ a ValueSet in a profile

In the last post we talked about ValueSets and CodeSystems – and in particular how the ValueSet can be thought of as the set of possible values from one or more CodeSystems for a particular element in a given context.

As you know, the spec provides ValueSets and bindings for all coded elements, and a common need when profiling is likely to be to ‘extend’ the set of possible values – take the contents already in the ValueSet and add others. What’s the best pattern to do that?

Read more of this post

A simple app to help using the Mapping Language

So I’ve just been at the FHIR devdays in Amsterdam which was really interesting (of course – attending a devdays is a ‘must do if possible’ for FHIR implementers). One of the presentations I attended was on the FHIR mapping language – more specifically an implementation of the FHIR mapping language by Firely and Healex   (currently in a ‘technical preview’ state).

I’ve always been interested in the mapping language, and its ability to create portable mapping files – allowing specialists to create the mapping instructions, which can then be used by any compliant engine, as the following image illustrates:

Read more of this post

Creating a ValueSet

To understand how to view and  create ValueSets using clinFHIR, follow this link to a post I wrote last year – it should still be up to date.

There are a number of servers that support terminology services – I suggest the HAPI-3 server at the moment

Terminology Services in FHIR

I must admit I haven’t paid as much attention to Terminology as I should.

I do appreciate how important it is – most (if not all) resources in FHIR have multiple coded elements that refer to a terminology of some sort, and a common understanding of concepts is one of the key parts of interoperability, but until Grahame asked me to talk to this subject at the recent Brisbane Seminar & Connectathon, I’d regarded coded items as just another datatype.

But DSTU-2 brings a whole new set of possibilities to the picture, so let’s look at how that helps us.

Read more of this post

Creating an Extension Definition – part 3: Coded items

A common data type that is likely to be added in an extension are coded types – those where the value in an instance comes from a pre-defined set of possible values. There are a couple of extra things that you need to do for these.

First, a quick review of the basics.

Read more of this post

Configuring ConMan in a clinical connectathon.

ConMan (Connectathon Manager) is a tool to help manage FHIR connectathons. In a previous page, we described how to configure the tracks and scenarios being tested (with a focus on technical connectathons). Here, we’ll describe how to configure conman for use in a Clinical Connectathon. You should review the previous link before starting – in this page we’ll describe the features that are specific to clinical events.

There are 2 types of clinical review (each represented by a track type).

The Logical Model Review track focuses on a single logical model. The model needs to have been created in the clinFHIR logical modeller (as it uses some of the extensions used by this application – and also supports a defined subset of Logical Model capabilities.) There are a number of different ways that a Logical Model (LM) can be ised:

  • It could be a proposed profile on a single resource. When the model is created, a ‘base type’ is specified – which will be the type being profiled. Generally, you would include the existing elements from the resource type, and then amend them in the Logical modeler tool in clinFHIR. The advantage of this approach is that it makes it easy to update and validate the proposed profile by clinicians, then  the profile can be generated (automatically or manually) by FHIR experts.
  • Another possibility is a LM that represents a more complex structure – like a document. In this case the base type is a Composition resource, and the referenced resources added as elements off the model. For example, you could set the Composition.subject element to be a reference to a Patient resource, then add child elements off that element in the model to represent the specific patient elements you might want to be present in the document (or where you might want to fix a value – like an identifier system.

The Scenario track is very similar to the existing scenario builder in clinFHIR. It allows you to build a graph of resource instances to represent the scenario. The main difference to the scenario builder is that it is more tightly associated with the pre-defined scenario, and that the data entry for the structured data is via a form rather than off a hierarchal tree. (Though there are still dialogs for the individual datatypes.

Creating the track

Here’s an example of creating a Scenario type track.

Note that we’ve used markdown in the description (and used the preview button to see what it will look like). Note also that there’s a new tab – Track configuration – that has appeared in the tabset at the bottom of the dialog. Here’s an example:

For a scenario type track, there are 2 sets of configuration:

  • The Terminology server is responsible for terminology operations – such as looking up a value from a ValueSet
  • The Conformance server is where conformance resources like the definition of resource types is stored.

Default values are supplied – but you can provide different ones if necessary.

Creating a scenario

Once the track has been created, one or more scenarios can be added. (See the previous page for details)

Here’s an example of a scenario concerning a Problem List.


The purpose of this scenario is educational rather than for clinical review, and the Resource types required are listed, along with the steps required to complete the scenario. Note that in addition to the core resource types, there’s also a logical model – described as ‘A simplified Condition’. This is a LM that has been created in the clinFHIR logical modeler based on a core resource type (same as can be used in the LM Review track type). The idea here is that it allows you to use the Logical Modeler to create what will become a profile, then use it in the scenario builder to determine if it is fit for purpose. (There’s a bit of an overlap between the 2 clinical track types here – you’s use the scenario type if you wanted to see how the profile fits with others in a scenario, and the LMReview type if you just wanted to focus on the LM).

(If you do add one or more LMs to the scenario, then you need to have the URL where the LM can be found. To find this in the Logical Modeler, load the model, then click the ‘model’ tab to the upper right. The url is in the second row, labelled ‘Model Url’)

Building a Scenario instance

Once the scenario has been built, it’s then possible to build the actual resource instance graph that represents the scenario. Each conman user can create a graph for each scenario – the graph is saved on a database, so can viewed from any browser. In fact, there’s a tab in the main conman screen that will show all the instance graphs created by all users for a given scenario – useful when trying out different approaches to the same scenario.

Theres a short video that shows how a scenario like this is completed in the scenario builder tab in conman, and here’s a screenshot of a completed graph:



Contained resources – MedicationStatement

Continuing our ‘mini-series’ on the SNapp event, one thing you may come across when consuming MedicationStatement resources are ‘Contained’ resources. We’ve talked about them before, but in the interest of having all the SNapp information in the same place let’s take a look at what they are.

Read more of this post

Using a FHIR Observation

These are some notes written by Lloyd, Grahame & Eric about using Observation in practice. I’ve copied this directly, here so I always know where to find it. You should refer to the source for the most recent version.

Read more of this post