Stream: implementers
Topic: MedicationRequest <-> MedicationStatement
Patrick Werner (Aug 10 2017 at 09:30):
We are currently discussing the right usage of M.Request vs M.Statement. The usecase is the "german federal medication plan". In this document all medications which are prescribed by different physicians as well as the patients self-medication shall be captured. Some of the german HL7 community have choosen a list of medicationStatements whilst other prefer MedicationRequest.
Patrick Werner (Aug 10 2017 at 09:34):
as both ressources have the possibility to enter a Dosage and Timing technically both can be uses. Reading the scopes leads to different estimates of the readers.
Arguments:
- Statement: captures all medication a patient is taking currently, prescribed or non-prescribed
- Request: suitable for prescribed medications, also self-prescribed (recorder = patient), the plan includes the dosage and timing of the medications, and is therefore a request.
Patrick Werner (Aug 10 2017 at 09:35):
here is the paper form of this document: https://www.akdae.de/Arzneimitteltherapie/AVP/Artikel/201503/116-ABB-2.png
Jose Costa Teixeira (Aug 10 2017 at 09:42):
Hi Patrick. The intended usage is different for Request and Statement, although there is space for interpretations to differ. And there is lots of legacy.
Stefan Lang (Aug 10 2017 at 09:50):
From the resource description alone, both are not clearly distinct, as far as we understand.
What we need to achieve is a consistent set of data, typically compiled by one practitioner, containing
- the medication (regular, when needed) that practitioner has prescriped
- the medication (regular, when needed) other practitioners have prescriped
- the medication (regular, when needed) the patient takes without a practitioner's prescription
Jose Costa Teixeira (Aug 10 2017 at 09:50):
Shortly: In my opinion, your opening sentence points to the answer:
"In this document all medications which are prescribed by different physicians as well as the patients self-medication shall be captured. "
So it is not about choosing a resource, but there will be a dcoument that contains things that are prescribed (prescriptions) and summaries that are stated by the patient (Statement)
Jose Costa Teixeira (Aug 10 2017 at 09:51):
@Stefan Lang they are quite distinct in that one is a clinical request, the other is a summary (think of it as an "observation")
Jose Costa Teixeira (Aug 10 2017 at 09:52):
The consistent set of data doesn not need to be one or the other resource.
Stefan Lang (Aug 10 2017 at 09:54):
Yes, we put that together in a composition.
Stefan Lang (Aug 10 2017 at 09:54):
So you suggest that anything coming from a practitioner would be MedicationRequest, anything coming from the patient be a MedicationStatement?
Jose Costa Teixeira (Aug 10 2017 at 09:56):
depends.
you can do things like "a statement that is derifedFrom a prescription".
So if the physician is just doing the compilation, yes, statement seems better (i have limited insight into what you are looking for so this is just a first opinion)
Jose Costa Teixeira (Aug 10 2017 at 09:57):
BUT if the physician is saying that he is now prescribing this medication, even if it is to add to the summary, then it is a request.
Jose Costa Teixeira (Aug 10 2017 at 09:59):
basically (i can send you the early draft paper IHE is working on), the idea is that the list contains anything:
- summary of prescribed treatments
- active prescriptions
-...
Peter Scholz (Aug 10 2017 at 09:59):
the problem ist, that the "Medicationplan" is used for two purposes: on the one hand it should give the patient a compiled information which medication he should use when on the other hand it shoud provide pharmacies and practioners to identify possible negative interactions
Stefan Lang (Aug 10 2017 at 10:01):
@Jose Costa Teixeira the IHE draft would surely be of interest, in terms of keeping both efforts consistent.
Patrick Werner (Aug 10 2017 at 10:06):
just saw that taken in MedicationStatement has the Cardinality of 1..1
If a Statement represents a drug which a patient is taking at the moment, or defined daterange, taken doesn't seem to make much sense?
Jose Costa Teixeira (Aug 10 2017 at 10:07):
one thing that is important: A request is just a request, a "rezept". it is not a treatment. So you cannot say "this prescription is ongoing", but "this treatment is ongoing". A treatment can start with a request (or without). If this doesn't make sense, then whatever comes next is hard
Jose Costa Teixeira (Aug 10 2017 at 10:08):
@Peter Scholz -that is indeed a challenge, and one thing we realized from the beginning: any medication list will likely have multiple uses, so we should not try to go to "the list that meets our use case closest"
Patrick Werner (Aug 10 2017 at 10:08):
ah, or taken stands for the patient saying "i definitely don't take drug X" ?
Jose Costa Teixeira (Aug 10 2017 at 10:09):
taken is a code
Jose Costa Teixeira (Aug 10 2017 at 10:09):
y Yes Positive assertion that patient has taken medication
n No Negative assertion that patient has not taken medication
unk Unknown Unknown assertion if patient has taken medication
na Not Applicable Patient reporting does not apply
Jose Costa Teixeira (Aug 10 2017 at 10:10):
it stands for patient saying indeed "i don't take Drug X " <-- of course, that statement may be true or not, but that is what the patient says
Patrick Werner (Aug 10 2017 at 10:10):
i'm aware of the code, but "A MedicationStatement may indicate that the patient may be taking the medication now, or has taken the medication in the past or will be taking the medication in the future." kind of collides with taken as 1..1, especially the "in the future" part
Peter Scholz (Aug 10 2017 at 10:13):
Patient reporting does not apply ???
Jose Costa Teixeira (Aug 10 2017 at 10:19):
"na Not Applicable Patient reporting does not apply" is one of the codes. i guess it could mean that thestatement is captured in a way that does not require any patient assertion. The codes that usually matter are "yes, taken" and "no, not taken"
Jose Costa Teixeira (Aug 10 2017 at 10:23):
i can go to my physician and say "i plan to take these vitamins after my vacation". or "as of next week I will not take my antibiotics because I have a party and i intend to drink"
Jose Costa Teixeira (Aug 10 2017 at 10:23):
(sorry for the silly examples)
Jose Costa Teixeira (Aug 10 2017 at 10:26):
for the IHE draft, we will publish asap. we started this discussion in 2011 but due to lack of resources/time, we spent almost no time writing, but we did follow lots of similar dsicussions
Jose Costa Teixeira (Aug 10 2017 at 10:28):
btw, who are the owners of this medikationsplan? I have a couple questions also around security and others.
Patrick Werner (Aug 10 2017 at 10:34):
the owner of the plan is the patient, currently only the paper version exists but the plan itself is coded in a ultra short fhir format as a 2d barcode on the paper plan. In the future this plan should also be available electronically on the famous german electronic health card.
Adding entries is allowed by physicians and pharmacists, not the patient itself. It contains all prescribed medications as well as the self medication of the patient
Jose Costa Teixeira (Aug 10 2017 at 10:35):
ah, i meant security as confidentiality, as in "is there any sensitive information in the barcode, that if i am at a lunch table and someone takes a picture, they get access to my history?"
Patrick Werner (Aug 10 2017 at 10:37):
in the barcode alle entries visible on the paper plan are encoded. There is not more "hidden" information in the 2D Barcode
Jose Costa Teixeira (Aug 10 2017 at 10:38):
ok that was a curiosity, since I was looking at encryption on barcodes and I thought that someone had it.
Stefan Lang (Aug 10 2017 at 10:38):
Right, I guess that's left to the responsibility of whoever has a paper printout of the medication plan.
Stefan Lang (Aug 10 2017 at 10:39):
It would make no sense to encrypt the bar code when all it's information is right below in plain text ;)
Jose Costa Teixeira (Aug 10 2017 at 10:40):
it would make little sense. just because people know how to conceal text if they want to hide some parts of it, but they don't know how to conceal a barcode.
Jose Costa Teixeira (Aug 10 2017 at 10:40):
but that is a detail, sorry for diverging.
Stefan Lang (Aug 10 2017 at 10:46):
You are right, but I think that would be more of an issue for a prescription (as in "I get my Viagra somewhere nobody knows me, but the blood pressure medication at the local pharmacy")
Lloyd McKenzie (Aug 10 2017 at 15:19):
MedicationRequest is used for ordered, planned and proposed medications. I would expect that MedicationRequest instances with an "intent" of "order" would always be authored by Practitioners. You wouldn't have Patient-authored orders. However, you might have patient-authored proposals or plans. If you want to capture statements about what medications a patient claims to be on or that some reporter believes them to be on, MedicationStatement would be the correct choice.
Peter Scholz (Aug 10 2017 at 16:11):
understood and agreed but what if you want to present a medication plan which should serve two objectives:
1st give the patient a kind of handout which medication to use (like what you see on the pic attached by Patrick above)
2nd give the pharmacist and practitioner a compiled list of all medications the patient uses (prescribed by practitioners and self medication )
that's what the german medication plan does.
to me that looked like a bundle of MedicationRequests with an "intent" of "plan"
Jose Costa Teixeira (Aug 10 2017 at 16:13):
I would separate the purpose from the content:
Jose Costa Teixeira (Aug 10 2017 at 16:13):
the medication that the patient has to use is a request. the one that the physician wants to see is a statement.
Jose Costa Teixeira (Aug 10 2017 at 16:14):
with that in mind, are you not merging the content with the presentation?
Jose Costa Teixeira (Aug 10 2017 at 16:15):
i mean, the physician application will take whatever information is there (summary and requests), and render it as a summary. The patient will take only the part that is for him to administer (the requests)
Jose Costa Teixeira (Aug 10 2017 at 16:15):
the information transport should not depend on what you are going to do with it.
Peter Scholz (Aug 10 2017 at 16:21):
the medication that the patient has to use is a request. the one that the physician wants to see is a statement.
nice try, but the medication plan is both in one by law :(
Jose Costa Teixeira (Aug 10 2017 at 16:22):
I dont understand that comment. the technical mechanism should be clear. if the law forces some assumptions, those are on the outer layer.
Jose Costa Teixeira (Aug 10 2017 at 16:23):
i.e. if a law says "when a prescription is complete" - it is up to implementers to realize that what the law would say, if they were ridiculously picky, is "when the treatment initiated by the prescription is complete".
Jose Costa Teixeira (Aug 10 2017 at 16:24):
this is just an example. The argument "assumptions are already in the law" are not something worth discussing.
Jose Costa Teixeira (Aug 10 2017 at 16:24):
law is different everywhere and we don't want to harmonize the law, but to support the variety of laws.
Peter Scholz (Aug 10 2017 at 16:26):
Hmm bit difficult to explain:
The law is, we have to compile a medication plan, which has to serve both purposes explained above.
In a profile we now try to define a bundle resource which implements that kind of plan, and came across the tricky question which resource would fit best representing a single line in that plan ( MedicationRequest with "intent" of "plan" or better use a MedicationStatement)
Jose Costa Teixeira (Aug 10 2017 at 16:27):
so, to avoid any assumptions on my own statement ( :) ) i should say:
- the entries for the medication for which there is a request for the patient to take, are modeled as a medicationRequest.
- The entries for which the treatment is done, and/or are just a synthetic view (for the past, present or future) are modeled as a medicationStatement.
-Nothing prevents you from converting a request to a statement if you want to create a summary.
The user interface would know how to handle this.
Jose Costa Teixeira (Aug 10 2017 at 16:29):
I thnk the trick is "in a single line" - you are possibly looking for a line in the paper or in the presentation layer. I am looking at fhir resources which are in the background.
Peter Scholz (Aug 10 2017 at 16:32):
ok,
it's not the question if treatment is done,
Story line is
Patient insists that the practitioner compiles a medication plan,
this plan consist on
a) medication this practioner has prescribed
b) medication other practitioners have prescribed (and told the practitioner about it, or the patient informs his practitioner)
c) medication the patient just takes on a regular basis (non prescribed drugs e.g one Aspirin per day)
and for sure, it is no problem to translate, we just want to profile a certain approach as a suggestion that apps in Germany should use to send such a plan
Jose Costa Teixeira (Aug 10 2017 at 16:32):
pls pm me if you want to take a look at the early draft of the short paper on this matter. we are just starting but this is the point we want to make - the separation, for medication lists, between:
- frontend and backend
- data stored vs uses of that list...
Peter Scholz (Aug 10 2017 at 16:33):
I hope that cleared up a bit of our intent
Jose Costa Teixeira (Aug 10 2017 at 16:34):
a use case always helops :) thanks for the story line. here goes (first impression)
Jose Costa Teixeira (Aug 10 2017 at 16:37):
here's a possible bundle for that:
a) medicationRequest A, + medicationStatement A, which is derived from medicationRequest A
b) you can have a medicationStatementB, possibly derived from a medicationRequest B which sits somewhere else
c) medicationStatement C
Jose Costa Teixeira (Aug 10 2017 at 16:37):
of course the doubt remains on a)
Jose Costa Teixeira (Aug 10 2017 at 16:40):
but that is the key: this has two purposes:
1. tell the patient he is expected to take his medication (or even make a reminder on his smartphone)
2. fill in a summary.
I don't see a big issue in representing this as a medicationStatement that contains a request (thus differentiating it from case b)
Peter Scholz (Aug 10 2017 at 16:54):
did I get you right:
that would be a bundle containing
medicationStatementA (with basedOn = reference to medicationRequestA)
medicationStatementB (with basedOn = reference to medicationRequestB)
medicationStatementC
if yes: what is the reasonable value for MedicationStatement.taken ?
Peter Scholz (Aug 10 2017 at 17:00):
my first approach would have been using three MedicationRequests
case a) I think there is no doubt that this resource exist in the database of practitioner A
case b) in an ideal networked world, there would have been a transmission of the MedicationRequest from practitioner B to A (leading to a resource in practitioner A's database)
case c) if the patient tells practitioner A he is about to take e.g. Vit-D 1000iE every morning we could see that as a prescription where the patient is the author which could be modeled as a MedicationRequest with MedicationRequest.requestor.agent=reference to patient.
David Hay (Aug 10 2017 at 19:29):
Is the 'medication plan' the same as the definitive list of medications that a patient is (or should be) taking? If so, I've always modelled it as a List resource with MedicationStatements. When an 'order to supply' is made, that is represented by a specific MedicationRequest...
Peter Scholz (Aug 10 2017 at 19:34):
Yes it is the such a kind of a list (see story line above)
still leaves me with the question, what would be the correct value of taken ?
Jose Costa Teixeira (Aug 10 2017 at 20:23):
that is a good point, the value of "taken".
I would say na, since this is not about what the patient reported.
Scott Robertson (Aug 10 2017 at 21:00):
(my own interpretation, not necessarily authoritative)
MedicationStatement.taken is based upon what you know at the time the MedicationStatement instance is created. If you are deriving MedicationStatement from a MedicationRequest, with no additional information (e.g., no info from the patient), then you really don't know if it has (or will) be taken. So, MedicationStatement.taken="unk" (or "na" it taken is not pertinent).
Lloyd McKenzie (Aug 10 2017 at 21:41):
If the intent is that you're creating a Medication "plan" that incorporates meds that the patient has reported to be taking, additional meds that have been ordered by other clinicians and meds that the prescribing doctor is ordering, then I'd say CarePlan with a bunch of referenced MedicationRequest instances all of intent"plan". However, the legal order would be distinct instances of MedicationRequest with intent "order"
Grahame Grieve (Aug 10 2017 at 22:24):
in existing implementation prototypes, I have seen 2 approaches here:
- the list can include statements and requests - and even administrations for high profile single use things
- the list is all statements, with references to source requests, dispenses, and administrations
Grahame Grieve (Aug 10 2017 at 22:24):
which is better depends on where curation work belongs in the process (if present at all)
Last updated: Apr 12 2022 at 19:14 UTC
