So a couple of weeks ago I posted on a new component that has been added to clinFHIR – a tool that will generate Logical Models – models of something that uses the FHIR infrastructure but doesn’t generate ‘real’ resources. The idea is that it is used as a requirements gathering tool when when interacting with clinicians to describe what information and processes are needed to meet some interoperability related need.
Since then, we’ve added a few new capabilities to the tool, and also further refined how it can work with the other clinFHIR components to provide an ‘end to end’ solution that starts with an idea, and ends with the various FHIR resources (profiles, valueSets, extension definitions etc) that will be needed. This post starts a ‘mini series’ that describes how this could work (and do note that this is just my idea – there are lots of other ways that this could be done).
I’ve also got in the back of my mind the FHIR Devdays in a couple of weeks where I’m leading a clinician related track – this will help flesh out what we’ll be doing there.
Let’s start with the new functionality in the modeler.
- There’s the beginnings of a way to capture comments against a model. It’s pretty basic right now – at the upper right is a tab labeled ‘Comments’ which shows a set of threaded conversations about the current model. You have to be logged in to add a comment (and the email is displayed for each comment) but anyone can read.
- The mind map now looks more ‘mind mappy’ with the elements of the model arranged horizontally from left to right. Otherwise it works the same – it’s automatically generated from the model, and selecting an element will show the details and allow you to edit it or add children.
- There’s a new tab labeled ‘Coded’ that displays all the elements that are bound to a ValueSet (code, Coding, CodeableConcept) and the url of the ValueSet – if you’ve specified that. The idea is to help identify – and find or build – the ValueSets you need in your model.
- The tab labeled ‘References’ also displays a subset of the elements in the model – those that are references to another model. I’m imagining that many of the models will actually become a profile on a single resource (though some won’t be) and so you’ll start by creating some of these ‘common’ models first (like patient and clinician’s) and then refer to them from subsequent models.
- The json and treeData views have moved to be sub-tabs of a ‘Dev’ tab. These views are only really needed for those interested in the internals of the tool.
- The tool should work against any STU-3 server (at the time of writing there’s an issue with Grahames server, but HAPI seems to work fine)
(There are screenshots of some of these tabs at the bottom of this post)
It also occurred to me that the modeler could be of value to a couple of other types of user:
- Those who are building new resource types. These do need to be developed in the proper tooling (based around Excel spreadsheet models currently) to be included in the specification build, but being able to quickly show and modify a proposed resource type might be helpful in the early days. And the ability to make comments might also be useful…
- There’s a proposal for custom resources in FHIR – resources that use the infrastructure but are not part of the FHIR specification. This is a somewhat controversial proposal at the moment, as the ability to share these custom resources is very limited compared with the official ones – but there are scenarios under which they could be useful. For example, you could build an EMR that uses custom resources internally, converting to official ones during exchange (and Grahame has proposed a mapping language that you could use for this).
But back to the original purpose of the modeler – collecting requirements for creating proper FHIR profiles. How would the overall process work? I can imagine a number of steps.
The first step is to document the business requirements – what are you wanting to do. There will likely be aspects of workflow and/or process involved in this step, but the parts we are focusing on here is the information that needs to be shared – and there could potentially be more than one model we need. Domain knowledge is required for this step, and there isn’t (currently) any tooling in clinFHIR to help.
The next step is to use the logical modeler to create a structured representation of the information to share – the model. This could really be done by anyone – you do need to be familiar with the FHIR datatypes, and ideally the basics of FHIR (especially referencing between common models/resources) but really domain knowledge is the most important.
You also need to decide if you are modeling what will become a single resource (eg an allergy intolerance) or a collection of resources – like a list, document or message. In the latter case you might want to split the design up into a number of referenced models to make the next stage simpler.
This step can take some time as getting agreement from multiple people is not always straightforward – hopefully the ability to make comments against the model will help here.
There are a number of outputs from this stage.
- The models themselves will become profiles – both constraints and extensions on resource types
- The ValueSets we’ll need for the coded elements (which is why there’s a separate tab in the modeler for these). We’ll consider ValueSets in more detail in the next post.
The final (almost) stage is to create or locate the FHIR artifacts – ValueSets, Profiles and Extension Definitions that represent the models in FHIR-space. Right now this will largely be a manual process using tooling (either in clinFHIR or Forge) and will need to be done by someone who understands FHIR reasonably well. However, it may be possible to automate the process (possibly using Grahames mapping proposal) by constraining how the modeler works – this needs more work though. And do note that Forge is much more comprehensive than clinFHIR. It may be that you use clinFHIR in the early stages to get the artifacts ‘mostly’ right (or exemplars of what you want), then Forge to complete them.
My guess is that there will be a ‘feedback loop’ at this point right back to the original model as the process of mapping to FHIR resources will likely produce suggestions that may not have been considered in the first stage – after all, a lot of people have contributed to the FHIR resources! So there will be one or more ‘cycles’ of development until the FHIR artifacts are finalized. There’s currently no direct link between the model and the FHIR profile – something to work on.
So I think that’s enough for a single post. In the next installment, we’ll take a logical model (probably Adverse Drug Reactions) and think about how we’ll generate the real FHIR artifacts from that model.
In the meantime, here are screen shots of the main parts of the modeler as a reference.
The main screen with the ADR Model selected
The mind map: (colours & icons still need attention)
The table view – with the comments tab selected
Coded elements summary
