Stream: implementers
Topic: Medication.identifier is missing?
Simone Heckmann (Aug 09 2017 at 12:52):
Why doesn't the Medication resource have an identifier?
I can see many use cases, where a Medication might be referenced by it's common identifier (RxNorm in the US, PZN in Germany...) but since it doesn't have an identifier, it can't be referenced in this fashion...
Is there a reason behind this? I was under the impression that all DomainResourcen should have an identifier.
Jose Costa Teixeira (Aug 09 2017 at 12:53):
There is medication.code
Jose Costa Teixeira (Aug 09 2017 at 12:55):
There is also a discussion to do changes to the medication the identifier(s) will likely be addressed (GTIN, PCID, PZN, UCD...) but unless it's for defining "catalogs/formularies", the medication.code is the one to be used.
Simone Heckmann (Aug 09 2017 at 13:43):
In my usecase it's for defining catalogs :) I'd believe most Medication products make for pretty static Medication resources, so most of ther times, there's no point in maintaining them redundantly in every system and communicating the identifiers will in most cases be 'nuf said.
Jose Costa Teixeira (Aug 09 2017 at 13:44):
Isn't code sufficient? Or you think it is misplaced?
Jose Costa Teixeira (Aug 09 2017 at 13:46):
that is actually the idea behind the use of code: in clinical uses, you consider the code as static, and that is it.
Jose Costa Teixeira (Aug 09 2017 at 13:47):
AFAIK, there are two types of identifiers: the ones we see in many resources, which are mentioned as "additional identifiers" or "business identifiers"
Jose Costa Teixeira (Aug 09 2017 at 13:47):
and there is also the resource identifier itself (part of the metadata, it is there for all resources)
Jose Costa Teixeira (Aug 09 2017 at 13:50):
one example of a resource that has external identifier - perhaps this is what you are looking for -
{
"resourceType": "Device",
"id": "f001",
"identifier": [
{
"system": "http:/goodhealthhospital/identifier/devices",
"value": "12345"
}
],...
Stefan Lang (Aug 09 2017 at 13:50):
I think this is about the business identifiers - "id" is out of scope here.
Jose Costa Teixeira (Aug 09 2017 at 13:50):
medication does not have the identifier, but has the medication.code.
Jose Costa Teixeira (Aug 09 2017 at 13:51):
I agree, @Stefan Lang , just want to expose the several ids. I am looking at catalogs and I think medication.code is the relevant attribute - but perhaps I am wrong
Stefan Lang (Aug 09 2017 at 13:51):
Basically, RXNorm, PZN etc. are Identifier systems. Every new product gets an identifier. So using code would be technically possible, but then the code system would have to be permanently updated.
Stefan Lang (Aug 09 2017 at 13:54):
If we would agree using code, it would also be required to maintain these identifying systems as code system (and value set)...
Jose Costa Teixeira (Aug 09 2017 at 13:57):
ok, this is where I am lost (my ignorance) - i believe all these code systems have a formal update process, or they can be assumed to have one.
Jose Costa Teixeira (Aug 09 2017 at 13:58):
and in some cases you can use the internal code sets
Stefan Lang (Aug 09 2017 at 13:58):
Not for a more or less public list of medications, obviously ;)
Jose Costa Teixeira (Aug 09 2017 at 14:00):
indeed. I guess I'm asking whether we would put PZN as an identifier, and InternalCode as a code.
Jose Costa Teixeira (Aug 09 2017 at 14:02):
i would hope not. I lack the semantics knowledge, but to me each of these values is a code (which we can use an identifier). So, technically, I see this as "every new product gets a code, which is then possibly used as an identifier". But again, my ignorance in these matters (codes/identifiers) is vast.
Jose Costa Teixeira (Aug 09 2017 at 14:04):
I am thinking that things that are "more or less static" are actually dinamic - slowly changing, but changing.
Stefan Lang (Aug 09 2017 at 14:05):
basically, for a code you need a well defined list of valid codes, while for an identifier, you only need a name space (aka NamingSystem), even if someone somewhere for sure maintains a a list of every identfying value that's ever been released.
Jose Costa Teixeira (Aug 09 2017 at 14:09):
if i read correctly, is this similar to "if I use a code, then I have to make sure about that the code set i am using is well governed so that my code has the characteristics to uniquely identify what I mean, while for identifiers, i assume that this is done by definition, and i just have to say the value of the identifier, and the uniqueness/unambiguity is guaranteed"?
Jose Costa Teixeira (Aug 09 2017 at 14:09):
is my rephrasing approximately correct?
Jose Costa Teixeira (Aug 09 2017 at 14:09):
in any case, is there any inconvenience to use a code instead of an identifier, in this case?
Stefan Lang (Aug 09 2017 at 14:28):
Right, that's the difference from an implementer's point of view. Terminologists of course would add a lot of other differences.
Stefan Lang (Aug 09 2017 at 14:29):
The inconvenience is that someone has to maintain the code system (including the CodeSystem resource) when using code ;)
Jose Costa Teixeira (Aug 09 2017 at 14:30):
enter Catalogs, where we want to exchange information like "here are the products allowed for prescription in this hospital/department, for 2017"
Jose Costa Teixeira (Aug 09 2017 at 14:31):
my assumption is that there is always this governance mechanism, even if we do not care for it.
And going to the point of Simone, if we have to use sometimes a code, sometimes an identifier, I would just stick to code.
Stefan Lang (Aug 09 2017 at 15:14):
That's probably the way to go, though you lose validation on the way.
Simone Heckmann (Aug 09 2017 at 16:48):
The thing is that with STU3, the logical references have been introduced to allow for the exchange of Artefacts that are known to both the sending and the receiving system by the same business identifier without having to explicitly bundle them into the document/message/whatever.
http://build.fhir.org/references.html#logical
This also comes in handy, if a system only knows a resource by it's identifier but has no additional information and doesn't want to create a resource instance just to hold the identifier.
What I was missing before is that this kind of exchange is also possible for Medications by using the code element in the MedicationStatement instead of the reference. It just tripped me, that in this case, the mechanism is different even though the use case seemed consistent with what the logical reference is supposed to do.
But as said, logical references don't work for Medication, as they rely on the identifier attribute.
I'm not really sure right now if that is an issue or not. Is FHIR consistent with offering code as an alternative to reference, whenever a Resource points at a medication? I didn't check...
Simone Heckmann (Aug 09 2017 at 16:52):
Oh. Here's one:
http://build.fhir.org/adverseevent.html
In this case, you couldn't just use the code of a Medication instead of a reference, and with logical reference out of the picture, you'd have to create an instance of Medication, even if all the information you know is just the code.
Jose Costa Teixeira (Aug 09 2017 at 16:56):
don't follow the logical reference bit, but indeed your point seems correct. you'd have to create an instance of medication.
Jose Costa Teixeira (Aug 09 2017 at 16:57):
now, questions: 1. Is that bad? you could create a contained resource (I don't mean this as a workaround, but as a design approach: you create a "product" and you say "this is the thing that I am referring to, it is a medication, but I just know the code".
Simone Heckmann (Aug 09 2017 at 16:57):
There are 3 more:
http://build.fhir.org/catalogentry.html
http://build.fhir.org/flag.html
http://build.fhir.org/group.html
but I don't think there's a use case for logical references there, all te others resources referencing Medication use medication[x] with CodableConcept or Reference as type
Jose Costa Teixeira (Aug 09 2017 at 16:58):
2. If the medication gets redesigned to support that it can be as simple as containing only the code, wouldn't that help?
Simone Heckmann (Aug 09 2017 at 16:59):
1. jep. bad. You can't search on contained resources, but you can search on reference.identifier. Medication Codes are definitely something you may want to be able to search on.
Jose Costa Teixeira (Aug 09 2017 at 16:59):
as for the catalogEntry, that is under construction. Which reminds me, catalog call starts now :)
Jose Costa Teixeira (Aug 09 2017 at 17:00):
Ah, ok. Then it may make sense to add an identifier. Is that your suggestion? an identifier that can simply duplicate /replace the medication.code?
Simone Heckmann (Aug 09 2017 at 17:01):
As I said, I don't think a CatalogeEntry has a strong use case for logical references, I mean - what's the point of cataloguing Codes ...? You'd be basically making a CodeSystem. Oh wait, there's a resource for that :D
Simone Heckmann (Aug 09 2017 at 17:02):
No, Actually right now I rather tend to making sure that wherever it makes sense, references to medication should allow either reference or CodableConcept.
Jose Costa Teixeira (Aug 09 2017 at 17:04):
CatalogEntry is a bit more fun than that. Listing products and their characteristics and relations
Jose Costa Teixeira (Aug 09 2017 at 17:06):
i assume you are referring to valueset, i will try to see if there is any overlap.
Simone Heckmann (Aug 09 2017 at 17:06):
Maybe change AdverseEvent.suspectEntity.instance to AdverseEvent.suspectEntity.instance[x] with choice of CodableConcept or reference like here with item[x]: AdverseEvent.suspectEntity.instance ...?
Or just wait and see if anyone implementing AdverseEvent ever complains... :D
Simone Heckmann (Aug 09 2017 at 17:33):
What I menat to say was that if all you know about the catalogue item is the code, your catalogue will be exactly the same amount of fun as a CodeSystem or ValueSet. So you are right: If the scope of the Catalogue is to list products and their characteristics then a logical reference to an item is pointless, hence no need to change anything.
Jose Costa Teixeira (Aug 09 2017 at 17:40):
indeed, if we have a catalog of a list of medications for which we only know the code, that is pretty useless waste of bandwidth. I will keep in mind to send you a first draft example of a catalog, when we have it
Simone Heckmann (Aug 09 2017 at 17:44):
Hold on. Quoting Scope and Usage of Medication: "The medication resource can be used to describe a compounded (aka extemporaneous or magistral) product that is manufactured by the pharmacy at the time of dispensing. In this case there will be multiple ingredients which are typically base chemicals (for example, hydrocortisone powder) and there may be other ingredients that are manufactured products (for example, Glaxal Base)."
In that case, the Medication wouldn't have a code, right? So how do you re-identify such a Medicaton instance across systems, if you don't have an identifier?
Jose Costa Teixeira (Aug 09 2017 at 17:45):
Yes, but i hope i mentioned before, there is some restructuring on Medication, to address exactly such examples.
medicationResource can be an identifier (in the sense "a data structure that identifies something) OR there may be a need to be a more descriptive set of data.
Simone Heckmann (Aug 09 2017 at 17:49):
ok thanks, I was just worried that I accidentialy talked anyone out of the idea that adding an identifier was a good idea :D
Jose Costa Teixeira (Aug 09 2017 at 17:58):
I think one question will be if it is clear or it it can cause confusion - some implementers using medication.code, others using identifier.
Lloyd McKenzie (Aug 09 2017 at 20:40):
Most places where Medication is referenced, there should be a choice of CodeableConceot|Reference(Medication). Identifiers are generally not used to define "kinds" of things. If we were to have identifier on Medication, that would mean there was a barcode on each pill that was unique to that pill. (And we may in the future actually get there - but for now that would definitely be extension territory.)
Lloyd McKenzie (Aug 09 2017 at 20:40):
The closest we get is lot numbers.
Simone Heckmann (Aug 10 2017 at 19:29):
@Lloyd McKenzie
"The medication resource can be used to describe a compounded (aka extemporaneous or magistral) product that is manufactured by the pharmacy at the time of dispensing"
They're not a "kind" , and they don't have codes.
Scott Robertson (Aug 10 2017 at 20:25):
even in the case you describe, the Medication resource is describing the product prepared as a recipe, not the specific entity created at that moment. If you included specific information about each dose entity (each tab, cap, suppository, ... not even sure the equivalent for a liquid) then you would have an entity and could use an identifier
Jose Costa Teixeira (Aug 10 2017 at 20:27):
From what I am reading, I think the identifier would be on the "instance" while the codes are on the "kind", correct?
Jose Costa Teixeira (Aug 10 2017 at 20:28):
I still have to write down some ideas for the "kind" vs "instance" part, but an identifier on the instance could help also in the old discussions about RFIDs, barcode HRF vs Carrier...
Scott Robertson (Aug 10 2017 at 20:29):
I agree that the Medication resource does not follow the norm in terms of id. I understand that Pharmacy took this situation to FMG, that id didn't really fit in Medication, and received an waiver. I'm looking for that discussion.
(This is not easy to search for. I'll continue to look as I have time)
Scott Robertson (Aug 10 2017 at 20:31):
@Jose Costa Teixeira yes, identifier is on an instance; code is on a concept.
Jose Costa Teixeira (Aug 10 2017 at 20:31):
thanks Scott.
Scott Robertson (Aug 10 2017 at 20:37):
An RFID embedded in a tablet would be an identifier on that instance (tablet) - assuming each RFID is unique. But an RFID/barcode on a bottle/box/container is more problematic: is it identifying the bottle/box/container (instance), or is it describing the content (concept/kind). In pharmacy, the descriptor used (NDC, RxNorm, IDMP terms, etc) describe the concept of the medicinal product. (Well, NDC actually refers to a specific bottle size for the medicinal product, but is normally used to refer to the medication (except for billing purposes))
Scott Robertson (Aug 10 2017 at 20:39):
Logisitic operations would be interested in tracking the packages, bundles, pallets, etc. Medication resource is not intended for that purpose
Jose Costa Teixeira (Aug 10 2017 at 20:43):
i understand that identifier may not uniquely identify one instance. for example if we only have lot numbers, then that is the granularity we have, and one identifier can correspond to 1000s of instances. I think that is ok. Not perfect, but ok.
Lloyd McKenzie (Aug 10 2017 at 21:36):
@Simone Heckmann It's still not typically an "identified" instance - where one jar of the compounded product has a distinct identifier from another jar (where that identifier is distinct from the identifier of the dispensing event itself). Medication.identifer would only make sense if it was unique to an individual jar/bottle/pill/etc. I'm fine with defining an extension for those edge cases where this occurs (vials of certain medications might indeed have unique identifiers per vial), but I don't think it's part of core for the pharmacy space.
Grahame Grieve (Aug 10 2017 at 22:32):
it's possible to assign an identifier in a Medication Formulary. However I think there's an underlying confusion here
Grahame Grieve (Aug 10 2017 at 22:34):
early ISO work around terminologies described 3 things:
- identifiers
- codes
- appelations
Grahame Grieve (Aug 10 2017 at 22:34):
codes are used to distinguish things by the properties
Grahame Grieve (Aug 10 2017 at 22:35):
identifiers are used to label instances of things that are only differentiated by the identifier assigned/affixed to them - in other words, they are not intrinsically differentiated by any property they have
Grahame Grieve (Aug 10 2017 at 22:35):
appelations are codes for which there is (and can be) only one instance of the thing
Grahame Grieve (Aug 10 2017 at 22:36):
a classic example of an appelation is a code for a country
Grahame Grieve (Aug 10 2017 at 22:36):
We typically treat appelations as codes, but they can also be treated as identifiers.
Grahame Grieve (Aug 10 2017 at 22:36):
some medication codes are actually appelations .. but I haven't seen anything that shouldn't be treated as code myself
Øyvind Aassve (Nov 06 2018 at 15:05):
I see that Medication.identifier is included again in R4. Is this meant for medications that are mixed specifically for a patient for example by a hospital pharmacy? If so, does that mean that you must include either M.identifier or M.code to identify the medication?
Lloyd McKenzie (Nov 06 2018 at 15:34):
Could be for patient-specific traceable administration doses. Could also be where the manufacturer puts serial numbers on individual doses (which apparently is happening in a few places now)
Melva Peters (Nov 06 2018 at 21:25):
Lloyd is correct, this identifier is for identifiers like serial numbers rather than codes (like NDC or RxNorm). The Medication.identifier was included in the latest build due to use cases that were presented. Codes such as NDC or RxNorm or an organizational codes go in Medication.code.
Øyvind Aassve (Nov 07 2018 at 11:15):
Great, thanks!
Last updated: Apr 12 2022 at 19:14 UTC
