Challenges with Lists

So one of the challenges we’re facing at work at the moment is Lists – more specifically ‘current’ lists – eg the medications a patient is taking right now, their problem list and set of allergies.

A bit of background.

Our application is really a combination of HIE (Health Information Exchange) and EMR (Electronic Medical Record). We have a Clinical Data Repository (CDR) that collects information from many different sources, and them maps them to a set of canonical models. The main source of information is v2 messages, from which we extract ‘Event’ based information like encounters, problems, allergies & medications as well as Document based – CDA & CCDA being the most common (and yes, combining data across paradigms carries it’s own challenges!)

In addition, we have our own applications – such as Portals, Reconciliation/Curation and Case Management systems that also contribute data to the repositories.

One of our key strategies is to make all this data available to consumers via FHIR based API’s, so we need to think about just what API’s we’re going to support. We’ll consider this in the context of medications, though the same applies to problems and allergies

Making event based data (eg prescriptions or dispensing) is straightforward – someone tells us about a dispensed medication, we store it in the CDR, and them make it available via a REST query to the [server]/MedicationDispense endpoint. I’ve glossed over the security/privacy issues of course – as well as dealing with duplicated data – but conceptually this is quite straightforward.

But it’s not so simple when we want to supply an endpoint for the current list of medications.

You’d think it would be reasonably straight forward: each event has a period over which it applies (for prescription it’s how long to take the medication for, for dispense you can work that out from the amount given), from this you can work out what meds are ‘active’ at a point in time and there’s the list! (Again, glossing over a few details, but you get the point).

Of course, such a list will always be approximate – we may not have all the events for example, or some may not have all the data we require in those events – so it’s much better for a human to be able to confirm that the list is correct – a ‘reconciled’ or ‘curated’ list. And, indeed, we have functionality that does that, but there are a few wrinkles.

For a start, we can receive medication lists from external systems as well as events – that’s what the medication data in CDA documents is – what do we do if the lists from different sources for the same patient is different? (surely not, you say … 🙂 )

And what happens if we get or create a list, and then subsequently receive an event (e.g. dispense) for a medication not on that list? What is the ‘current’ list then?

So we’ve come to the conclusion that there is no single way that we can expose the ‘current’ list – instead we need a number of endpoints, each slightly different in what it supplies.

a) Firstly a simple RESTful query against each resource type – in this case MedicationOrder (prescriptions), MedicationDispense (dispenses), MedicationAdministration (actual taking of the medication) and MedicationStatement (from the CDA’s and other lists we receive) that returns a simple bundle containing the resources. We’ll provide various searches to facilitate the query of course, and likely some ‘aggregate’ operation that supplies all medication related resources.


b) Next, queries against the List endpoint that will return the ‘actual’ lists we have received – eg from CDA or our own List creator. This will return a bundle containing List resources – each of which represents a single list – plus the medication resources to which the list refers (likely MedicationStatement). This will be something like:


c) And finally an endpoint that represents our ‘best estimate’ for the current list. There will be internal business logic that assembles the list – for example it could take the most recent ‘curated’ list, remove meds whose activity period has expired and add any new medications we receive since the list. The details of this are to be determined! We’ll expose this list like this (it will only have MedicationStatement resources in it):


Although this lets us proceed, it’s not the most elegant of solutions so I’m interested in any comments that you may have – positive or negative! I’m sure that we aren’t going to be the only organization facing these questions.

Interestingly, the spec also discusses this issue and comes up with similar conclusions. This page also talks about lists. (both links are to the current build BTW so may change)

And finally, there’s a track at the next connectathon exploring this topic. Unfortunately I can’t be at that one, but will be interesting to see what comes out of it…


About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

6 Responses to Challenges with Lists

  1. The last step you describe is the same we are doing at the moment. We are still doing some research with the clinical stakeholders. It seems like different people see “current medications” in a different way so even that business logic might end up being up for interpretation depending on who the consumer is

    • David Hay says:

      Thanks for the comment Villy! Do you think it’s worth (or possible) providing a ‘recommended’ approach for this? – ie a ‘best practice’ for this logic?

  2. Peter Jordan says:

    Interesting, David. As well know, the “My List of Medicines” concept is something of a ‘holy grail’ in the NZ Digital Health landscape and the best available source of dispense events, over the country as a whole, is probably the community pharmacy systems. Are you working with the relevant vendors to create FHIR APIs to obtain this information over the whole of NZ or, at this stage, just getting it where a regional repository is available?

    • David Hay says:

      At the moment this is to meet our immediate needs, as the National repository is still in the early stages. Just thinking on it, it may be better to use the ValueSet rather than LOINC for option #2 (which would have a code of ‘medications’ in the example of the post) as that might be less controversial in the longer term…

  3. Brett says:

    Great post David — this is a tricky one. We haven’t heard vendors suggest $current-medications, although they might not be aware it’s available! At the San Antonio medications track we hope to nail down a recommended approach, and pitfalls. The Argonauts are currently leaning towards a query for both MedicaitonStatement/MedicationOrder with the client resolving duplicates.

Leave a Reply

%d bloggers like this: