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.

[server]/MedicationOrder?patient={patientId}

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:

[server]/List?subject={patientId}&code=http://loinc.org|57828-6

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):

[server]/MedicationStatement?patient={patientId}&_list=$current-medications

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…