Stream: implementers
Topic: Medication Resource Scope
Craig Newman (Oct 14 2020 at 12:21):
Splitting off from the https://chat.fhir.org/#narrow/stream/179166-implementers/topic/COVID.20Immunization thread so that one doesn't get hijacked by this tangent.
It sounds like the Medication resource can be used both as a definition of a medication as well as a description of an instance of a medication. Is that right?
Rik Smithies (Oct 14 2020 at 12:59):
yes that is true
Jean Duteau (Oct 14 2020 at 15:15):
i would say partly true. The scope of the Medication resource is to identify the medication that is being used in the referring resource. This can be done by specifying a code and lot number and identifier (if you just wanted to send the code, you'd probably just send the code as most references are CodeableReference(Medication). If you are defining a compound, you can also specify a set of ingredients and a recipe for making that compound.
The intent is NOT that you can say "this medication with this code has these ingredients".
Craig Newman (Oct 14 2020 at 16:44):
When looking at an instance of a Medication resource is it possible to tell the difference between a definition of a medication and an instance of a medication? Or should you be telling by context (eg. a Medication referenced in a MedicationRequest is probably a definition because a provider probably isn't ordering a specific instance of the medication)? Does it really matter?
Jean Duteau (Oct 14 2020 at 16:47):
i just feel that the distinction between "definition" and "instance" is a non-starter when it comes to the Medication resource. even historically it has always been problematic. I think that the only time that the Medication resource is explicitly referring to a specific instance of a medication is when the Medication.identifier is specified, i.e. a serial number is given. Every other time, even when the resource contains a recipe and a list of ingredients, it is not referring to an instance.
Rik Smithies (Oct 14 2020 at 16:50):
It can be type of medication or an actual medication though
Rik Smithies (Oct 14 2020 at 16:51):
but the definition is always elsewhere, in the code and the thing that the code represents. Is that it?
Jean Duteau (Oct 14 2020 at 16:52):
no, it is always an actual medication. When a prescriber says "100mg of amoxicillin" he is prescribing an actual medication. He just doesn't care which specific brand of amoxicillin is dispensed.
Jean Duteau (Oct 14 2020 at 16:52):
Rik Smithies said:
but the definition is always elsewhere, in the code and the thing that the code represents. Is that it?
I'd agree to that.
Rik Smithies (Oct 14 2020 at 16:53):
is it more like virtual vs actual?
Rik Smithies (Oct 14 2020 at 16:54):
which is like abstract vs concrete maybe
Rik Smithies (Oct 14 2020 at 16:56):
or maybe it can be thought of as a less specified medication vs a more specified one
Rik Smithies (Oct 14 2020 at 16:57):
but it does also go from being a type (amoxicillin, or a branded version) to an instance - an actual
pack with a lot number
Jean Duteau (Oct 14 2020 at 16:58):
Rik Smithies said:
but it does also go from being a type (amoxicillon, or a branded version) to an instance - an actual pack with a lot number
actual pack with lot number still isn't an instance. it's just more specified. the only time it is an instance would be if Medication.identifier is specified.
Jean Duteau (Oct 14 2020 at 16:58):
and Pharmacy WG didn't want to add that but caved in due to the requirement for injectables.
Jean Duteau (Oct 14 2020 at 16:59):
i do like the "less specified vs more specified" idea
Rik Smithies (Oct 14 2020 at 17:07):
I agree with the suggestion/question earlier by Craig that it doesn't really matter if it's an instance or not.
If its dispensed or administered, you know that there was one selected you could touch. Before that (requested) there isn't one specific one you can touch. But systems aren't going to be acting on some rather artificial "it's now an instance" flag. The context is clear from the use of the Medication resource.
Lloyd McKenzie (Oct 14 2020 at 21:11):
The reality is that there's a continuum. If you indicate that you dispense a medication with a particular lot number, that's not really an 'instance', in that you're not identifying the specific pill, but you're certainly conveying a degree of 'instancy' information. (You could also have 10 different dispenses that all refer to the same Medication resource instance declaring that same lot number - and that wouldn't mean you dispensed the same pill 10 times, merely that they are all the same 'kind' of medication from the same lot.)
John Silva (Oct 14 2020 at 21:46):
I've asked some of these questions before and specifically filed a GForge ticket in the past asking for there to be a Medication.idenfitfier (*) so that the "instance" can be differentiated from the "class" (or abstract type). If you have a medication quality control system you'd need to at least track the lot in case there are problems with a particular lot though that is still not an 'instance'. However, it is possible that a specific solution for a specific patient gets a bar code label and unique identifier that is 'one of a kind'. Imagine if there was a problem with a specific solution that got 'contaminated' or was mixed incorrectly, it seems like the pharmacy control systems (and people) would want to track that specific instance of the drug given to a specific patient. Also, when the clinician actually does the administration (RAS in V2, MedAdmin in FHIR) then at that point a unique instance of a drug is actually given. I suppose with one pill from one lot (or bottle of pills) it might not make much of a difference but for other use cases it would.
I also think of the 5-Rights Med Admin with barcodes so that the clinician (and system) knows and documents that the exact, specific instance of a med is given the Right Drug, to the Right Patient at the Right Time, with the Right Dose, with the Right route.
(*) I was amazed back in STU3 that it seemed like the Medication resource was the only one that didn't have an identifier property (other than maybe some of the non-patient infrastructure/foundational type resources)
Rik Smithies (Oct 14 2020 at 23:03):
Is lot number always meant to be an identifier of multiple items of which this is one? If it was unique to this item - possible for a dispensed pack presumably - would it go in batch.lotNumber or identifier?
Jean Duteau (Oct 14 2020 at 23:06):
i wouldn't say that it is always. But normally a lot identifies a specific batch of product that was produced, so normally it is an identifier of multiple items.
Rik Smithies (Oct 14 2020 at 23:11):
if I have a unique number on a pack, which people think of as a batch number, is it clear if it goes in identifier or lotNumber?
Jean Duteau (Oct 14 2020 at 23:11):
batch number would be an alias for lot number
Jean Duteau (Oct 14 2020 at 23:11):
unless it uniquely identifies the medication, it's not an identifier
Rik Smithies (Oct 14 2020 at 23:15):
Does where you put it depend on if there are other things with the same number?
Lin Zhang (Oct 15 2020 at 00:15):
A dispensed medication might be a mixed collection of a physical/concrete package, container and pills/doses...
Lin Zhang (Oct 15 2020 at 00:34):
What if a medication with a specified batch/lot number has to be recalled for an adverse event?
Rik Smithies (Oct 15 2020 at 09:23):
AdverseEvent resource can reference the Medication
John Silva (Oct 15 2020 at 12:39):
OK, but the adverse event could happen much later and then how would a system track down to the specific instances of medication administrations that were associated with this Adverse event? Yes, sometimes it could be a 'bad batch/lot' but other times a specific 'mixed solution' (a true one-of).
For other use cases I've seen is that when interfacing to existing MAR/CPOE systems that still (only) support HL7 V2 there needs to be a way to match the RAS (RXA) identifier of the "instance" of the drug with what is used as an identifier in the MedicationAdministration resource for that traceability back to the originating system.
Rik Smithies (Oct 15 2020 at 13:02):
FHIR can record the medication that was administered. If a "mixed solution" has a useful identifier, it can be recorded using FHIR, and potentially referenced later. If not, it can't. But FHIR cannot fix limitations in real world processes. If you don't know what administration it was, then FHIR can't really help you.
John Silva (Oct 15 2020 at 16:32):
I was talking about the situation where you do have a unique ID, e.g. a barcode in that is used in the 5-rights workflow (and usually communicated via HL7V2 RDE and RAS messages). Before the Medication.identifier property was added in R4 (I believe) there wasn't a way to have this traceability.
Rik Smithies (Oct 15 2020 at 16:41):
yes - does that raise some issues, or do you have what you need (in R4+)?
John Silva (Oct 15 2020 at 16:46):
@Rik Smithies - I don't have a problem with something I'm working on now. I'm just pointing out that there are real-world use case that require unique Medication identifier to properly implement certain medication workflows. The 5-rights is just one example, there are probably others that are related to quality assurance and other drug-tracking applications, e.g. clinical trials, that probably need unique identifiers.
Craig Newman (Oct 15 2020 at 19:05):
Jean Duteau said:
unless it uniquely identifies the medication, it's not an identifier
I'm assuming you mean the "instance of the medication" given that Medication (the resource) can be anywhere on the continuum. I don't see this spelled out in the resource definition (only the comment of "The serial number could be included as an identifier."). Would you like a Jira ticket to clarify the use of .identifier, restricting it to ids for medication instances?
Jose Costa Teixeira (Oct 15 2020 at 20:05):
A Medication resource can also convey "we've given to this patient a special mix wich includes:
- 5 g of product X with lot Y and serial Y
- 10 ml of product A with lot B
"
Jose Costa Teixeira (Oct 15 2020 at 20:05):
even if the special mix does not have a unique ID
Jose Costa Teixeira (Oct 15 2020 at 20:09):
The introduction of a serial number was a long discussion (meaning it was not seen as common practice), and personally I'm still not convinced "identifier" is the best place we could have found for it.
Identifier could be a batch identifier, or a serial number... which makes it a continuum - but not a good one (and not what implementations are/were doing AFAIK)
Jose Costa Teixeira (Oct 15 2020 at 20:16):
Looking at the OP: @Craig Newman I think your sentence may be better if instead of
"as a definition of a medication as well as a description of an instance"
you have
"as a kind of a medication as well as a description of an instance of a medication"
(and would be even better if you replace "description" by "specification".
Jose Costa Teixeira (Oct 15 2020 at 20:16):
Reading the above, I don't see anything in the OP related to Virtual vs actual, abstract vs concrete, type vs actual.
All those are just concepts related to the "precision" of the definition of a medication - but they are all still definitional.
Rik Smithies (Oct 15 2020 at 20:23):
All identifiers are identifiers. We can't add one for each type across a continuum. No one would know which to use. It is already a problem with two of them. We want one type (identifier), which has a type, so you can say what it is if you need to.
Jose Costa Teixeira (Oct 15 2020 at 20:34):
I don't know what you mean with that. The way I see it, you must be able to add an identifier, at any point of the continuum.
Jose Costa Teixeira (Oct 15 2020 at 20:36):
what you cannot standardize is the splitting lines across the continuum.
Rik Smithies (Oct 15 2020 at 20:44):
Yes I agree. So we use identifier for everything, because there is no separation between types that we can agree on in advance. The different identifiers have systems to tell them apart. If users also need to have different types differentiated they can use different identifier.types.
Jose Costa Teixeira (Oct 15 2020 at 21:11):
now I see what you meant. Well the way that systems are working, Serial Number and Lot Number are clear concepts with specific meaning
Jose Costa Teixeira (Oct 15 2020 at 21:13):
and they are both Production Identifiers (out of a production process)
Jean Duteau (Oct 15 2020 at 21:36):
To clarify and repeat my earlier statement, Medication.identifier should be used for a string that uniquely identifies a specific medication. For most cases, Serial Number does uniquely identify a specific medication. But Lot Number is an identifier of a batch of product and not of a specific medication. That is why you shouldn't put Lot Number in the Medication.identifier.
Jean Duteau (Oct 15 2020 at 21:37):
And that is why it shouldn't come to anyone's surprise why the Pharmacy WG did not have a Medication identifier. MOST systems that we were referencing don't refer to a specific instance of a Medication.
Jose Costa Teixeira (Oct 15 2020 at 21:56):
I admit I have always struggled with the interpretation of the rule that "most systems". That always ends up as 'most systems I've know' or 'most systems I care about'
Jean Duteau (Oct 15 2020 at 21:57):
for Pharmacy WG, it has always been, of the systems that all of the people in the WG know about and/or use
Jean Duteau (Oct 15 2020 at 21:58):
that is all any WG can do. thus the onus is on others who come to the table to present their use cases and show that they have production systems that require whatever it is they are asking.
Jose Costa Teixeira (Oct 15 2020 at 21:58):
To me what matters is - 'when this element is exchanged, should it be a standard element so that everyone is expected to use it the same way'
Jean Duteau (Oct 15 2020 at 21:59):
except that's not the FHIR mantra
Jean Duteau (Oct 15 2020 at 21:59):
that way leads to V3 models with everything and the kitchen sink
Jose Costa Teixeira (Oct 15 2020 at 22:01):
That is an opinion, I presume. In most systems I've seen ( ;) ) it avoids ambiguity and scope creeps
Jose Costa Teixeira (Oct 15 2020 at 22:05):
We have a release coming for resources that are not implemented by most / any systems. And we have to adapt our rules for that. A mantra is not a dogma, so we have to start somewhere even if we are not sure (this is where I praise. Rik for the initiative - even if I disagree with some of the options, steps were made into the unknown, and that is good)
Jean Duteau (Oct 15 2020 at 22:05):
no, it's not an opinion. Take a look at Pharmacy's V3 models. They modelled every element that could be exchanged so that there was a standard way. That led to models that did not actually reflect what was being exchanged since no one had the use of every requirement and use case. FHIR intentionally went the opposite way. Here is the line from the spec: "FHIR resources aim to define the information contents and structure for the core information set that is shared by most implementations. There is a built-in extension mechanism to cover the remaining content as needed." So you might have a "standard element" that isn't shared by most implementations and thus isn't in FHIR. Medication.identifier was one of those. We agreed that a Medication serial number existed but the implementations that Pharmacy WG knew of and had participation from did not record nor exchange it. So it wasn't originally in scope. When the list of implementations grew, the need to exchange a serial number came forward and thus got included.
Jose Costa Teixeira (Oct 15 2020 at 22:06):
Ok so if it's not an opinion I'm not supposed to debate or challenge
Jean Duteau (Oct 15 2020 at 22:07):
i didn't say that either. i'm simply showing you what the specification says. if you want to debate or challenge that, go ahead.
Jose Costa Teixeira (Oct 15 2020 at 22:09):
Anyway, the serial number was not accepted when implementations grew or new implementations came up with the need.
Jean Duteau (Oct 15 2020 at 22:11):
Umm, yes it was. When John Silva came forward with the requirement, we discussed it and added the Medication.identifier as the proper place for that.
Jose Costa Teixeira (Oct 15 2020 at 22:11):
That's how it seemed. I look at this discussion and things seem quite fragile, which contrasts with some of the strong assertions I sense.
Jean Duteau (Oct 15 2020 at 22:11):
Until he came forward with a concrete requirement, it wasn't a need for the resource.
Jose Costa Teixeira (Oct 15 2020 at 22:13):
There was a long discussion before that. IHE had to make an extension because the same request was rejected
Jose Costa Teixeira (Oct 15 2020 at 22:18):
Anyway, that is not the issue, it's just that we take modeling-based decisions, and we take empirical decisions. Some of those are a hit, some are a miss. I would like to see a serial number on anything that is a product, but it's not something I cannot get around.
Jose Costa Teixeira (Oct 15 2020 at 22:20):
The original question triggered some discussion but my idea is:
The medication resource allows us to specify (not define) a specific instance or a kind of a medicine - whether there is a continuum or definition vs not... that doesn't matter I think.
Jean Duteau (Oct 15 2020 at 22:20):
In September 2017, you raised this issue. We suggested that it be an extension for STU3 until more systems came forward with the requirement. You raised the exact same issue in January 2018 and we decided to change it at that time. In September 2018, we realized that a serial number could be considered an identifier and moved it. That's how things should get added to the spec.
Jose Costa Teixeira (Oct 15 2020 at 22:20):
to specify a medication, you need a code, or sometimes you need more than that.
Rik Smithies (Oct 15 2020 at 22:56):
At the moment it's hard to know from the text that .identifier is for the (relatively rare) case of a unique number (serial number is mentioned, but only as a possibility), and .lotNumber is for the non-unique cases. But that is clear now, and the text could easily be improved.
I can also see an issue where you may not know (yet, or ever) if a number is a unique identifier or not. I assume the rationale was that {anyresource}.identifier is meant to be unique. Is that a rule? If so then it has to be the way it is. If that is not true then all unique or non-unique identifiers could have been modelled in one attribute, which is simpler in some ways.
John Silva (Oct 16 2020 at 15:19):
Just an aside -- this discussion seems to have corollaries to the UDI identifier in Observations: http://hl7.org/fhir/R4/device.html#udi
"The UDI may identify an instance of a device uniquely (when the PI includes a serial number), or it may just identify the type of the device."
It's interesting that this use case was driven by a governmental requirement and also, that FHIR added a unique property to Observation for this rather than "overloading" the identifier property.
As in the case of medications though, this need for device-level (or 'instance level') traceability comes from the safety/quality control requirements around the medical practice, in this case device use, in the case of medications, medication use (or abuse).
Derek Ritz (Oct 16 2020 at 16:22):
I don't know if this is helpful... but it might be. In the supply chain world, there isn't a distinction between LOT NUMBER and SERIAL NUMBER. They are the same concept. A SERIAL NUMBER is just a LOT with one (and only one) member. I also note that we run the risk of conflating "active ingredient" with "product" (or so it seems from the thread). A clinical order for acetaminophen doesn't care what brand. But when this order is fulfilled (dispensed, or dispenses and administered), we need to track the exact product (what GTIN... which can also include the LOT# for lot-controlled products). This also can connect back to data elements maintained by our insurance colleagues... since there may well be a defined formulary for the various acetaminophen products that are included in the portfolio of insured/covered products.
Jose Costa Teixeira (Oct 16 2020 at 16:35):
When a serial exists, it can coexist with a LotNr.
Jose Costa Teixeira (Oct 16 2020 at 16:36):
the rest I agree with you @Derek Ritz
Derek Ritz (Oct 16 2020 at 16:38):
@Jose Costa Teixeira -- I am sorry to be drawing a blank... when can a serial exist that co-exists with a LOT#?
Lloyd McKenzie (Oct 16 2020 at 16:51):
The lot # is the id of the case, the serial # is the id of a specific item in the case. When you're talking about an item from the case, you might well convey both ids.
Rik Smithies (Oct 16 2020 at 17:12):
I agree with Derek that these numbers might overlap. You can have a unique "lot number" I assume (at least in common language of the domain). And then that would not go in lotNumber but in identifier.
The tricky issue is that given a number written on something (or a legacy record of a number), it may be hard to know if it is/was unique (like a serial number) or not (like a lot number). So you can't know where to put it. "Uniqueness" doesn't seem to me to be a good filtering criteria.
Is there a general FHIR requirement that resource.identifier uniquely identifies that thing?
Lloyd McKenzie (Oct 16 2020 at 17:58):
It's supposed to uniquely identify a thing, but as with any real world identifier, messiness exists. If you know it doesn't uniquely identify the thing, it would be wrong to put it in .identifier.
Jose Costa Teixeira (Oct 16 2020 at 18:28):
Jose Costa Teixeira (Oct 16 2020 at 18:29):
These concepts are defined, we don't need to know if it is unique or not. A serial number is a serial number
Jose Costa Teixeira (Oct 16 2020 at 18:30):
The concept of uniqueness will fail. Sometimes there are batches of 1. Sometimes you want to see if there are duplicate serial numbers
Rik Smithies (Oct 16 2020 at 19:46):
So if we say that unique ones go here and non-unique ones go there, then we have a problem. On the other hand if identifier can only take unique numbers, then we can't put them all in there (and just use .type to tell them apart).
Both possible ways to do it are messy.
Lloyd McKenzie (Oct 16 2020 at 19:47):
If you've got an identifier for a specific medication instance (vial, tablet, baggy), that goes in .identifier. Anything else goes in lot
Rik Smithies (Oct 16 2020 at 19:48):
what if you don't know if it is unique to that instance
Rik Smithies (Oct 16 2020 at 19:49):
If I have 100 medications in some legacy data, all with identifying numbers, what do I do?
Lloyd McKenzie (Oct 16 2020 at 19:51):
If you have no clue what the values mean, stick them in an extension because they're only going to be safe for use by someone who understands their context
Rik Smithies (Oct 16 2020 at 19:55):
So that is junk data then.
But even for new data, sometimes a user may not know which field to put it in. Next to the data entry fields, when they type in the number on the pack, it will need to say: use this one if the number on the pack is unique, this one if not unique.
If it seems common to not know whether what is on the box is unique or not - as Derek says - it doesn't seem good to not have a clear place to put it.
It seems more unsafe to relegate a useful identifier to an extension, because you don't know if it is unique or not.
Rik Smithies (Oct 16 2020 at 19:57):
The terminology doesn't seem to help because a lot number can be unique, or not.
Lloyd McKenzie (Oct 16 2020 at 20:02):
Sure. If something is a lot number, stick it in lot. If it's a lot of one, so be it. You only stick something in 'identifier' if it's truly known to be unique. And most user interfaces will call it something like "serial number" which should hopefully avoid confusion. (And in fact, most systems won't capture it at all because there aren't a lot of places that deal with dose-specific serial numbers.
Jean Duteau (Oct 16 2020 at 20:14):
unlike what Derek said, there does appear to be a natural distinction between a product's lot number and a product's serial number. FDA, EMA, and Health Canada both make a distinction. Here, as an example, is the FDA's discussion of a product identifier: Includes the product’s lot number, expiration date, national drug code (or NDC), and a serial number.
I think that a more interesting conversation revolves around GTINs. From my reading of the GTIN Allocation Rules document, it seems that you can assign a GTIN to a single unpacked pill, but that the pill wouldn't be marked with the GTIN via barcode. The bottle that all of those pills comes in would be assigned a different GTIN. What I couldn't clarify (and would love if someone else could) is if the GTIN assigned to the single unpacked pill was just an identifier of any single unpacked pill or whether it was a GTIN assigned to that specific single unpacked pill. I would be surprised if a separate GTIN was assigned to every single pill but I don't know enough about the size of the GTIN space. I did find reference to a sGTIN (a GTIN plus a serial number) but I couldn't find that in the specification.
In any case, where do we think the GTIN should go? Is it a Medication.identifier? Is it actually just the Medication.code? I've actually seen guidance from supply chain providers that basically equates the NDC with a GTIN. If that is true, then my answer would be that the Medication.code is the place for the GTIN.
Peter Jordan (Oct 16 2020 at 20:35):
Jean Duteau said:
In any case, where do we think the GTIN should go? Is it a Medication.identifier? Is it actually just the Medication.code? I've actually seen guidance from supply chain providers that basically equates the NDC with a GTIN. If that is true, then my answer would be that the Medication.code is the place for the GTIN.
Unless GTIN is underpinned by a medications terminology, Medication.identifier looks a better fit to me.
Rik Smithies (Oct 16 2020 at 20:37):
(not wishing to skip over GTIN discussion)
Regarding lot vs serial, these things are differentiated, and may be clearly defined, but I get the feeling that in practice you may not know which of the clear definitions you have in front of you. Official guidance doesn't always reflect what goes on in the ground, which is what we need to support.
TBH I can't see a strong reason to split up the identifiers based on uniqueness.
Putting them all in identifier seems reasonable, then only one place to worry about.
But it seems it's just me who doesn't know what is unique and what is not :-)
So I think the main thing would be to better document this "uniqueness" requirement, which seems fundamental, because I totally missed that when I came to use this recently. I will raise a Jira.
Jean Duteau (Oct 16 2020 at 20:37):
@rik the uniqueness of identifier isn't specific to Medication, so hopefully your Jira ticket isn't medication-specific.
Rik Smithies (Oct 16 2020 at 20:39):
It would be about any resource that has two types of identifier and where it's not already documented which is which :-) I've only see that in Medication... (though I do worry about UDI occasionally, but that's not my field).
Rik Smithies (Oct 16 2020 at 20:40):
if there was a place everyone would read that said don't use this unless it is unique, we could put it there. But it's better not buried in the datatypes spec.
Derek Ritz (Oct 16 2020 at 20:49):
There is a very mature nomenclature in the supply chain domain related to part numbering, lot control, etc. The tracking of materials -- including lot controlled and serial number controlled items -- is not a requirement unique to healthcare. If we develop a nomenclature for our materials (like medications, for example) that is not compatible with the nomenclature used by GS1, we'll just be creating problems for ourselves... and perhaps (potentially) problems for patients and providers, too. This feels to me like an area where the physical-world use case needs to drive what our informatics model should do... especially including how we decide to use our resource identifier.
Derek Ritz (Oct 16 2020 at 20:56):
In supply chain management and industrial engineering, a part number (also called a stock keeping unit, or SKU) will need to be different each unique combination of form, fit or function. If the form, fit or function changes... then a new part number is created. Lot numbers (or serial numbers... for lots of 1) are for traceability. They do not impact the form, fit or function. An item's serial number is not used as a replacement for its part number.
John Silva (Oct 16 2020 at 20:56):
It's interesting reading all of this discussion. One thing that strikes me (probably from the V2 world) is the difference between an "unencoded order" where the clinician just says, "give the patient some amount of X", where X is the generic or even product drug name. That is fine for unencoded orders (OMP or RXO segments in V2) but when the Pharmacy gets that order they create an "encoded order", which is typically more precise, that is, they specify the specific brand in stock, the particular package (drug form), and so forth (because of knowledge of what's in the Pharmacy and maybe also the patient's condition and side-effects/adverse reactions, etc.), that would end up in RGV (Give) messages in V2. Then, when the specific instance of a drug is actually given, no matter whether or not it has a unique identifier on it, it is surely a unique instance of the drug being given (RAS in RXA/RXC in V2). Of course V2 is more 'transactional' (in a sense) than FHIR which seems to only contain the 'current state' of something in the resource, in this case the Medication with respect to the encapsulating order (MedRequest) or administration (MedAdmin) and that seems to be part of the problem for this difference in how the Medication.identifier might be used over these different steps in the med workflow.
[I suppose at the 'unencoded order' stage it might be Medication.code only, but surely at the 'administration' stage it is unique and seems to need Medication.identifier.]
Rik Smithies (Oct 16 2020 at 21:05):
If you know an identifier for the medication you can record it. If you don't, but want to record "the unique instance of the drug being given" (my emphasis on the act of "being given", not the instance) then the associated activity resource, in the later stages of workflow, is unique and identifiable. MedicationDispense for "given to the patient" (as in "handed to"), or MedicationAdministration for the sense of "given to to take". Does that cover what you are thinking of John?
Derek Ritz (Oct 16 2020 at 21:06):
Also particular to supply chain -- I may have multiple SKUs that all contain the same thing. Drug X could be packaged in bottles of 50, 100 and 500. These are all the same drug and manufactured at the same time with the same LOT# and expiry date. As @John Silva has noted, a medication order for X could be equally fulfilled by dispensing any of these 3 SKUs... but at the time of dispense, it will be necessary to say which one. And so, at the time of dispense (or administration), the SKU and the LOT# will need to be recorded. It is likely an attribute of the SKU that its classification or its product family will be denoted as X. This is a challenge. The what it "is" from an active-ingredient standpoint is not identical to what it "is" from a stock management standpoint. Typically, the GS1 GDSN (Global Data Synchronization Network) database maps GTINs (SKUs) to ATC codes (active ingredients). That's how it is in Canada and in the US, too, I believe.
Derek Ritz (Oct 16 2020 at 21:15):
Info re: GS1's use in healthcare (sadly without a meds example... but still illustrative): https://gs1ca.org/gs1ca-components/documents/healthcare-hscn/webinars/GS1-Standards-Class_Nomen-Intro-Webinar_Nov-2019_v1.3_Final.pdf
Jose Costa Teixeira (Oct 17 2020 at 07:00):
IHE is working on a product model for this last bit @Derek Ritz , based on what is currently working on supply chain
Jose Costa Teixeira (Oct 17 2020 at 07:01):
the GDSN is about product master data, so yes, it defines the product and its characteristics like ATC and active ingredients.
Jose Costa Teixeira (Oct 17 2020 at 07:03):
I do not understand the reasoning about the uniqueness vs non-uniqueness. A serial number has a meaning. It's meant to be unique and used and exchanged as such. A lot number is a different attribute with typically a different granularity. This is how all systems operate, do we want to consider deviating from that?
Jose Costa Teixeira (Oct 17 2020 at 07:05):
This is perhaps why something was telling me that using an "identifier" for serial number is not a good idea. It is a projection onto a model, without a need for that. It requires us to consider whether something is unique or not.
Jose Costa Teixeira (Oct 17 2020 at 07:06):
I cannot think that someone would do the same thing for similar problems.
Jose Costa Teixeira (Oct 17 2020 at 07:09):
serial number, lot number, expiry date, etc are all well-established production attributes (GS1 calls them production identifiers).
Is it my turn to say that we should look at what systems do, instead of making our model? If so, we'd have to have a very good model.
Jose Costa Teixeira (Oct 17 2020 at 07:14):
@Derek Ritz I think what you point at in terms of separation corresponds to the model we captured , where we have a trade item (the GTIN thing) and a product (which is a functional description, in whatever abstraction level)
Jose Costa Teixeira (Oct 17 2020 at 07:19):
Use case(just to make Craig hapy :smile: ):
- A covid vaccine is scanned upon arrival to the pharmacy. The system captures a serial number(, and knows it is unique because it is a serial number).
- In another part of the country, another covid vaccine is scanned, with a same serial number. This other system captures a serial number(, and also knows it is unique because it is a serial number).
Jose Costa Teixeira (Oct 17 2020 at 07:20):
The part in italic is not relevant IMO. Systems don't capture a serial number because / depending on its uniqueness. They capture a serial number.
Jose Costa Teixeira (Oct 17 2020 at 08:55):
just remembered another thing: The GTIN number (which is a product code) uniquely identifies a (kind of) trade item, one with unique characteristics. So it's a business identifier, but doesn't go into .identifier? I don't think that is a consequence that goes well with implementations
John Silva (Oct 17 2020 at 14:02):
@Rik Smithies - yes, MedDispense is 'equivalent' to the V2 RGV (Give) message and MedAdmin to the V2 RAS (Administration) message. However, in the V2 workflow there are separate places in the message (segments) to capture the 'originally ordered' drug (e.g. ORC or RXO, and the specific drug "to be given" (RXG, with optional RXG.25 barcode id) and then the actual instance given (RXA and/or RXCs for bases and additives). The question I have with the FHIR 'current state model' is that as the medication workflow transitions from one state to another, does the same Medication resource get used (i.e. instance stored in FHIR server) or is there a unique instance stored with (typically more) precise identification as it steps through the Med workflow?
BTW, I didn't state this explicitly but I'm referring to an inpatient Med workflow.
Jose Costa Teixeira (Oct 17 2020 at 14:49):
MedDispense is the same as RGV AND RDS if it is about "here's the medication"
Jose Costa Teixeira (Oct 17 2020 at 14:49):
technically, I think Dispense is best suited to replace RDS
Jose Costa Teixeira (Oct 17 2020 at 14:50):
if RGV means "give this one now and this one later", then it's a MedRequest with intent=instance-order
Rik Smithies (Oct 17 2020 at 15:06):
To your question John, yes you can have a different FHIR Medication for the one prescribed to the one dispensed.
Jean Duteau (Oct 17 2020 at 15:25):
The GTIN number (which is a product code) uniquely identifies a (kind of) trade item, one with unique characteristics.
You can say that an NDC code uniquely identifies a trade item and we put it in Medication.code. If you are going to make the argument that you did, then I will gladly point people to put the GTIN in the Medication.code.
Derek Ritz (Oct 17 2020 at 20:52):
Jose Costa Teixeira said:
Use case(just to make Craig hapy :smile: ):
- A covid vaccine is scanned upon arrival to the pharmacy. The system captures a serial number(, and knows it is unique because it is a serial number).
- In another part of the country, another covid vaccine is scanned, with a same serial number. This other system captures a serial number(, and also knows it is unique because it is a serial number).
Jose -- your example should not happen... and if it did happen, it should throw a supply chain (GS1) exception. By definition -- no two items should have the same serial number. This is why, in my view, we're getting a bit arm-wavy when we talk about serial numbers on pharmaceutical items. To assign an individual serial # to every vial of vaccine coming off a production line just doesn't happen (in my experience, at least, when I was a supply chain advisor to Pharmacia and Upjohn). Pharmaceutical products are made in batch lot runs and it is essential to track the batch lot in case a recall is necessary. But there could be millions of doses produced out of the same batch lot production run.
I'm starting to see the wisdom, however, of tracking serial numbers and lot numbers as separate elements in our FHIR resources. In many ERP products, there is only one data field (true for ObviousMRP and for JDE, for example) and the definition of a serial number is that it is a lot with only one member in it. But by tracking separate elements, we can tell that a serial number should be globally unique for the same GTIN and (as mentioned above) throw an exception if we ever find that this isn't the case.
Derek Ritz (Oct 17 2020 at 21:00):
RE: re-using the same resource for two different purposes... I must admit my radar is going off, a bit. When the resource is fulfilling a master data management (MDM) purpose, then it is denoting a "thing" and we will be well-served to have the identifier somewhat following the "part number rule" -- if the form, fit or function changes, then we need a new identifier. But where the resource is associated with an event or transaction (e.g. MedicationDispense, or MedicationAdministration) then it makes more sense for the identifier to denote a unique transaction # or some similar event tracking ID. I'm sorry if I'm the only one who isn't following the plot... but it seems to me very unhelpful to conflate these two fundamentally different concepts.
Jose Costa Teixeira (Oct 17 2020 at 23:49):
@Derek Ritz thanks for catching this. The case is indeed for a falsified medicine check. It will likely happen, I'm afraid. We may or not be ready to tackle it.
Jose Costa Teixeira (Oct 17 2020 at 23:50):
@Jean Duteau yes, the GTIN is to me a product code. Even if it identifies uniquely a single concept. I'm arguing that "uniqueness" is not a good criterium.
Jose Costa Teixeira (Oct 17 2020 at 23:51):
@Derek Ritz serialization is full of challenges - printing unique barcodes at the speed that machines produce the products is not easy. But it's a directive that we are aiming at. And some products need this
Jose Costa Teixeira (Oct 17 2020 at 23:54):
btw, other products do this serialization check - I can recall for example software license numbers, and guitar strings - he user is asked for a unique code. If the same serial number is seen twice, then something strange happened and triggers investigation.
Jose Costa Teixeira (Oct 18 2020 at 00:01):
@Derek Ritz I may have missed your point on re-using the resource for master data and transactional aspects.
I think those are different concepts and indeed different resources (eventually also different resource types) would be best.
But these resources should remain somewhat aligned.
One example: I have a use case where we need to say, in a prescription transaction, "this is the product we should give; and btw, this is the product's relevant definition".
Jose Costa Teixeira (Oct 18 2020 at 00:02):
(I just realized I summoned Derek 3 times, real fast)
Derek Ritz (Oct 18 2020 at 00:57):
@Jose Costa Teixeira I think it is interesting to note that a MedicationRequest for acetaminophen is not an order for a product (GTIN level)... it is an order for an active ingredient (ATC level). A MedicationDispense, however, will need to identify that it was Tylenol, and record the batch lot. It isn't clear to me what is expected of the Medication resource referenced by these two? It doesn't seem like it can be expected to be the same resource... can it? (and this is what I meant by MDM vs transactional resources)
Jose Costa Teixeira (Oct 18 2020 at 01:12):
ATC is not a substance code, is a classification (it is not univocal). I'm aware that a request for acetaminophen is not a request for a specific GTIN. But you can have a medicationrequest for a specific GTIN. We are exploring this in depth for a few years (hence my reservations about some aspects of the current approach, but that is not the point here).
Jose Costa Teixeira (Oct 18 2020 at 01:17):
About the resources - I don't think the current Medication resource is incorrect here. It allows us to specify whatever attributes are needed to convey what is meant - with or without a brand name, or with or without a lot number, depending on what you want to order or to register as dispensed. I actually favour a tighter integration between the master data and transactional resources - not because they are not separate concepts (they are and I try to underline that every chance I get) but because when specifying a product you need to use more than just a code.
Jose Costa Teixeira (Oct 18 2020 at 01:18):
The medication resource here is not how data should be persisted (really) but a reasonable exchange form for "specifying a product"
Derek Ritz (Oct 18 2020 at 04:20):
Thanks, @Jose Costa Teixeira . I apologize for being slow to understand. As an example... would we expect to have a separate Medication resource for Acetaminophen... and another one for Tylenol regular strength (50 tab package), and another one for Tylenol regular strength (100 tab package), and one for Paracetamol extra strength (50 tabs) and Paracetamol extra strength (100 tabs), etc.? And if yes... which one would we expect to be identified in the MedicationRequest? (or do we believe it doesn't actually matter... cuz they're all, functionally, the same "thing"?)
Rik Smithies (Oct 18 2020 at 10:25):
Derek, from what Jean was saying you would not necessarily have Medication resources sitting around for all those types waiting to be used in requests or dispenses. It didn't sound like Medication is intended for that sort of definition, and to be re-used over and over. You would at least have to clone them into an 'instance' Medication for each use. I think the idea is that you make one new for each event, and the definition is really only in the code (backed by NDC, SNOMED etc, possibly GTN, or even ATC).
Medication definitions can also be done in MedicinalProductDefintion, which could be pointed by the Medication (in lieu of a code), but that relationship doesn't exist at the moment (we have asked for it, but it was not allowed).
Also to your point about ATC, drugs are not always prescribed by substance/active moiety. That is routine in hospitals, but in primary care (General Practice, family doctor) it is more common to prescribe at generic (or 'virtual') product level, with an actual product in mind but just not a specific manufacturer. Virtual product, actual product and substance based requests are all required, and all covered, I believe. This is the continuum of "specificity" that has been mentioned earlier in the thread.
I don't think that "ATC is not a code". If that degree of specificity is good enough for the context of the request, I see no reason why you can't request that and have a qualified dispenser turn that into an appropriate actual product. It's common to have lists of moieties to pick from (e.g. UK VTM, virtual therapeutic moiety, which is similar in concept to ATC, just more integrated with the product list).
Jose Costa Teixeira (Oct 18 2020 at 11:09):
ATC is not a product code. It is a classification code. epSOS tried to use ATC as a code for prescribing but the result was clear
Jose Costa Teixeira (Oct 18 2020 at 11:11):
VTM identifies one moiety so it is a product code. I believe the starting point for openMedicine was that some products have 0 ATC categories, some products have more than one ATC category.
Lin Zhang (Oct 18 2020 at 11:12):
ATC is not a GOOD terminology/classification because a...
Jose Costa Teixeira (Oct 18 2020 at 11:13):
@Derek Ritz in the case you mention, you'd have one resource instance for each of the concepts you describe
Lin Zhang (Oct 18 2020 at 11:13):
@Jose Costa Teixeira As you said
Lin Zhang (Oct 18 2020 at 11:14):
In other words, Its codes are lack of uniqueness.
Rik Smithies (Oct 18 2020 at 11:51):
~ a VTM identifies one moiety so it is a product code.
That's not correct, by what I consider the normal definition of a product.
Many products can share the same moiety (and so VTM, at least in the systems that I'm aware of), including many virtual products - for instance solid and liquid forms.
A VTM is a moeity/substance code, not a product code.
The fact that a moiety can be in more than one part of ATC, doesn't mean than an ATC code (which is made more specific by moeities being non-unique, not less) cannot express the desired concept of the request. But we have already established that there are better moiety level code systems for prescribing.
Jose Costa Teixeira (Oct 18 2020 at 12:03):
A product is not a trade item, perhaps that is what is what makes you disagree.? But in any case conflating vtm - a concept identifier - with ATC is not correct
Rik Smithies (Oct 18 2020 at 12:06):
I'm just saying that there are multiple products for paracetamol VTM.
Jose Costa Teixeira (Oct 18 2020 at 12:08):
I agree with that
Jose Costa Teixeira (Oct 18 2020 at 12:12):
There are also many concepts of product. For me VTM is another - but I can correct that statement if it helps. A VTM is a concept and has an identifier (or code, as you want). And ATC is a classification. We don't order by ATC
Rik Smithies (Oct 18 2020 at 12:28):
A VTM is not another concept of a product by any useful definition of a product in this space.
We should not equate products and moieties/substances.
Jose Costa Teixeira (Oct 18 2020 at 13:21):
"by any useful definition of a product" is a strong statement. I think you mean by your definition of a product - which is not agreeable to me. Anyway I corrected my statement to reduce the gap from my side.
Jose Costa Teixeira (Oct 18 2020 at 13:23):
We can discuss if any other abstraction is a "product". We can discuss all that but I think it's rather useless
Derek Ritz (Oct 18 2020 at 20:21):
Thanks, all. The idea that the Medication resource wasn't an MDM resource hadn't occurred to me; that represents a bit of an "a-ha" moment for me, @Rik Smithies . :smile: So... the Medication resource can be used as a "scratch" resource, and articulated at whatever degree of specificity is required at the time it is being used... but you wouldn't necessarily have a requirement that there was referential integrity back to a cardinal set of pre-defined Medication resources. Do I understand this correctly??
Jose Costa Teixeira (Oct 18 2020 at 20:25):
I did ask for Medication to contain a link to MedicationKnowledge for that referential integrity - like we have for Device to DeviceDefinition.
Jose Costa Teixeira (Oct 18 2020 at 20:27):
(MedicationKnowledge is the "MedicationDefinition" resource I'd use for MDM - see the #catalogs stream)
Jose Costa Teixeira (Oct 18 2020 at 20:28):
and btw, I believe that is the trigger of this discussion - my opinion is that in a vaccine you should not only have the code, but a possible relation to the Master Data
Rik Smithies (Oct 18 2020 at 20:28):
There is no need for a Medication resource to exist in abstract, that is then referenced later on when activity happens. The integrity is to the definition of the medication, which is the code. The medication definition concepts are in the terminology.
If a resource is needed for a definition, then that would be to a MedicinalProductDefinition. MedicationKnowledge is not intended for that I believe, but for extra information about the medication. e.g. for decision support.
Jose Costa Teixeira (Oct 18 2020 at 20:32):
(There's obviously a disagreement here between me and Rik on the resources to use, and the reference between resources. Nothing that can't be resolved with some dialog)
Rik Smithies (Oct 18 2020 at 20:33):
the diagram on this page https://wiki.hl7.org/File:Resources_sketch.png shows the relation between the medication and the definition and the knowledge that is part of the original resources definitions https://wiki.hl7.org/MedicinalProductDefinition_FHIR_Resource_Proposal
Derek Ritz (Oct 18 2020 at 20:34):
So... @Rik Smithies , that's one of the main things I'm concerned about. If there is not an accepted and consistently-used level of specificity in the MedicationRequest... how do we do CDS on it... such as drug-drug interactions, etc.? I'm working on a number of Computable Care Guidelines projects... and we need this to be nailed down or it won't work...
Rik Smithies (Oct 18 2020 at 20:34):
I can understand the concern Derek, but what is not accepted or not consistently used?
Rik Smithies (Oct 18 2020 at 20:36):
It is normal that there is different specificity as you go from request to dispense to administration. And also possibly a switch from moiety/substance to product.
Derek Ritz (Oct 18 2020 at 20:38):
@Rik Smithies A PlanDefinition resource related to guideline-based medication recommendations (and the workflow associated with these) will need a degree of consistent specificity so that the plandefinition.action.condition statement can be correctly evaluated. Including to just be able to tell whether a prescription already exists (and so another need not be created). Stuff like that...
Derek Ritz (Oct 18 2020 at 20:40):
if it is different every time... it will be nigh impossible to define "condition" statements that will correctly evaluate to TRUE when they should evaluate to TRUE... and that can have some pretty dire patient safety implications... :rolling_eyes:
Derek Ritz (Oct 18 2020 at 20:43):
(and I know it is different all the time, in practice, today... but the whole role of the computable care guidelines is to try to reduce medical errors and coalesce clinical behaviours around systematic guideline-adherent care... so this use case isn't intended, necessarily, to accommodate a status quo that is demonstrably not patient-safe... it is intended to change it) :smile:
Rik Smithies (Oct 18 2020 at 20:46):
ok well that is wider than this prescribing pattern we are discussing.
You would need to look for a MedicationRequest for a Medication that included the medicine you were interested in. (or a dispense or administration possibly). The complication is that you may need to transform from product to moiety.
That is just a general problem with guidelines however, not a consequence of this FHIR representation. The GP system I did in 1995 had this same issue with our decision support guidelines.
You need a terminology that allows you to ask for "paracetamol" and find all the products (branded and unbranded), all the packs, forms etc and any substance based scripts (we didn't have that last issue in primary care however). This problem will be familiar to anyone making guidelines I think.
Derek Ritz (Oct 18 2020 at 20:53):
we're working with WHO and trying to develop computable care guidelines (CCGs) that can be leveraged to operationalize WHO's care guidelines for ANC or HIV and so on. as you would imagine... there are no "brands" referred to in WHO's guidelines. (hence my reference to ATC codes... since that seems to be about the level of the recommendations... i.e. for active ingredients). i've also been taking a cue from what's defined in the IPS regarding their profile of Medication (IPS) (which mandates either ATC or SNOMED in medication.code).
Rik Smithies (Oct 18 2020 at 20:53):
Bottom line is that this variation of specificity exists in the real world of prescribing. FHIR allows you to capture it fully. Guidelines need to work with the real world. FHIR enables that.
Rik Smithies (Oct 18 2020 at 21:01):
If your guidelines don't know about brands, but your prescriptions do (most won't in fact, but a few may), then you would need a way to map brands to generics. That is common in drug terminologies.
Also if your guidelines know about substances (in ATC) but your prescriptions don't (as in primary care) or do (secondary care) but its not coded in ATC, then you need maps there too. You need product to moiety/substance maps, and ATC to whatever substance codes are used maps. Again, medications terminology commonly does both of those. You can also represent that in MedicinalProductDefinitions if you want.
Lloyd McKenzie (Oct 18 2020 at 22:48):
Medication is going to be used in a few ways:
- most commonly as a 'contained' resource where a MedicationRequest, MedicationDispense, etc. needs to convey details about a particular medication beyond just the code (ingredients, lot number, whatever)
- as a resource serving as some sort of 'formulary' entry representing medications available for ordering, dispensing, administering. Typically these won't have lot number/expiry date/identifier information on them, though they could. The registry indicates what's (typically?) allowed to be ordered/dispensed/administered.
- as a resource serving in some sort of inventory management system, typically only referenced by MedicationDispense and MedicationAdministration that refers to what's actually on hand and available. The dispensing system might also 'generate' identified Medication instances when it spits out unit-dose containers for transport to the ward, and eventually to the patient room
Lloyd McKenzie (Oct 18 2020 at 22:50):
For the first two uses, you'll have hundreds or thousands of MedicationRequest/Dispense/Administration instances (for a wide variety of patients) all referring to the same Medication instances. For the last, you'll have fewer, though if the instance is only specific to the level of 'lot', you could still have many resources referring to the same instance (because the instance doesn't represent a single pill, it instead represents "a pill from one of the bottles that arrived in shipment A").
Melva Peters (Oct 18 2020 at 23:04):
@Derek Ritz I'm not sure I understand your concern about CDS on MedicationRequest. Alert checking is done today whether the drug is prescribed at the level of Amoxicillin or Amoxicillin 250mg or Amoxicillin 250mg capsule or Teva-Amoxil 250mg Capsule. The Drug Knowledge Base vendors such as First DataBank or Multum have relationships back and forth between different levels of the drug hiearchy.
Derek Ritz (Oct 18 2020 at 23:17):
Hi @Melva Peters -- the concern related to CDS is related to expressing computable care guideline (CCG) "condition" statements (plandefinition.action.condition) that should fire TRUE when, for example:
**pregnant mum's BP is above a threshold level X
AND
BP med is not already prescribed
**
If there isn't a clear way to tell what the medication resource for this BP med is, then there isn't a clear way to tell whether a medicationrequest for this med already exists. Also -- I appreciate that there may be vendor products that figure all of this out -- but if I can't make it work without these products, then I will need to know to mandate them for the MOHs in low and middle income countries (LMIC) where I'm providing advisory services. I was looking for a way to do this in a FHIR-based HIE... and trying to sort out what data needed to be where in order to operationalize CCGs. :smile:
Lloyd McKenzie (Oct 18 2020 at 23:18):
Decision support will almost always drive off the Medication.code, not the Medication instance. There'll be lots of Medication instances that share the same code (or express the medication concept at different levels of granularity).
Derek Ritz (Oct 18 2020 at 23:49):
Jean Duteau said:
The GTIN number (which is a product code) uniquely identifies a (kind of) trade item, one with unique characteristics.
You can say that an NDC code uniquely identifies a trade item and we put it in Medication.code. If you are going to make the argument that you did, then I will gladly point people to put the GTIN in the Medication.code.
@Lloyd McKenzie -- I agree with you... but if we put GTINs (or their equivalent) in medication.code, then we will not be able to succeed re: CDS, I don't think. There's been a lot of discussion on what should go there, over the arc of this thread...
Rik Smithies (Oct 18 2020 at 23:50):
Lloyd, why would your first bullet mean "you'll have hundreds or thousands ... all referring to the same Medication instances".
If contained, they cannot be the same medication instance? Would all your thousands be for your second bullet?
Also, Jean seemed to be saying that Medication was not expected to be a purely definitional thing (a list of medications to be referred to), and the definitional aspect was only a "less-to-more specified" thing. That sounded like the formulary use was not in scope (despite what I had thought before).
Perhaps that was only referring to definitions within the "instance" use (request, to dispense) and not the "pure definition" use (formulary).
Rik Smithies (Oct 18 2020 at 23:52):
Derek, why would having a GTIN in the code would be limiting for CDS? As long as you can know things about the GTIN and its relation to other products, substances etc, you can reason about what things people are taking. It makes no difference what sort of code it is.
Derek Ritz (Oct 18 2020 at 23:56):
Rik, if a terminology service was there that could somehow map the GTIN to the code used to express the business rule, then I guess it would work. Is that what you're thinking?
Rik Smithies (Oct 18 2020 at 23:57):
Yes. That is exactly what drug terminology does.
Derek Ritz (Oct 18 2020 at 23:58):
The GDSN in Canada, as I understand it, maps GTINs to ATC codes. So each CDS rule would go thru the drug terminology mapper to see if the rule should fire TRUE or not. Like that?
Rik Smithies (Oct 18 2020 at 23:59):
You can go from general to specific, product to substance etc. It does depend how good the maps are. But the main ones in use very much do do that sort of thing.
What is in place for GTINs now I have no idea. But if they are to be useful at all they will need that. So, yes to your last question, like that.
Derek Ritz (Oct 19 2020 at 00:04):
If we were designing for a "green field" -- are there simplifications that could be reasonably made? In many LMIC environments, our opportunity is to help formalize "best care practices" through the application of the digital health solutions (similar to how ERP systems became instruments of business process re-engineering back in the 1980s, for those that might recall those days). Any thoughts??
Derek Ritz (Oct 19 2020 at 00:04):
I have the voice of one of my Engineering profs ringing in my ears: "the art of design is to cast the problem in such a way that it lends itself to being solved". :smile:
Rik Smithies (Oct 19 2020 at 00:07):
Green field of electronic prescribing? Green field of prescribing in general? Everyone prescribes the same way? Or green field of guidelines? Several of those ships already sailed :-)
Lloyd McKenzie (Oct 19 2020 at 00:22):
@Rik Smithies Right. I mis-spoke in referring to thousands pointing to contained Medications - only the containing resource would point to it.
@Derek Ritz The terminology service and/or the CDS engine would need to be able to perform subsumption testing on the basis of the GTIN. But if GTINs are being captured, then I'm pretty sure someone somewhere has a mapping between those and the knowledge-base codes more typically used for drug-drug, drug-allergy and other CDS functions.
Derek Ritz (Oct 19 2020 at 00:23):
The WHO's ANC guidelines recommendation C.5 states:
–– If a pregnant woman has not previously been vaccinated, or if her immunization status is unknown,
she should receive two doses of a tetanus toxoid-containing vaccine (TT-CV) one month apart with
the second dose given at least two weeks before delivery. Two doses protect against tetanus infection
for 1–3 years in most people. A third dose is recommended six months after the second dose, which
should extend protection to at least five years.
–– Two further doses for women who are first vaccinated against tetanus during pregnancy should be
given after the third dose, in the two subsequent years or during two subsequent pregnancies.
–– If a woman has had 1–4 doses of a TT-CV in the past, she should receive one dose of a TT-CV during
each subsequent pregnancy to a total of five doses (five doses protects throughout the childbearing
years).
It would be useful to be able to have a medication order for this recommendation be completely consistent across all practitioners. And it would be equally useful if a woman's IPS medication statement were consistently expressed, too... so that the guideline could be readily evaluated and operationalized regarding subsequent administrations. That's the kind of thing I'm trying to accomplish. I think in some of these environments the re-engineering opportunity is there to improve the consistency (and quality) of how care is delivered. And if yes... how might we want to model the use of the medication, medicationrequest, medicationdispense and medicationadministration resources (and of course, the medication statement that is returned in the IPS).
Lloyd McKenzie (Oct 19 2020 at 00:25):
In LMICs, my guess is there often wouldn't be a formulary function of what's allowed to be prescribed/available to be dispensed. So in most cases, you'd probably be working with contained drugs. As for what codes get captured, that tends to be national. If there is no national terminology, then you'd probably be looking at using something like SNOMED (provided the country qualifies for a free license) and would need to look for mappings to the GTINs on the prescribing/administering side.
Derek Ritz (Oct 19 2020 at 00:25):
The IPS medication profile (http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Medication-uv-ips.html) indicates ATC or SNOMED code is to be denoted in the medication.code element. That's why it has been these trees that I've been barking up.
Derek Ritz (Oct 19 2020 at 00:26):
In LMICs it is common to leverage the WHO's guide to essential medicines: https://apps.who.int/iris/bitstream/handle/10665/325771/WHO-MVP-EMP-IAU-2019.06-eng.pdf?ua=1
Derek Ritz (Oct 19 2020 at 00:28):
The WHO list is, I think, the "formulary"...
Rob Hausam (Oct 19 2020 at 01:09):
We need to be clear that the IPS medication profile does not mandate the use of ATC or SNOMED CT for medication coding. It does highlight the visibility of those two particular code systems, as they have potentially wide (although not universal in the case of SNOMED CT) availability and applicability. This is done be by representing them as separate slices. Each slice has a required binding to its particular code system (maybe that's where the confusion arises?), but the slicing itself is open - so IPS doesn't have any mandate for this and allows for any medication terminology to be used. We would have liked to be able to be more prescriptive and push (or nudge) toward a recommendation for something that could approach global usability, but we didn't come up with a suitable way to do that at the present time. We did consider at some length specifying IDMP (at various levels) here, but ultimately we backed away from that as the needed content for it to be useful at a prescribable or describable level doesn't yet exist.
Derek Ritz (Oct 19 2020 at 02:25):
@Rob Hausam I've read, with interest, the epSOS D1.1 openMedicine report on gaps identified by ePrescribing pilot countries. It seems that there are challenges that remain... but also that there are approaches that look pretty promising. Is there a path that, in your view, LMICs could take to leverage SNOMED GPS and/or ATC to good effect to get basic ePrescribing working with the WHO's essential medicines as the national formulary?
Rob Hausam (Oct 19 2020 at 02:52):
That's a very good question, @Derek Ritz. Unfortunately, I don't think that the GPS will be of any help with this. We didn't include medications in our submission for the IPS free set (one of the contributing sets for the GPS), and I don't think that anyone else has, either, so I don't believe that there is any medication content at all in the current GPS. The problem with that idea is that there isn't really a way that know of to come up with a useful subset of the "most common" medications, or something like that. To make it useful, especially for e-prescribing, you pretty much would need to have a code available for whatever medication any patient could be taking - and that's completely out of the scope of the current GPS idea. That will only begin to have a chance to work if at some point SNOMED Int. decides to make all SNOMED CT descriptions available for free use - but even then if the relationships aren't free then that will seriously hamper the use for CDS that was being discussed earlier. Looking otherwise at ATC, I don't know how far we might be able to get with that. It's been pointed out in this discussion that ATC is a classification. In my mind that doesn't necessarily mean in any way that it isn't potentially useful, including for the IPS. But I suspect that its granularity isn't sufficient for e-prescribing, unfortunately - though I wouldn't entirely rule that out. Since it can at least generally provide the generic drug names that are needed, maybe with sufficient additional support for the other prescription elements there could be a way to make that work? I don't know. So I still don't know what the answer is for this, but I'm very interested in continuing to help all of us work to figure out some solutions.
Derek Ritz (Oct 19 2020 at 03:06):
Thanks, Rob. I'm happy to say that, on a cursory inspection, it does look like there is pretty good coverage of the WHO's list of essential medicines in the ATC. That's a start... and a good start, IMHO. Getting the basics up and running would make a huge and positive impact... and would usefully support the CCG (CDS) work. :+1:
Derek Ritz (Oct 19 2020 at 03:09):
And thanks for the catch... I read right past the fact that the SNOMED meds IPS code set (http://build.fhir.org/ig/HL7/fhir-ips/ValueSet-medication-snomed-uv-ips.html) is licensed. Of course... it's a free license in LMICs... but it's still a license requirement that many get uncomfortable with since there will be steep fees once they "graduate" from LMIC status.
Jose Costa Teixeira (Oct 19 2020 at 06:50):
about codes vs categories:
snomed|774587000 means Product containing only amoxicillin and clavulanic acid (medicinal product)
but in atc
atc|J01CR01 is ampicillin and beta-lactamase inhibitor
Jose Costa Teixeira (Oct 19 2020 at 06:50):
I think snomed wins here
Jose Costa Teixeira (Oct 19 2020 at 07:13):
This doesn't mean that you can't use ATC, but then you're stating that those above are equivalent?
Last updated: Apr 12 2022 at 19:14 UTC
