Stream: implementers
Topic: Querying all active medications
Michael Growette (Nov 26 2018 at 14:05):
Hi all,
I have a question regarding how other FHIR users are retrieving all the current medication resources associated with a patient profile. It looks like there may be different approaches in theory, but I'm wondering what other have used in practice. In this link - https://fhir.cerner.com/millennium/dstu2/medications/medication-statement/#querying-for-active-medications - Cerner discusses the approach of using MedicationStatement as well as MedicationOrder (MedicationRequest) to ensure that draft orders are included. According to the FHIR docs, it looks like this should be a valid approach, as MedicationStatement is commonly used as "the summarization of a patient's 'active medications' in a patient profile'". However, I've run into issues retrieving MedicationStatement in a couple different sandboxes - HSPC: https://www.hspconsortium.org/developers/sandbox/ and SmartHealthIt: https://www.launch.smarthealthit.org - but can retrieve medication resources via MedicationRequest. I'm curious if this is indicative of real EHRs or is maybe a limitation in the implementation of the FHIR servers in these sandboxes? Can any real-world implementers shed some light on how they go about retrieving all active medications from real EHRs?
Thanks,
Michael
Lloyd McKenzie (Nov 26 2018 at 15:35):
In Argonaut, most U.S. EHRs have agreed to use MedicationStatement to reflect the medications that a patient is "believed" to be on - but there's no guarantee across all EHRs that looking at MedicationStatement alone will give you everything.
Michael Growette (Nov 27 2018 at 13:48):
Great, thank you!
Veliyan Georgiev (Nov 27 2018 at 15:16):
Michael - we considered very carefully using the Epic FHIR endpoints for our patient portal. Leaving AuthN, AuthZ aside (whole different can of worms) - the FHIR endpoints didn’t contain some important information that was needed like number of refills left and so on. We had to fall back to using the WCF services instead but to answer your question - the MedicationStatement returns the same payload as the legacy API so it is the right one to use. There is a Status parameter you can use but I’d combine it with the Category parameter to further narrow down the list (especially for patient-reported meds). The missing information actually became more important later with DiagnosticReports and Observations in our case - there were workflows that couldn’t be accomplished just using FHIR like letting the patient aware that there are new test results and marking them as read. Only sharing it as a caution ahead in case you are thinking of using FHIR to power up a portal too.
Jose Costa Teixeira (Nov 29 2018 at 10:05):
Hi. on How to get all active medications - depends on what you mean by active medications
Jose Costa Teixeira (Nov 29 2018 at 10:06):
there is no single universal definition of what is "active" or "current" medication.
Jose Costa Teixeira (Nov 29 2018 at 10:06):
and take care when looking at MedicationStatements. They contain what someone stated that the patient is on.
Jose Costa Teixeira (Nov 29 2018 at 10:06):
if the EHR knows that the patient has an active prescription, this is not a statement, but a request.
Jose Costa Teixeira (Nov 29 2018 at 10:07):
Unless some system creates statements from prescriptions.
Jose Costa Teixeira (Nov 29 2018 at 10:08):
and things like number of refills left, which can be important or not, will not be in a statement.
Jose Costa Teixeira (Nov 29 2018 at 10:08):
so, Statement is just one of the components
John Moehrke (Nov 29 2018 at 15:17):
There is the special use of List -- http://build.fhir.org/list.html#query
René Spronk (Nov 30 2018 at 09:58):
.. which just pushes the complexity to the server.
In the Netherlands we just discussed a project where a server fetches all kinds of Medication* resources, and creates a Questionnaire to be updated by the patient "are you still taking X?" "what else are you taking?" - the resulting QuestionnaireResponse is translated into MedicationStatements. Yet another way of doing things. The Questionnaire is sent to the patient just prior to them being admitted for a scheduled procedure.
Mark Hudson (Nov 30 2018 at 13:49):
I'm working with Michael on this and understanding the various Medication related resources is only our first layer of getting to all active medications. To answer Jose's question, our definition of active is our best understanding of what medications a patient is on today. We are building a SMART on FHIR app that performs some level of analysis on medications that a patient is actively consuming so that providers can adjust the medication regimen to reduce medication risk.
It seems like using MedicationStatement is a good starting place understanding that it may not be perfect and non US EHRs may not use it in the same manner.
The next question we are working to solve is how to look at an individual medication resource, we'll use MedicationOrder in this example, and determine whether or not it is current.
curl https://fhir-open.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/MedicationOrder/14205368 -H 'accept: application/json'
This MedicationOrder has a status of active, a dateWritten of 2015-07-22, a timing code of daily, and a dispenseRequest.quantity of 30. No information is presented regarding refills outside of a text field, which would be unreliable.
If we combine dateWritten, timingCode, and quantity, the answer is no, this medication expired a long time ago. One of our worries is that neither dosageInstruction or dispenseRequest are required fields which could give us inconsistent results if EHRs don't proactively provide this data.
Has anyone come up with a good formula, or know of a public library we could include that helps solve this problem?
Jose Costa Teixeira (Dec 02 2018 at 19:27):
our definition of active is our best understanding of what medications a patient is on today.
Which is fine, because it is your definition. Other places will have other definitions for "active" or rather consider "relevant" medication - also whatever that is.
Jose Costa Teixeira (Dec 02 2018 at 19:32):
here is some old stuff:
pasted image
Jose Costa Teixeira (Dec 02 2018 at 19:35):
I'd say the principle is:
1. Use List, capture the other resources
2. Call things what they are. If you have a known prescription and a known dispense, they are no more, no less than that. They may indicate "active" but if you have a statement countering that information, then someone has to make a decision. So, keep the data, don't make assumptions.
3. Don't assume you can define global criteria for what should be in any list. Someone in Europe some time ago made a definition of what should be a medication list, and they took that as the entire truth, and I think they are still regretting that (or at least they should, considering the impact)
Jose Costa Teixeira (Dec 02 2018 at 19:39):
Oops, I just wrote a few things, they seem to be lost in ether. Can someone see the picture i posted?
Jose Costa Teixeira (Dec 02 2018 at 19:39):
anyway, it is here:
ftp://ftp.ihe.net/Pharmacy/yr6_2014-2015/Technical_Committee/Whitepapers/MedicationManagement/MedicationManagementRelatedConceptsandDefinitions_2014.10.02.docx
Jose Costa Teixeira (Dec 02 2018 at 19:44):
in case my other messages were lost: Use List, and use the resources for what they mean. a prescription means a prescription, a dispense another. a statement does not overlap any of those
Jose Costa Teixeira (Dec 02 2018 at 19:45):
and re-posting the picture pasted image
Lloyd McKenzie (Dec 11 2018 at 02:42):
Even if a medication order has expired, that doesn't necessarily mean the patient has finished taking it. They may not have started when it was first prescribed - or even when it was first dispensed. They may also have taken a break, then resumed. The best you can do is make categorical statements of "very likely taking", "possibly taking", "unlikely to still be taking" and "no evidence of taking".
Jose Costa Teixeira (Dec 16 2018 at 10:34):
yes, and if you do those statements, they are your local interpretation. When we discussed this in IHE a few years ago, there were two ideas:
1. We can make assertions based on the data and send those assertions as well, but it is nice to send the actual data in case your assertions are not following the same rules on both ends of the wire
2. We could (can we?) code some of those assertions or interpretations, e.g. "give me the "active" list of meds , where "active" means xxxxxxxxx..
Last updated: Apr 12 2022 at 19:14 UTC
