Clinical Scenarios in FHIR

Well we’ve reviewed all 3 of the posts on the scenarios for the Clinical Connectathon in Chicago in September by the Patient Care Working Group – and there was some good discussion on all of them.

I didn’t keep as good notes as I should have for the Chronic Care scenario – which was a large scenario. A core part of this was the maintenance of the care plan – I had suggested that there should be multiple plans – 1 per Condition, but the consensus of the group was that a singe plan would be sufficient.

The ability to record compliance to medication was seen as important – even if there’s no easy automated way to do this, it’s often possible to tell this clinically (e.g. the patient doesn’t need a repeat script when they ought to have) and it is important to be able to record this.

Being able to link an Observation to an Encounter was generally agreed to be a useful thing to do – I don’t recall whether we came to a landing on whether this should be a property of Observation or a standard extension – I do wonder if the standard extension makes more sense as there are other resources that we might want to be able to refer back to the encounter where it was created/updated.

The discussion about the Acute Care episode centered largely on the use of multiple encounters. There was a concern that this would be confusing to clinicians who are more familiar with a less ‘granular’ approach – i.e. the visit to the ED would be a single encounter rather than multiple ones. You can still tell ‘who did what and when’ from the specific resource references (e.g. an observation has a reference to the Practitioner who made the observation as well as the time) so the need for multiple encounters is debatable. (I still kind of like the multiple encounters from a modeling perspective, but we’ll see how that plays out at connectathon!)

There was a question about the concept of an episode – Lloyd pointed out that there are plans to develop a specific resource for that as an episode typically encompasses multiple encounters dealing with a specific ‘concern’.

And finally the discussion on recording Allergies really focused on the maintenance of the List – and the processes around that. We talked about how a list would be updated – touching on the general concept of ‘reconciliation’ which applies to other domains like medications (and here) and problems.

We talked about the source of the list (for example suppose we already have an allergy list and then we get a Discharge Summary that has another allergy in it – how should that be represented?)  As it turns out it’s quite easy – the List has a source property that could record that a specific version of the list was automatically updated by an application (represented by a Device perhaps) so it should be obvious how the list was updated. We also have the option of using Provenance resources if we need more detail either at the List or the Allergy resource level.

We also agreed that it was important that the List and the resources referenced by the list need to be consistent. For example if an allergy is removed from the list, then the Allergy resource itself needs to be marked as refuted (using its status property).

So that completes the review phase of the scenarios (but do feel free to add to the comments anything I’ve missed). The next step is for the FHIR team to work on the software to be used at the Clinical Connectathon – ideally this should be able to be previewed prior to the event for feedback, so hopefully that will be possible.

And just a reminder that the clinical connectathon (unlike the main connectathon) is not yet open for anyone to attend. We need to test the concept with a small group first, but hopefully there will be a repeat of this at future Working Group Meetings that will be more open.