Stream: argonaut
Topic: Medication
Jenni Syed (Jun 23 2016 at 15:05):
All, I was absent for the call that discussed requiring all Medications to be contained. I'm curious about the reasoning behind this (I've heard it's primarily for consistency and ease of use for client apps).
Jenni Syed (Jun 23 2016 at 15:06):
We originally used all contained Medications in our server, but switched most "simple" meds over to codeable concept based on pressure from applications, Grahame, and others in Argonaut (and since that was possible in DSTU 2)
Jenni Syed (Jun 23 2016 at 15:07):
I'm curious about the reverse in stance now - it seems easier for apps to access the codeableConcept directly rather than digging into the Medication resource when possible
Jenni Syed (Jun 23 2016 at 15:09):
previous conversations: https://groups.google.com/forum/#!searchin/argonaut-project/contained/argonaut-project/CyzzVBdoxO0/xLT2iHLVAQAJ and https://groups.google.com/forum/#!searchin/argonaut-project/contained/argonaut-project/50wSm34WhZQ/P3hBgATVAQAJ
Jenni Syed (Jun 23 2016 at 15:10):
Also, to specifically require a server to "contain" a resource where it may have been a pure reference seems wrong/a misuse of the contained concept (I was told one of the servers had pure references but were going to switch to contained)
Josh Mandel (Jun 23 2016 at 15:23):
Thanks @Jenni Syed! There are two issues for clients:
1. Ensuring the medication data are always available directly from a prescription (without an additional HTTP call)
2. Ensuring that client-side logic is as simple as possible (but not simpler).
For #1, medicationCodeableConcept and reference-->contained both work — but not reference-->external.
For #2, the issue is that if data can live in 2 places, you need to maintain two code paths and check in both places all the time. So this is strictly harder to manage than just having a rule like "Always look in medicationCodeableConcept" or "Always look in medicationReference".
Cerner indicated that the semantics of medicationReference are sometimes required (e.g. for compounded drugs, because a single codeable concept is not expressive enough).
--> the only logical conclusion I could reach to satisfy all constraints is: always use medicationReference, and always make the reference contained.
Josh Mandel (Jun 23 2016 at 15:25):
I should also add: if Argonaut vendors wanted to support "_include" directives, issue #1 would go away :-)
Jenni Syed (Jun 23 2016 at 15:27):
It still feels like abuse of the spec to require contained when something is indeed a reference.
Jenni Syed (Jun 23 2016 at 15:28):
As to the "where to look" I could make the same argument for any value[x] type field. Why are we particularly concerned with this one? Why make it harder for the larger use cases where meds are single ingredient?
Jenni Syed (Jun 23 2016 at 15:28):
Don't most of the open source libraries make this flexing somewhat simple?
Jenni Syed (Jun 23 2016 at 15:30):
I personally feel like the Medication resource is fundamentally broken - it's part reference data and part activity data right now. But so far there's been resistance to moving this resource closer to a representation of "formulary"
Jenni Syed (Jun 23 2016 at 15:30):
However, we're currently limited to what we have. I would love to continue conversations around how to make the "what was ordered/given" simpler within HL7
Josh Mandel (Jun 23 2016 at 15:42):
I agree the Medication resource as specified isn't ideal, but @Jenni Syed can you clarify what you mean by "activity data"? In the context of this Argonaut DSTU2 IG: we're just trying to work with it as published.
When it comes to client library support: I don't know any open-source client that, given a MedicationOrder, allows you to say "what's the drug code" with automated resolution across (medicationCodeableConcept vs. medicationReference) and also across (local vs. in-bundle vs. remote-fetch). It'd be nice, but it also forces all code to be written asynchronously, etc. In other words, it's hard.
Now, writing a single function to resolve a contained reference isn't hard. And it's reliable. The actual function is 2 lines instead of 1 line long, but once you write it, you're done.
Josh Mandel (Jun 23 2016 at 15:42):
It still feels like abuse of the spec to require contained when something is indeed a reference.
Agreed, it could be considered "an abuse", but it seems like the "least worst" solution (because it doesn't create practical issues I can see).
Josh Mandel (Jun 23 2016 at 15:44):
Also, re value[x]: different types are used to convey different information. So there's a reason for the pain. Whereas with this drug resolution issue, it's the same information in both cases (just more or less detailed).
Jenni Syed (Jun 23 2016 at 16:07):
For the contained on simple, would only the Medication.code be filled out? For multi-ingredient, is the Medication.code always filled out? If so, with what?
Jenni Syed (Jun 23 2016 at 16:09):
Also @Josh Mandel When I said activity data - some of the fields on Medication are specifically set based on an instance of an order. Whereas others are primarily "reference" - like if it's tylenol 325 and other packaging/product details
Josh Mandel (Jun 23 2016 at 16:09):
which fields are order-specific? That's the part I want to understand.
Josh Mandel (Jun 23 2016 at 16:10):
For the contained on simple, would only the Medication.code be filled out? For multi-ingredient, is the Medication.code always filled out? If so, with what?
I think we'd want Medication.code to be reliably populated -- even if just with a "text" element describing the compounded product.
Jenni Syed (Jun 23 2016 at 16:10):
Examle of "activity" on Medication are primarily the dosages of multi-ingredient meds, IIRC
Josh Mandel (Jun 23 2016 at 16:12):
It's not clear to me -- I mean, if you're prescribing a tylenol/codeine, I'd expect to see an RxNorm code in Medication.code, and that's it. But even if you did populate Medication.product.ingredient (x2), that's still not activity-specific.
Jenni Syed (Jun 23 2016 at 16:12):
Also, the lot info gets weird, depending on what you're tracking/what level. Since many pharmacy regulations state you need toknow the lot/exp of the specific order/fill, this is the only place to put that
Josh Mandel (Jun 23 2016 at 16:12):
Oh, I see - batch (lot number) would definitely fall in that category though
Josh Mandel (Jun 23 2016 at 16:12):
Yeah
Jenni Syed (Jun 23 2016 at 16:12):
The amounts are order specific. Otherwise, how do you say exactly how much of each item is in a bag (for IV or TPN)?
Jenni Syed (Jun 23 2016 at 16:16):
The form also gets clumsy for a compound or multi-ingrient. I believe we do this by setting form for the order. But for compound, the ingredients may be compounded into a cream. That I'm less concerned about as you likely don't care if the things that were compounded together started as powder or something else
Josh Mandel (Jun 23 2016 at 16:18):
Agreed!
Eric Haas (Jun 23 2016 at 17:51):
@Jenni Syed I started eiditing IG to show how this decision would look in the IG. I got stuck on the Medication Resource part and is thus unfinished. Yes as Josh said code is required. That is a no brainer but what about the compounded stuff. @Josh Mandel is saying text in code.display. If that is the case the why not just use Medication.medicationCodeableConcept?
Jenni Syed (Jun 23 2016 at 17:55):
@Eric Haas For IVs, Compounds, etc, there are likely other things filled out on that Medication to provide enough detail to apps doing logic based on dose or ingredient info (ie: not just displaying). However, I'm not sure any of that is required for MU
Jenni Syed (Jun 23 2016 at 17:55):
S4S likely has other concerns there, in that they likely do want RxNorms/coded ingredient information which is buried in the ingredient lists on Medication
Jenni Syed (Jun 23 2016 at 17:55):
(as would other apps)
Eric Haas (Jun 23 2016 at 18:10):
adding @Brett Marquard I don't see the distinction. It seems like a Kludge if we use the Medication resource but then only use the text to do compounded meds. We could then say must support codes and use the contained MedicationResource if you want to fill out anything more than a text description of a compounded medication. BTW we expected push back so thanks for bringing this up.
Brett Marquard (Jun 23 2016 at 18:19):
Are clients prepared to handle IVs, Compounds, etc? We started modeling some of this in C-CDA and folks stopped because they got very complicated and the value on a document exchange wasn't clear. I am sure these would be valuable for S4S and other exchange, but wonder if we should nail the simpler use case first.
Josh Mandel (Jun 23 2016 at 18:20):
S4S likely has other concerns there, in that they likely do want RxNorms/coded ingredient information
@Jenni Syed Maybe for compounded drugs. But for products in RxNorm, we can easily look up ingredients (i.e. just give us the SCD; we don't need the EHR to tell us what ingredients belong to an SCD, since NLM already provides that information).
Jenni Syed (Jun 23 2016 at 19:03):
@Josh Mandel For most things that qualify as IVs/Multi-ingredient/TPN, AFAIK there's no single RxNorm that represents them. This was the only remaining reason our server used the contained Medication resource
Jenni Syed (Jun 23 2016 at 19:04):
They usually only have those codes if there's a premix available
Josh Mandel (Jun 23 2016 at 19:39):
@Jenni Syed Totally -- that makes sense, and for these mixtures, reporting ingredients is great. I'm just saying we don't need/expect that same level of detail for prescribables.
Jenni Syed (Jun 23 2016 at 19:52):
interestingly, there's nothing AFAIK in FHIR that indicates an order is inpatient vs. outpatient
Josh Mandel (Jun 23 2016 at 20:04):
Well, MedicationOrder.encounter --> Encounter.class is a window onto that info.
Jenni Syed (Jun 23 2016 at 22:07):
@Josh Mandel That doesn't work when the ER or hospital prescribes you meds for home
Jenni Syed (Jun 23 2016 at 22:08):
You *might* be able to get there by who eventually dispenses, but that's assuming you know that info
Josh Mandel (Jun 23 2016 at 22:09):
I suppose that for inpatient or ED meds, you'd expect to find some MedicationAdministrations pointing back to the order.
Jenni Syed (Jun 24 2016 at 14:26):
Maybe, though there's nothing stopping home care or patients from inputing admins (at least in the spec)
Jenni Syed (Jun 24 2016 at 14:27):
But yes, many different methods to try to determine the origin of the med
Grahame Grieve (Jun 27 2016 at 01:19):
back to this
Grahame Grieve (Jun 27 2016 at 01:21):
we expected that mainly systems would reference medications in one of 3 ways:
- a code that refers to an national drug dictionary that implicitly defines a Medication resource (and In Australia, we'll be making that explicit for the national drig dictionaries - they'll publish Medication resources)
- a direct reference to the institutional pharmacy formulary (not usually an option for ambulatory prescriptions)
- an inline custom formulation (TPN, some IVs, creams etc)
Grahame Grieve (Jun 27 2016 at 01:22):
we expected that since all these are valid choices at the clinical level, clients would naturally need to be able to handle all these 3 options - codes, contained and external references.
Grahame Grieve (Jun 27 2016 at 01:22):
my opinion is that trying to restrict the options to less than these is 'too simple'
Grahame Grieve (Jun 27 2016 at 01:23):
I don't think there's much mileage in Argonaut trying for something simpler here either.
Grahame Grieve (Jun 27 2016 at 01:24):
I thnk that the feature that's currently in medication that belongs outside of it as well is the product.form. Frequently, clinicians order by code + form
Grahame Grieve (Jun 27 2016 at 01:25):
@Jenni Syed - what specificially were you referring to when you talked about resistance to fixing medication?
Lloyd McKenzie (Jun 27 2016 at 03:56):
But if they want code + form, why wouldn't that be a contained Medication? (because in addition to code + form, sometimes there's code + strength or other things too.
Grahame Grieve (Jun 27 2016 at 05:45):
because it's not the rest of the medication
Lloyd McKenzie (Jun 27 2016 at 05:54):
If it's a contained resource, it doesn't need to be - it's just the details you happen to have. We don't want to propagate medication details into the order.
Lloyd McKenzie (Jun 27 2016 at 05:54):
If you need more than a bare code, then you need the resource - and can choose whether you have enough to make it stand-alone or whether it should be contained
Grahame Grieve (Jun 27 2016 at 06:14):
no that missed the point. If I use a contained medication, I have to populate all of the correct details for medication. There's no way to just do code + form
Lloyd McKenzie (Jun 27 2016 at 06:25):
Why on earth not? You can have a contained Patient that just lists name and gender, why not a contained Medication that just lists code and form? You send the information you know (and can skip sending information pre-coordinated into the code).
Jenni Syed (Jun 27 2016 at 13:51):
@Grahame Grieve We discussed some of the challenges with Medication at the last WGM, along with what the intent was for this resource. IE: if it was inteded to represent a formulary. Also, that most non-premix multi-ingredient type prescriptions/administrations would all require a contained medication as it is now (or for Medication to be unique by order for those). I don't think we landed what the intent was (though I get the impression it may not be representative of a formulary). We discussed possibly turning the references from Med Order/Admin/Dispense into a list of Medications instead of single reference to help with multi-ingredient. However, sounds like the concern was that someone might misuse that for placing multiple separate prescriptions/orders. EG: Ibuprofen for pain, Amoxicillin x 10 days on the same order
Jenni Syed (Jun 27 2016 at 13:52):
The general feeling I got from the Pharmacy group was that there wasn't a concern that all mutli-ingredient/non-premix would always need to be contained on the Order/Admin/Dispense side
Jenni Syed (Jun 28 2016 at 19:34):
Sooo... are we good with leaving simple meds = to code or reference & multi ingredient = reference? And does it really matter if the reference is contained or remote?
Jenni Syed (Jun 28 2016 at 19:34):
Until some future time when we land on something better?
Jenni Syed (Jun 28 2016 at 19:35):
For apps that only want display - we can require that display/text is populated on codeable or display is required on reference?
Grahame Grieve (Jun 28 2016 at 19:50):
I think it doesn't matter if it's contained or remote, but if you do remote references, it would be good to support _include (even if just for this use case)
Josh Mandel (Jun 29 2016 at 13:43):
I think it doesn't matter if it's contained or remote, but if you do remote references, it would be good to support _include (even if just for this use case)
I have a very different take here @Grahame Grieve @Jenni Syed -- I think it's basically broken to offer developers an API where they're forced to issue 11 separate HTTP API calls just to fetch the drug codes associated with a patient's ten-medication-long list. We've built clients that work this way and they're complicated and slow. The complexity is manageable, but the slowness is not. Just being able to display a name isn't enough; interesting apps need access to semantics!
The fixes for this include: always use _contained, or support _include=MedicationOrder:medication. But if you do neither, you leave clients in a lurch. And Argonaut should specify that that's not okay.
Josh Mandel (Jun 29 2016 at 15:24):
Alternatively, vendors could support batch so an app could issue multiple queries together. We just need some way.
Josh Mandel (Jun 29 2016 at 15:24):
Of course read-only batches would be fine.
Jenni Syed (Jun 29 2016 at 16:23):
@Josh Mandel This specific instance doesn't require batch, but if you didn't support _include, it would require at least one more query, assuming the server supportted the _id parameter, correct? ie: get all medications, then get all the unique referenced id's like so:
/Medication?_id=1,2,3,4...
Jenni Syed (Jun 29 2016 at 16:24):
(note: as to _include, I currently have no skin in this game other than trying to find a common approach since our references are either code or contained, so others should add/discuss here...)
Eric Haas (Jun 29 2016 at 17:03):
What I am understanding so far is that we need the following:
'.medicationCodeableConcept' = mandatory to support for both client and server
'.medicationReference' = mandatory to support for both client and server
need to agree on whether servers must always use contained ( this is current state of IG) or must support _include or both ( whichi is what I think GG is saying) - If we only say must always support _include that does not preclude a reference from being contained.
Josh Mandel (Jun 29 2016 at 17:26):
Jenni: Indeed, comma-separated IDs are also a fine way to do this. I just want to make sure we have at least *one* required way that argonaut clients can rely on. Whether that's batch, or _id with commas, or _contained ,or _include -- just as long as we agree on at least one way.
Josh Mandel (Jun 29 2016 at 17:29):
'.medicationCodeableConcept' = mandatory to support for both client and server
This doesn't quite make sense. Are we saying that a server would be in violation of the spec it just happened to always use medicationReference? How would we decide?
Josh Mandel (Jun 29 2016 at 17:29):
I think we'd have to say "servers can choose, and clients must be prepared to deal with both"
Eric Haas (Jun 29 2016 at 18:02):
Despite how great it would be if everyone used RXNorm as codeable when appropriate. I'm OK with splitting the server and client requirements.
Eric Haas (Jun 29 2016 at 18:02):
...for now
Grahame Grieve (Jun 29 2016 at 21:49):
@Josh Mandel: "I have a very different take here" - I didn't think this was a very different take - I agree. Perhaps 'would be good' wasn't expressed strongly enough...
Josh Mandel (Jun 29 2016 at 23:23):
Ah, great. I misinterpreted your emphasis. But good :-)
Brett Marquard (Jun 30 2016 at 02:21):
@Grahame GrieveDo you have any concerns if we require a server support code and contained; or always contained? I am trying to find the middle ground...
Grahame Grieve (Jun 30 2016 at 03:15):
my opinion is that all 3 cases - code, contained, and external reference - are all valid workflows. Even we we said that we could prohibit the first so that you always used code.contained - which is functionally equivalent - I see little prospect that other groups with different dynamics than Argonaut would make the same choice, particularly in the ambulatory context. So my opinion is that we might as well say that clients should support all 3 options, and servers can choose any combination of the three.
Grahame Grieve (Jun 30 2016 at 03:16):
but since @Josh Mandel is always watching .... if we allow external references, we should make it clear what the most efficient way to retrieve all the medications information is
Josh Mandel (Jun 30 2016 at 15:13):
If I just keep repeating myself... ;-)
I think making it clear is good -- but we also need to clarify that at least one acceptably-fast method is required of Argonaut implementors. So far: contained and _include work (with no extra HTTP calls) and batch, and ?_id=a,b,c,d,... work (with one extra HTTP call). We need to pick at least one of these four and require it (or somebody can suggest a 5th!)
Eric Haas (Jun 30 2016 at 16:15):
I vote for
- code
- contained
- _include
where clients SHALL support all 3 options, and servers can choose any combination of the three.
Pascal Pfiffner (Jul 01 2016 at 10:57):
Is there a need to specify what clients shall support? Because that's usually not done.
Jenni Syed (Jul 01 2016 at 16:00):
@Pascal Pfiffner DAF actually specifies both client and server behavior
Jenni Syed (Jul 01 2016 at 16:04):
eg: requestors (client) and responders (server): http://hl7.org/fhir/dstu2/daf/daf.html#D.0.3.1
Josh Mandel (Jul 01 2016 at 16:37):
@Eric Haas what exactly does it mean, for a client to have "SHALL support" both contained and _include? A client has to write a specific query -- which one would it write? If we said "clients always are allowed to pass an _include parameter, and servers must accept it -- either by implementing _include, or by sticking meds in contained", that could work.
Jenni Syed (Jul 01 2016 at 17:36):
@Josh Mandel Isn't this scenario precisly what the conformance doc is expected to be used for?
Jenni Syed (Jul 01 2016 at 17:36):
We have competing goals/previous discussions here
Jenni Syed (Jul 01 2016 at 17:36):
EG: wanting servers to fail if known but unsupportted parameters are passed vs. ignoring parameters they don't really support
Josh Mandel (Jul 01 2016 at 20:53):
Well, maybe a server could have a way to express this in a conformance statement. We'd have to define two or three different patterns and require that each server fit one of those two or three, and that clients could then resolve/determine each and adjust behavior to fit? It's possible, but 1) I'm skeptical we can get it right, and 2) even if we do, I'm kind of worried about the complexity of it.
Eric Haas (Jul 01 2016 at 23:37):
Is summarized this discussion and subsequent offline discussion to: https://github.com/argonautproject/implementation-program/issues/46
Last updated: Apr 12 2022 at 19:14 UTC
