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: