A sense of history with clinFHIR

I’m definitely going to finish off the series on building extensions (we have to cover coded extensions) but I must admit I’ve been a bit sidetracked in the last couple of days. You see we had a call with the ‘Clinicians on FHIR’ team talking about plans for the upcoming event at the WGM in Spain, and during the course of the discussion, Emma asked if clinFHIR could show versions of resources as she wanted to describe medication reconciliation.

At the time I said we could certainly do something like that (though I’ve not yet got that working in the Scenario Builder) but after the call I was thinking about it, and it occurred to me that what we really need is to be able to version scenarios – so we can show how they are built up, and potentially to model a workflow like fulfillment of an order or reconciliation.

So, may I present…

If you load the latest version of the Scenario Builder and load (or create) a scenario, you’ll see a link in the navbar – ‘show version’ (under the ‘Import’ option). Clicking on that will display a version bar across the middle pane (once a scenario has versions the bar is shown automatically).

Each version (there will be one at the start) is in a little box, and clicking on the box shows that version (it works best when the graph tab is displayed). If you have the most recent version displayed, a plus (+) sigh is shown to the far right of the version bar and clicking that will ‘freeze’ the current scenario as a version. You can carry on editing the scenario and clicking the + button to create a series of ‘frames’ that represent the story you are trying to tell.

Here’s a simple example.

We start with a Patient, a List and 2 MedicationStatement resources. Note that all resources have a reference to Patient. A simple medication list.

Now let’s pretend that we have another list – maybe from a CCDA – that also has a list for the patient, but the list of meds is different – there’s atorvastatin in there as well (How do they make up those names!).

So what we want is to update the patients Usual Medications list with atorvastatin.

(btw – note that in the interest of clarity I’ve removed the references from most of the MedicationStatement resources to Patient. They will be present in a real scenario of course. To do that, select the MedicationStatement resource instance, and in the tree view of that resource to the right (Current Resource Views > Tree view), select the reference to Patient, and click the delete button that appears. Note that this will remove the whole node – if you try it on List.entry you’ll delete them all)

First, we update the ‘Usual meds’ List by adding a reference to the atorvastatin resource (which is now referenced by both Lists):

And now we can remove the rest of the CCDA set of resources, leaving only the usual list:

Now, I’m not suggesting that this is the best way to do reconciliation, and I’ve ignored the fact that the CCDA version of the meds is taken at night – I just wanted a realistic example. The whole point of this new functionality is to be able to experiment with these things.

A couple of things to note:

The versioning is of the scenario on your local machine (including the resources and references in it) – but they are not saved to the data server, unless you do this manually between versions – ie first update the server and then create a new version. This does need work to tidy up – should be done by the time of the WGM

I also got confused trying to select the resource I wanted in the graph when there are many of the same type, so I added the first 20 characters of the text to the display. I’ll make that an option shortly, as I suspect it will clutter the larger scenarios…

I also noted that the way in which you create references to multiple resources from a repeating backbone element (like List.entry.item -> MedicationStatement) is – to be kind – rather klunky. What you have to do is:

1. Create the first reference (ie List.entry.item -> MedicationStatement). This updates nicely in the graph display
2. Then click on another resource (any one) and back on the List resource. If you select the List.entry.item element, you’ll see the current contents of that branch just above the datatype, and an ‘Add’ link to the right of it. You have to click on that link to create a new List.entry.item branch, then you can create the new reference – otherwise you just wind up replacing the existing one.

Once you’ve created 2 or more branches, you can create as many more as you like by clicking the ‘Add’ link. You can also select (and edit) the other branches by clicking on the appropriate box in the set of branches.

But it’s not very user friendly, so I need to work on that. It’s all a bit complicated under the hood, but I’ll see what I can do.

But nevertheless, you can now a ‘story board’ of ‘frames’ that you can use to illustrate a process, or how to build a complex scenario.

I have to say that I found it a really instructing episode – not just developing the new functionality, but also understanding the usability issues.

To remind myself:

• Optionally synchronize resource versions in the scenario to the data server
• Allow individual branches (eg List.item) to be deleted
• Make the adding of new branches more user friendly
• Add an option to hide/show the text in the graph.
• A text box to describe each frame would be nice
• The nav bar has become a bit disorganized
• And maybe being able to edit / delete frames…

There’s some work to do! Well, it’s never boring…