FHIR QA

We’re looking for volunteers to help out with QA (Quality Assurance) for the STU3 FHIR specification.

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:

 

 

Thoughts about updating Registries

In New Zealand we are lucky enough to have had a national patient registry for some years which serves as a unique identifier of patients in New Zealand – the National Health Index or NHI. The Registry is an instance of an EMPI (Enterprise Master Patient Index) and currently  exposes a SOAP interface that can be accessed by clients across a protected network.

In order to make it available for more users we are working in a project to expose a FHIR API that will offer similar functionality to the existing SOAP one, be simpler to use, available across the public Internet and so accessible to a wider range of clients in support of the healthcare ecosystem. We’re also looking at similar work for Provider registries.

Read more of this post

Changing a ValueSet in a profile

I learned something today.

Actually, most days I do learn something (and occasionally remember it later on) but this one is worth recording here.

Read more of this post

Converting v2 to FHIR

At the recent Working Group Meeting in Montreal, I participated in the ‘v2 to FHIR’ stream – focused on how can the HL7 community give advice to implementers about converting v2 messages into FHIR bundles.

Broadly there are 2 approaches to this conversion:

  • The creation of a FHIR message bundle that mirrors the contents of the v2 message, and is intended to be an equivalent representation, behaving in the same way as v2 messages
  • Using the contents of the v2 message to update a FHIR server – perhaps extracting Encounter resources or creating a Bundle that is intended to act as a ‘transaction’ bundle against a FHIR server. I think this will be a much more common use case.

In either case, it’s desirable that HL7 should provide the mappings (insofar as that is possible in v2) from v2 to FHIR.

Read more of this post

Creating a Resources model

In another page, we discussed how to use the Logical Modeler to create an Information model. Now let’s think about how to create a ‘Resources’ model

To recap the previous page:

  • The Information model represents the data from the perspective of the Clinician, irrespective of what FHIR resources (and other artifacts) are required to represent it
  • The Resources model takes that information, and re-casts it in formal FHIR resources – indicating which elements in the resource are needed, and extra elements (extensions) and changed valueset bindings. In theory, it should be possible to automatically generate the FHIR artifacts from this model, though there is still some work required to achieve that (and it will only work for simpler Use Cases – this can get complicated!

I’m going to assume that you’ve read the previous page, which covers the basics of using the Modeler, and focus on the differences for a Resources model.

As stated above, the purpose of the resources model is to act as a ‘bridge’ between the clinical and the technical world. To achieve this, it goes hand-in-hand with another clinFHIR tool – the Scenario builder. The two work together as follows:

  • The resources model is used to identify the resources that we’re going to need to represent the clinical use case.
  • The Scenario builder then takes those resources and describes the references between them – displaying them as a ‘graph’ of interconnected resources. It also allows you to enter real data into the resources, to help make sure that you have all the elements you need.

It is expected that this will be an iterative process – based on entering real data, the resources model may need to be updated – indeed the Information model might also be reviewed.

Start by creating a new Logical Model or a ‘multiple resources’ type. (Incidentally, you may wish to have the Information model in another window so that you can refer easily to it.) Here’s the Information model we developed for the Discharge Summary:

 

From this model, and knowing that this is going t be represented we can identify the following resources that we’re going to need:

  • A Patient resource
  • An Encounter resource (for the admission details)
  • A List resource with associated MedicationStatement resources (for the medications on admission)
  • A List resource with associated AllergyIntolerance resources (for the allergies)
  • A Composition resource to represent the document metadata.

You add the nodes representing the resources in exactly the sam way as before. When adding the node, set the data type to ‘Reference’, and select the appropriate resource type from the dropdown. Here’s an image of adding the Patient resource:

If you want to indicate which elements of the resource will be needed, add a ‘child’ node to the resource, and select the appropriate element. There’s a shortcut you can use – after clicking the ‘add element’ link, immediately select the mapping path in the bottom left (the tool knows what the parent type is, so can present the correct list). After selecting the element in the list, the name and the datatype can be automatically selected. (If there’s more than one possible type, the first one will be selected). You can change these if you want to…

Here’s a screen shot as you’r selecting the element (just start typing the name):

and here it is after the element has been selected

 

And really, that’s about all there is to it. There is a lot of other data you can enter if you need to – for example bindings to valuesets or to extensions, den]pending on the particular requirements.

Here’s the model created for the Discharge Summary:

Note that I used the mapping tab for this display as it gives a better view of all the references as well as the mappings. I also hid the selector pane (the left one) to give more screen real estate.

Next up on our path towards FHIR is the Scenario Builder.

 

 

 

Configuring conMan: Track definitions

The Connectathon Management Tool (code named conman) is a tool that is intended to facilitate the running of FHIR based Connectathons. It can be used by anyone for any event, but does need to be setup for each event – contact David Hay if you want this to be done.

The overall design of conMan is that there are any number of tracks, each of which can have any number of scenarios. Each scenario can, in turn, have any number of actor roles (note that roles are shared across all of the tracks in the event – not confined to a single track or scenario).

Conman supports both technical and clinical connectathons.

  • A technical connectathon is used for testing actual interoperability between systems. It involves exchange of FHIR resources between a client and a server (currently only two way exchange is supported), and has the ability to record whether the interaction between the 2 roles was successful or not.
  • A Clinical connectathon is more about validating that a particular set of resources (and profiles on those resources) accurately represents the clinical scenario being tested.

Although the overall concept is the same between the two, there are a number of differences. This document focusses on the technical connectathon. See this page  for details of the clinical one.

Adding/Editing tracks

To create a new track, start conMan using the link to the specific event. For example, the following link will load the Australian Terminology connectathon:

http://conman.fhir.org/connectathon.html?event=austerm

or for the the HL7 May Connectathon:

http://conman.fhir.org/connectathon.html?event=cologne2018

(you might see the pattern here 🙂 )

If there any tracks already defined, they will be displayed in a row to the left – and they can be edited by clicking the edit link (Screen Shot 2018-03-20 at 7.06.13 AM) in the display box. To add a new link, click the ‘Add a new Track’ link. This will display the Track create/edit dialog:

There are a number of fields you can enter on this form.

  • The track name is the label that you see in the main ConMan display. Keep it short and descriptive – 2-3 words only.
  • The track lead is the person who is managing the track. The person needs to have been entered into ConMan before the that track is created (though you can go back and add it later). The track lead is optional – but if entered then only they can make changes to the track. (Note that overall security is quite loose at the moment, it is gradually being tightened). It is generally a good idea to specify a track lead.
  • The details page is a link to any external web page – such as a wiki. This enables you to have a lot more detail about the track that can (or should) be entered in ConMan. You can add other links as well, but this is the ‘main’ one for the track.
  • The track type is used to distinguish between technical and clinical tracks as mentioned above. There is only a single technical option – the clinical tracks have 2 options:
    • Logical Model Review allows the user to enter sample data in a form generated from a Logical Model and make comments.
    • The Scenario type allows the user to assemble resources (and Logical Models) into a web of resources to represent the scenario being tested. It is very similar to the Scenario Builder in clinFHIR.

At the bottom of the screen is a tabset with 3 tabs:

  • The description allows for more detail about the track – more than the name, less than the page in the wiki link. It is markdown enabled.
  • The links tab allows you to enter any number of links to additional pages that are relevant to the Track. Each link has the Url and a description about the page. When the track is selected in the app, the users will be able to click on the pages to view the details (The links will open in a separate tab).
  • The endpoints tab lists specific server endpoints that are relevant – such as a link to a FHIR server.

 

When you’ve entered the details of the track, click the ‘Save’ button to add it. Note that you also have a Delete option when editing a track. Be careful when deleting – the track cannot be restored after deletion! (If a track lead is specified, then only they can make changes – including deletions.)

Adding/Editing Scenarios

As stated above, a single track has any number of scenarios.

To add or edit a scenario, first select the track in the main app, then either add a new scenario or edit an existing one:

This is the scenario edit screen that is displayed:

 

  • The scenario name is (like the track name) a short label for this track.
  • The description (which is MarkDown enabled) has more detail. This field will automatically expand as you type to support as much detail as is required. It is markdown enabled.
  • The review purpose allows you to be specific about the purpose of testing this scenario (it does make more sense in the context of a clinical track type).
  • The links entry allows you to create linkages to external pages. This is very similar to the links feature for the track, and is useful for resources about the scenario – perhaps much more details about the scenario or reference information.

To the right is a tabset with 5 tabs:

  • The ‘Pre’ tab contains any preconditions for this scenario
  • The ‘Action’ tab describes the specific actions needed for the scenario.
  • ‘Steps’ goes into even more details about the actual steps in the scenario (generally you would have either action or steps – not both – though the app doesn’t enforce that). Steps can be deleted and re-ordered, and can contain MarkDown. Currently you can’t edit a step – if you need to do this, then select & copy the text of the step to be edited, delete it, create a new one, paste in the text box, edit, save and move into position.
  • ‘Success’ describes what a successful completion of the scenario would be
  • ‘Roles’ lists all the roles in the Connectathon event, and allows you to indicate the ones that will be required for this scenario. You can also create new roles from this tab.

Videos on clinFHIR Scenario Builder and Logical Modelers

So in a fit of enthusiasm I offered to do a short demo of clinFHIR at the CATonFHIR event in the UK in a couple of days. As it turns out, the reality of the timing is that this would be at 2am my time (New Zealand). Of course I’d be happy to do this to support FHIR (and have done it before), but when the organizer Philip Scott suggested I record a video that they could show instead of a live performance I jumped at the chance!

And having done one, a second wasn’t that hard…

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

Building a set of resources in FHIR

One of the primary goals for clinFHIR is to help people who are new to the standard understand how it works – and increasingly these are clinicians whose interest is less in the technology and more about how FHIR can be used to represent the clinical information they wish to exchange.

While the current app does allow this, it has been aimed more at the people actually developing the resources than the casual user, and so can be time consuming to develop sets of resource instances that represent real world scenarios.

The component described by this post (called a simple builder – though a better name is needed!) is intended to allow someone completely new to FHIR to build sets of resources that represent clinical scenarios, to help them understand how the resources can be linked together – rather like Lego is used to build a complete model.

Read more of this post

:)