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.