Stream: IPS
Topic: Slicing of Medication.code
Øyvind Aassve (Jul 02 2020 at 08:31):
Hi,
one question regarding slicing of Medication.code. In the textual explanation there are described five levels of IDMP-codes, but these are not reflected in the build-profile for Medication. In the build profile there are only slices for atc and snomed. Is there are reason for this?
Christof Gessner (Jul 02 2020 at 08:58):
As IDMP is still developing, the five levels are anticipating the future logical structure of IDMP identifiers. But no practical use as of today.
Øyvind Aassve (Jul 02 2020 at 09:48):
Thank you Christof, so the plan might be to add slices as identifiers/ codes for the 5 IDMP levels are developed? Is there expected to be any guidance on what levels of IDMP SNOMED CT-codes could be used?
Christof Gessner (Jul 02 2020 at 11:57):
I think it is SNOMED CT instead of IDMP identifiers, for the time being. In that sense, this is a valid question: should we use value sets of SNOMED codes to "simulate" the IDMP levels? And how would the slicing work in that case?
Øyvind Aassve (Jul 02 2020 at 12:07):
OK, we can ponder that a little bit up here as well. In the first round we will be slicing IDMP-levels on basis of Norwegian identifiers.
Giorgio Cangioli (Jul 02 2020 at 14:37):
The slice is open so you can use whatever you want as product code.
Giorgio Cangioli (Jul 02 2020 at 14:41):
These slices gives the idea that ATC and SNOMED are for the time being the most reasonable solutions for cross-jurisdictions product identification, waiting for more widely usable product identifiers (IDMP)
Giorgio Cangioli (Jul 02 2020 at 14:49):
based on the latest discussions the basic idea is that the IDMP identifiers will go in the medication.code, but since the cardinality is 1..1 they need to be represented into different codings. The question here is if they are actually representing the same concept... I hope this might be part also of the discussion in the UNICOM project (https://unicom-project.eu/)
Jose Costa Teixeira (Jul 02 2020 at 15:00):
current guidance in FHIR is:
"The concept may be coded multiple times in different code systems (or even multiple times in the same code systems, where multiple forms are possible, such as with SNOMED CT). Each coding (also referred to as a 'translation') is a representation of the concept as described above and may have slightly different granularity due to the differences in the definitions of the underlying codes. "
Jose Costa Teixeira (Jul 02 2020 at 15:01):
In my opinion, this (or several other cases), are NOT slightly different granularity - these are completely different concepts - a PhPID and a PCID are really not a translation.
Jose Costa Teixeira (Jul 02 2020 at 15:02):
(we had a similar discussion with the vaccine code (MMR) and a GTIN)
Jose Costa Teixeira (Jul 02 2020 at 15:03):
so perhaps we need to ask for a change FHIR that CodeableConcept.coding should support slightly different or wildly different granularity of related concepts
Jose Costa Teixeira (Jul 02 2020 at 15:04):
(or find some other way, I am not sure what is best). For me it is absolutely different to have a GTIN and to ahve a PhPID. I think UNICOM will feel that pain indeed
Christof Gessner (Jul 02 2020 at 18:28):
@Jose Costa Teixeira isn't this the old well-known TERMINFO problem? i. e. choose between creating complex data structures to capture those different granularities vs. "hiding" the complexity in the code system? FHIR slicing based on CodeSystem (or on "granularity") might deliver the best of both worlds?
Jose Costa Teixeira (Jul 02 2020 at 18:29):
not really, i think. I would not want to create a data structure for each level if that is what you are pointing at.
Jose Costa Teixeira (Jul 02 2020 at 18:31):
Slicing is a good choice. The thing that I am concerned is that the slicing is done on a data element that is (by its definition) meant to support translations, i.e. same granularity or slightly different
Christof Gessner (Jul 02 2020 at 18:33):
data element or data type? add more metadata to slicing, for use cases that want to know more details?
Christof Gessner (Jul 02 2020 at 18:34):
like a "structure behind the structure"? adding more layers between codesystem and data elements, beyond value sets?
Rob Hausam (Jul 02 2020 at 22:37):
The slicing on Medication.code is on the element, and therefore at the CodeableConcept level. So in an given instance, whichever slice (or no slice) is matched, multiple Codings can be included which can deal with the differences in granularity (even potentially "extreme" differences) as long as the overall meaning is the same (i.e. all of the Codings are representing the same "medication" [e.g. "penicillin"] at whatever "level" each code represents).
Jose Costa Teixeira (Jul 02 2020 at 22:58):
Maybe I was looking at a different place. this is about slicing on the coding element, right?
Jose Costa Teixeira (Jul 02 2020 at 23:02):
http://build.fhir.org/datatypes.html#codeableconcept mentions slightly different granularities
Rob Hausam (Jul 03 2020 at 02:50):
What we are doing is slicing on the 'code' element (a 1..1 non-repeating element, by the way), at the CodeableConcept data type level. The slicing is not at the Coding level. Multiple Codings, according to the usual rules, are allowed for any instance.
Jose Costa Teixeira (Jul 03 2020 at 04:45):
Ok, I was not thinking that.
I thought this was about supporting several codes at once (i.e. "I took Ben-U-Ron which in my country is the common brand for Paracetamol")
Giorgio Cangioli (Jul 03 2020 at 08:35):
Yes the slice is at the code level, I don't see however how this change the initial question of @Jose Costa Teixeira if it is meaningful to convey different IDMP identifiers in the medication.code.
Since the cardinality of the code is 1..1 the only way is to use different codings for the same code, that in principle should represent the same "concept" ...
Giorgio Cangioli (Jul 03 2020 at 08:37):
if I need to share only one code (and it could be also any of the IDMP identifer) the medication.code is fine
Giorgio Cangioli (Jul 03 2020 at 08:40):
I believe there is still an open issue when multiple codes should be provided.
This is relevant for cross-jurisdictions sharing:
I send all what I know (national product code, ATC code, (future) IDMP identifiers) and the receiver pick up those is able to understand
Christof Gessner (Jul 03 2020 at 09:42):
This is what I had in mind writing "more layers between codesystem and data elements". Let's say I have one data element 1..1 and I am using certain codes (ATC, or national etc.) to describe my concept, I am looking for a way to say "I am using this code from that codesystem with the following intention or implied meaning in relation to the given data element : { exact | broader | narrower | example | attribute | instance-of | similar-to | part-of | has-part | ... }". Probably I am thinking of something like qualifiers or annotations, as it can be done within SNOMED per post-coordination. But how can it be done for ATC? Or for a national medication code? If such logic is implemented as an attribute of the slicing or of the value set binding, it is not visible to the receiver. Coding.userSelected is possibly just one specific example of such a "qualifier".
Jose Costa Teixeira (Jul 03 2020 at 14:02):
and config.userSelected is not something we can really rely on. (it may not be populated, but we can force one)
Jose Costa Teixeira (Jul 03 2020 at 14:15):
The situation being as is, I do not know if:
-
we can expect that all systems will understand from that PhPID L1 is broader than PhPID L4, or that PZN has really nothing to do with MPID...
or -
it would be good or bad to add some extension to coding element, for Medicinal Product codes and similar purposes (is this your qualifier, @Christof Gessner ?) I do not know how that would look like.
- Add a "codeType" to the Coding datatype which will contain a code for concept type: mpid, phpid1, phpid2, pcid, gtin, pzn... (doesn't sound pretty but i throw it out there anyway)
Jose Costa Teixeira (Jul 03 2020 at 14:20):
at this moment we can create slices for a non-repeating element (I thought that was not kosher).
I don't know what value we add by slicing .
Rob Hausam (Jul 03 2020 at 16:35):
I think the primary added value of this is visibility of the explicitly modeled choices. It makes it easier to see that you can use a SNOMED code, or an ATC code, for example. Or it could include one or more of the levels of the IDMP codes, if we want to make that explicit (we did pretty much have that in IPS at one point - but, as noted, IDMP isn't really "there" yet, so we removed that for now). When there are separately modeled slices the choices seem much easier to see than if instead you simply create and bind to a value set including the content from all of the possible code systems (and in IDMP the multiple "levels" of the codes). One aspect to consider is that If multiple Codings (with different terminologies and/or levels of granularity) are used in an element instance, as we've described, there is a risk (and likelihood) of having a particular instance match multiple slices. That generally has been frowned upon, if not prohibited - but I think that actually the same considerations apply when the element is repeating, so I don't think this is (or it shouldn't be) necessarily a show stopper.
Øyvind Aassve (Jul 04 2020 at 20:07):
I am no sure I get why there is a likelihood of instances matching multiple slices. Lets say if you divide according to the 5 IDMP-levels, the granularity of the code will depend on the level that is expressed and all codes on that level will contain the details required by that level. An an instance will be categorized in the slice according to the level of detail. Or the instance might use a different code system like SNOMED or a national code system. How would an instance match multiple slices (unless one count that they are all more detailed descriptions of a pharmaceutical product)?
Lloyd McKenzie (Jul 04 2020 at 22:53):
The instance could have multiple Codings on the code.
Øyvind Aassve (Jul 05 2020 at 09:15):
OK, my understanding is then that it would not be possible to have an instance satisfying multiple IDMP-level based slices. Unless you populate several levels on purpose because you dont know what the receiver can read? The same level of coding could also be represented in SNOMED CT, but there are maybe not so many instances that would populate both SNOMED CT and IDMP? On the other hand I expect a need for ATC to be used as a parallelle coding scheme in Norway, as this is basis for some reporting requirements.
Lloyd McKenzie (Jul 05 2020 at 13:53):
It would be common to populate with multiple codings expressing different levels - not just because you might not know the recipient but because the same instance might be sent multiple places. As a rule, you want to send the same information to everyone, not to have custom interfaces for each recipient.
Lloyd McKenzie (Jul 05 2020 at 13:53):
So you send all code systems and all granularity levels you're capable of expressing that you expect to be needed by someone, somewhere.
Jose Costa Teixeira (Jul 05 2020 at 14:09):
@Øyvind Aassve Note that ATC code is technically not a code for the drug. It's a classification where some drugs may have 2 ATC categories, some have none
Jose Costa Teixeira (Jul 05 2020 at 14:11):
@Lloyd McKenzie sending all the granularities as code translations? Does that play well with the definition of "additional codes" which reads something like "same granularity or slightly different".
Jose Costa Teixeira (Jul 05 2020 at 14:12):
one thing is to send RXNorm and NDC, the other thing is to send all the IDMP level stack.
Jose Costa Teixeira (Jul 05 2020 at 14:14):
(As a side note, IMO sending the IDMP identifiers is not the single viable solution for cross-border identification of products - I'm just looking at this from the FHIR definitions and the discussions we had recently)
Lloyd McKenzie (Jul 05 2020 at 14:42):
So long as the code is a proper coding for the drug, the granularity can be very different - one code that says "Penicillin" and another that says "APO Amoxicillin 100mg caplets" and any concept between those granularities is completely fine to appear as alternate codings. What you can't do is send a code that says "blue" and another code that says "oral" - because those aren't codings for the drug.
Jose Costa Teixeira (Jul 05 2020 at 15:09):
Lloyd McKenzie said:
the granularity can be very different - one code that says "Penicillin" and another that says "APO Amoxicillin 100mg caplets"
that is what I understand from our discussion last week - you can send largely variant codes - my comment is that the spec says this:
Each coding (also referred to as a 'translation') is a representation of the concept as described above and may have slightly different granularity due to the differences in the definitions of the underlying codes.
Those examples are not slightly different granularities. Am I misreading the spec?
Jose Costa Teixeira (Jul 05 2020 at 15:10):
anyway, ATC is not a drug code so something should be done for that.
Øyvind Aassve (Jul 05 2020 at 15:34):
Regarding ATC - some here have mentioned an alternative where ATC could be represented as an attribute on Medication rather than coding.
Øyvind Aassve (Jul 05 2020 at 15:35):
Is that a feasible option?
Lloyd McKenzie (Jul 05 2020 at 17:20):
@Melva Peters
Rob Hausam (Jul 05 2020 at 17:38):
I agree with @Lloyd McKenzie 's idea, but not the example as it is - "Penicillin" and "APO Amoxicillin 100mg caplets" are not different granularities, but are different drugs and therefore different concepts, so codes for both of them would not be legitimate in a single instance. But if you change the first one from "Penicillin" to "Amoxicillin", then having both levels of granularity should be fine.
Lloyd McKenzie (Jul 05 2020 at 17:41):
My understanding was that Penicillin was a broad category that covered a number of similar drugs - including Amoxicillin. A quick web-search says that Amoxicillin is a Penicillin-type drug?
Lloyd McKenzie (Jul 05 2020 at 17:43):
I guess one of the challenges here is that Penicillin is both the name of a specific drug and of a family of drugs. My intention had been to convey the code for the 'family' - in which case I think the example still holds.
Lloyd McKenzie (Jul 05 2020 at 17:43):
An equivalent would be a code for "Ace inhibitor" down to the code for a specific manufactured formulation of a specific drug as packaged in a particular way in a specific country.
Rob Hausam (Jul 05 2020 at 17:44):
Yes, that's right. It can be confusing. "Penicillins" (or maybe "Penicillin-type drug") is a drug class, which does include Amoxicillin, but "Penicillin" is a specific drug in that class which is different from Amoxicillin.
Rob Hausam (Jul 05 2020 at 17:57):
I think that including a Coding for both the drug class and the specific drug in the same data type instance is really stretching the idea of the CodeableConcept to (and maybe beyond) the limits. But various "levels" of description of a particular drug would generally be fine (in my opinion). So you could have Codings for "Lisinopril" and "Lisinopril 10 mg tablet" and "Zestril 10 mg tablet bottle of 100" (or the equivalents), but if I want to also convey that they are in the drug class of "ACE inhibitors", I would do that separately. That's my take. I'm not entirely certain what Pharmacy is recommending on this, so I would be happy to hear from Melva or anyone else about that.
Rob Hausam (Jul 05 2020 at 18:06):
I should also add that when prescribing Penicillin as a drug (not the class), it's going to be specified as "Penicillin V" (typically Penicillin V potassium) or "Penicillin G" (as sodium, potassium, benzathine or procaine), so just stating "Penicillin" (singular) alone probably isn't sufficient and it normally wouldn't be used.
Christof Gessner (Jul 05 2020 at 19:36):
The exclusion of "blue pill", "red pill", "oral medication" etc. from the list, as proposed by @Lloyd McKenzie , is based on the a-priori assumption that the concept granularity may vary only along the one axis that points from "generic medication class" to "specifiied packaged medicinal product with specific ingredients in specific strenghts". What determines the direction and range of that axis in CodeableConcept or Coding? The indicated slicing options, maybe?
Lloyd McKenzie (Jul 05 2020 at 21:20):
The range and axis of the concept is driven by the attribute - and also by the availability of other attributes to capture other characteristics like form & route.
Melva Peters (Jul 06 2020 at 20:41):
Sorry to come in to this late. I was trying to understand the use case for including multiple levels of code in a single instance of medication. As far as including ATC in a different attribute, there isn't another attribute in medication, but there is in medicationKnowledge. Medication is used for prescribing, dispensing, administering, etc but MedicationKnowledge is intended to be used for formularies, drug knowledge bases. You can use the MedicationKnowledge.medicineClassification attribute.
Jose Costa Teixeira (Jul 06 2020 at 20:50):
Since medicationKnowledge has the attribute Classification, I would use that
Jose Costa Teixeira (Jul 06 2020 at 20:51):
this could even work for cross-border prescription: an extension containing a link from Medication to MedicationKnowledge.
Meaning "this is the medication, and in that box over there you will find a few more attributes of the medication"
Øyvind Aassve (Jul 07 2020 at 08:49):
@Melva Peters - the discussion In Norway was related to whether ATC is a good fit for coding in Medication for use-cases like prescribing, dispensing that we are about to implement (like IPS), or if it would better be defined as an attribute (like form). To what extent do you support the argument that ATC could better be defined as an attribute in Medication? What would be the reason this is handled differently in Medication and MedicationKnowledge?
Jose Costa Teixeira (Jul 07 2020 at 10:55):
ATC is a classification, it is not a product code
Øyvind Aassve (Jul 07 2020 at 11:35):
Yep, and the question is then, maybe somewhat philosophical - should classification in the Medication resourcce be coded in the same manner as product code (as it is done now), or would it be as good to put it in a separate attribute (ex called classification) in the same way as is done for MedicationKnowledge. Any thoughts?
Jose Costa Teixeira (Jul 07 2020 at 11:56):
I do not see a reason why they should be in the same attribute.
Jose Costa Teixeira (Jul 07 2020 at 12:07):
I see reasons for them to be in different attributes :
- they mean different things
- the existence or absence of one does not allow conclusions about the other
Melva Peters (Jul 07 2020 at 13:56):
@Øyvind Aassve I don't believe that ATC is a good fit for coding for medication for prescribing and dispensing. My understanding is that ATC is a classification system. According to the WHO website "The purpose of the ATC/DDD system is to serve as a tool for drug utilization monitoring and research in order to improve quality of drug use." There are 5 levels to the ATC hieararchy and the most granular level is "metformin" or "amoxicillin". While this might be suitable for prescribing in some cases, it definitely isn't appropriate for dispensing. Since this is a classification system, that's why I support it being an attribute in medication - it would need to be an extension as the medication resource has been stripped down to include only those attributes that we believed are necessary for prescribing, dispensing, administering medications. The classification of the drug isn't one of those attributes. It was included in MedicationKnowledge as it is information about a drug. You can use the medication code to look up the medicationKnowledge to get the classification.
Øyvind Aassve (Jul 07 2020 at 14:03):
Thank you Melva, would you consider that to be important enough to be considered as a possible change request for the IPS Medication Profile - where it is sliced under Medication.code? I guess IPS can be an inspiration for many other Medication-profiles.
Øyvind Aassve (Jul 07 2020 at 14:17):
@Jose Costa Teixeira That means you support a change in the IPS-specification?
Lloyd McKenzie (Jul 07 2020 at 14:21):
The degree of coding of a Medication isn't binary where you've got classifications and product codes. Rather, it's a continuum from high level classifications down to very fine-grained codes. It might be possible to get agreement on dividing those potential codes at the extremes, but it would be rather hard to do as you get into the middle. It's not clear why there's a problem simply sending alternate codings. If we split it in two, then people will argue that they need a high-level classification and a low-level classification or a general product code and a detail product code - essentially wanting a separate attribute for each level of categorization or coding they care about - and there's no way we're going there.
Jose Costa Teixeira (Jul 07 2020 at 14:28):
Lloyd McKenzie said:
The degree of coding of a Medication isn't binary where you've got classifications and product codes. Rather, it's a continuum from high level classifications down to very fine-grained codes.
Right, and I don't think that the fact that levels are different is the main driver for separating. The main driver I'd consider is what has happened in recent projects - I think EPSOS, openMedicine (UNICOM is just starting) - that people will use that continuum to imply equivalence, or use only that for interoperability. Given that history (and the fact that people ATC and later we found out that ATC was not adequate as a drug identifier), I do support that classification (ATC, schedule etc) is not in the same place as product code(s) - at least for prescription and dispense. Product code uniquely identifies a concept, independently of how broad that concept is. ATC doesn't serve that purpose.
Jose Costa Teixeira (Jul 07 2020 at 14:30):
for Patient Summary, the need is less evident but with the information I have now, I still support that difference - and I think my argument is what you wrote @Øyvind Aassve : "IPS can be an inspiration..." as we've seen in EPSOS and then we realize we have to spend a few more euros to revise that.
Jose Costa Teixeira (Jul 07 2020 at 14:31):
Øyvind Aassve said:
Jose Costa Teixeira That means you support a change in the IPS-specification?
Yes. For medication prescriptions and dispense I would support something else - adding a link from a Medication to a MedicationKnowledge.
Jose Costa Teixeira (Jul 07 2020 at 14:32):
Lloyd McKenzie said:
essentially wanting a separate attribute for each level of categorization or coding they care about - and there's no way we're going there.
Happily agree that that we should NOT try to do that - that is a very common temptation though.
Lloyd McKenzie (Jul 07 2020 at 15:05):
If people presume multiple codings are equivalent, they're in trouble all over FHIR. In general, very few codes are ever equivalent. They may be close, but identical meaning is uncommon. I don't consider that a good reason to split out multiple attributes
Øyvind Aassve (Jul 07 2020 at 15:16):
I agree that it is fully ok with multiple codings - given that the codings actually are adequate for identifying the relevant concept (here Medication) in a useful manner. I think this is the main question here - whether ATC at all is useful as an identifier for Medication, and should be considered a code-element? Any input @Melva Peters
Lloyd McKenzie (Jul 07 2020 at 15:19):
"Useful" is dependent on use-case. Generally when it comes to medications you want a reasonably fine level of detail, but some use-cases just want high-level categorizations. E.g. "Is the patient on an ace inhibitor? (Y/N)". Because the objective with FHIR interfaces is to spit out the data that any consuming system might want, good practice is to share whatever codings you know at whatever level of granularity they exist. Consuming clients will pay attention to those they find useful.
Øyvind Aassve (Jul 07 2020 at 15:37):
OK @Lloyd McKenzie , do I understand you correctly as in theory we can have some use-cases where ATC might be useful as concept identifier, in other use-cases not. The next question then is if the profiles should reflect this, they should place ATC accordingly - in either an extension or as a coded element - depending on the use-case? If so - in the context of this stream another follow-up question could be what would be the right approach for IPS? Or would it be better to desribe this in the same way in all FHIR-profiles, so that ATC is always put in code - even if in the applicable use-case it would have been better to put it as an extension - in order to drive more large-scale consistency across Medication-profiles.
Lloyd McKenzie (Jul 07 2020 at 15:56):
Using an extension is not appropriate if there's an appropriate place to send the code in FHIR - and there is. I can't think of any reason why it would ever be 'better' to have ATC in an extension...
Profiles only need to talk about ATC if there's a specific need to discuss it - a need to indicate where to send it or where to find it.
Rob Hausam (Jul 07 2020 at 16:05):
In following and thinking though this later part of the discussion, I think we should go back to how the element itself is defined. In this case, Medication.code is defined as "A code (or set of codes) that specify this medication ...". So, if the ATC code is being used in the system to specify (i.e. select, identify, etc.) the medication (for prescribing, dispensing, etc. ), then it should be appropriate to include as one of the Codings, as Lloyd has said. If it's being used in another way, then possibly it shouldn't be included there (would want to see actually how it's being used in that case).
Jose Costa Teixeira (Jul 07 2020 at 16:39):
An ATC code does not specify a medication IMO, especially for dispensing or prescribing.
Jose Costa Teixeira (Jul 07 2020 at 16:39):
in a PS, it specifies the group of medications - so that may or not work depending on how the requirements for the IPS.
Christof Gessner (Jul 07 2020 at 16:50):
May or may not. It seems that it works for a subset of drugs and a subset of ATC: "Of the 11,422 single-ingredient clinical drugs from the prescribable subset of RxNorm, 7748 (68%) had an ingredient mapping to ATC, and 7260 (64%) had both an ingredient and an administration route mapping. In other words, a mapping between a clinical drug in RxNorm and a drug in ATC (at the 5th level) for a particular administration route was found for 64% of the clinical drugs in RxNorm." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4419961/
Øyvind Aassve (Jul 07 2020 at 18:33):
From an outsiders perspective on IPS - I am thinking patient summary is possibly not the most problematic use-case with regards to the use of ATC. It is a summary of historic medications given a patient, and I dont see a big problem if an ATC-code tags along. It gives the clinican an idea of the medication the patient has used. However, in Norway, IPS is now being used as a template for Medication-profiles that are more directly targeted towards prescrption and dispensing, and for those use-cases ATC is not ideal for identifying medications.
Lloyd McKenzie (Jul 07 2020 at 18:34):
Sure - and they'd be free to require an additional code be sent. But that doesn't mean that moving ATC into an extension would make sense.
Rob Hausam (Jul 07 2020 at 18:52):
I guess it probably would be good to say that the reason that there currently is an explicit slice for atcClass on Medication.code in the IPS Medication profile is that it has been felt that there are ATC codes available at a sufficient level of granularity to be useful to represent the medications that a patient is taking (i.e. prescribed/dispensed), in the context of a patient summary. That is consistent with the statistics that Christof provided on the ability of ATC to represent the "clinical drug". Another factor for explicitly including it in IPS is that ATC happens to be one of the few reasonably comprehensive medication terminologies that is currently available and is (at least potentially) usable globally.
Rob Hausam (Jul 07 2020 at 18:54):
And you can get a sample of the codes that are available for this in ATC in the value set here.
Jose Costa Teixeira (Jul 07 2020 at 19:17):
Øyvind Aassve said:
I am thinking patient summary is possibly not the most problematic use-case with regards to the use of ATC.
Yes!
Jose Costa Teixeira (Jul 07 2020 at 19:18):
and for those use-cases ATC is not ideal for identifying medications.
indeed, because it was not meant to identify medications
Jose Costa Teixeira (Jul 07 2020 at 19:23):
Rob Hausam said:
t it has been felt that there are ATC codes available at a sufficient level of granularity to be useful to represent the medications that a patient is taking (i.e. prescribed/dispensed), in the context of a patient summary. That is consistent with the statistics that Christof provided on the ability of ATC to represent the "clinical drug". Another factor for explicitly including it in IPS is that ATC happens to be one of the few reasonably comprehensive medication terminologies that is currently available and is (at least potentially) usable globally.
I'd think, based on what I saw in previous projects: ATC was used because there was nothing else before IDMP. Depending on the use cases, adding ATC cn be useful of absolutely useless. So we just provided whatever information we had, hoping it would be useful (that is what I understand from the use of ATC which AFAIK was designed for monitoring purposes, not for clinical purposes).
Jose Costa Teixeira (Jul 07 2020 at 19:25):
Not sure this is agreeable:
ATC does not intend to have granularity to identify medications - it does identify the part of the body that is targeted and the therapeutic mechanism. that is it - it is just additional information. The fact that it is coded information does not mean it is a product code.
Rob Hausam (Jul 07 2020 at 19:34):
Here are a couple of sentences from Purpose of the ATC/DDD system:
The purpose of the ATC/DDD system is to serve as a tool for drug utilization monitoring and research in order to improve quality of drug use.
It is essential that a tool for drug utilization monitoring and research is able to cover most medicines available on the market.
So @Jose Costa Teixeira you are quite correct that ATC was designed for monitoring and research, but I guess I would say that does not entirely mean that it "was not meant to identify medications" - as to be able to monitor their usage it must be able to identify them (at some level). And, I do agree, that in large part in IPS (and elsewhere) you are exactly right that ATC was used "because there was nothing else before IDMP" - and I might add that there still isn't, because IDMP isn't actually "real" yet. And the other potential alternative of using SNOMED CT is not feasible globally (at least not yet) due to the licensing issues, as the number of drugs needed to sufficiently represent clinical practice is far too large for the full set or any reasonable subset to ever be included in the GPS.
Jose Costa Teixeira (Jul 07 2020 at 19:45):
it identifies what drugs do, not the drugs themselves.
Rob Hausam (Jul 07 2020 at 20:08):
I don't think that's quite complete or correct, but we can disagree. :)
Jose Costa Teixeira (Jul 07 2020 at 20:19):
I don't mind this minor disagreement (and it's my spider sense that is causing me to amplify this), but for correction if appropriate:
I'm not a pharmacist but I learned that ATC classifies where the drugs work in the body and the mechanism of action.
There are drugs without ATC classification, drugs with several ATC classifications, or drugs whose ATC classifications change (https://www.whocc.no/atc/application_for_atc_alterations/)
Jose Costa Teixeira (Jul 07 2020 at 20:22):
and for summaries, I think I'm just splitting hairs. The concern I have is what Oyvind and myself pointed at: it may encourage people to prescribe by ATC. or to put the ATC code in the box barcode, instead of the GTIN.
Melva Peters (Jul 07 2020 at 20:51):
I think you have to be careful about the multiple codings so that they imply the same thing. I don't think you want a set of codes included where one code is Penicillin (using ATC) and one code is Amoxicillin 250mg (using SNOMED-CT) and one code is Amoxil 250mg capsule by GlaxoSmithKline - while they are related, they clearly are not the same. I'm with @Jose Costa Teixeira on this one - I don't think ATC is a good fit for identification of medication for the purposes of prescribing and dispensing - that isn't the intent of it from what I understand. Its the same argument about why ICD isn't a good fit for diagnosis - it is a classification system. If you need to include the classification, it should be in a different attribute - so in Medication it would be an extension or you use the medication.code to look up the MedicationKnowledge.
Lloyd McKenzie (Jul 07 2020 at 20:59):
They don't have to be the same. They just have to be appropriate codings of the medication in their respective code system. It's no different than allowing ICD9, ICD10 and SNOMED codes for diagnoses in the same element. The granularity might be quite different, but they are all coding "what is the condition" within their respective code systems. There is zero expectation that multiple codings within a CodeableConcept will reflect the same granularity.
Jose Costa Teixeira (Jul 07 2020 at 21:09):
Agree that same granularity is not an expectation. But the specification does say "slightly different" - which is not the case. For the rest I agree with Melva not only because of the "code vs classification", but because of the impact on other things like prescription.
Lloyd McKenzie (Jul 07 2020 at 21:13):
If I prescribe a med, I see no issue sending a code identifying a specific drug and also saying it's an ace inhibitor in the same element. What's the issue with that?
Rob Hausam (Jul 07 2020 at 22:28):
One thing that this discussion is making me think we really should consider is, let's say using MedicationRequest.medication did I order an "ACE inhibitor" or a "Lisinopril 10 mg tablet" (for example)? I guess you could try to infer that based on assuming that the most granular (detailed) code is what was actually ordered, but that doesn't seem very satisfying or necessarily reliable or even possible. You could also look for userSelected on one of the Codings, but that might not be populated at all (I'm not getting the sense that it's been very popular so far), or if it is populated it might not be reliable (if it's populated on the wrong Coding or more than one Coding then it would be of no actual value).
Lloyd McKenzie (Jul 07 2020 at 22:33):
What the user actually saw would generally be conveyed by the text.
Rob Hausam (Jul 07 2020 at 22:39):
Yes, I anticipated that - but I'm not sure that I would trust it (including in a court of law). The consequence of that that seems to me to be that if the optional CodeableConcept.text is not populated, then we can't reliably know the intended meaning of the coded data (at least in some instances)? Whatever your thought on that is, I don't think that we can afford to go there.
Lloyd McKenzie (Jul 07 2020 at 22:48):
That's an issue with translations of any sort.
Lloyd McKenzie (Jul 07 2020 at 22:48):
You're not necessarily going to know what the user selected if it's not marked and there's no text - and the translations won't mean exactly the same thing.
Lloyd McKenzie (Jul 07 2020 at 22:48):
E.g. SNOMED vs. ICD10
Lloyd McKenzie (Jul 07 2020 at 22:49):
And putting them into different attributes isn't going to tell you which was inferred from which.
Rob Hausam (Jul 08 2020 at 02:59):
Right. I think that illustrates, though, that we need to consider how far is reasonable to go with the notion of "translation". As @Jose Costa Teixeira already quoted, the CodeableConcept spec says (emphasis mine) "Each coding (also referred to as a 'translation') is a representation of the concept as described above and may have slightly different granularity due to the differences in the definitions of the underlying codes". "Slightly" may actually be stating it somewhat too narrowly, but I don't think we should go so far as to interpret that to mean "any degree of". Each individual Coding should be a reasonably faithful representation of the intended meaning of the concept, as expressed in its particular terminology (normally choosing the most specific matching code available). So if I'm prescribing Lisinopril 10 mg tablet and I am going to include an ATC code in addition to whatever other code(s) I may have, then I think the expected choice would be 'C09AA03' for "lisinopril", rather than 'C09AA' for "ACE inhibitors, plain" (or anything at a higher level than that).
Jose Costa Teixeira (Jul 10 2020 at 20:31):
I'm looking at another project and I'm forming the opinion that it's dangerous to rely on a medication code (whatever level) and especially a classification. This creates some noise (at least I consider it noise) like "what is the right balance" or "what is the use case we are covering".
Jose Costa Teixeira (Jul 10 2020 at 20:32):
Practical impact (will probably need to document rationale): I think we should have an extension or even core link from Medication to MedicationKnowledge
Jose Costa Teixeira (Jul 10 2020 at 20:33):
we should be able to say "I dispensed GTIN 01232323" which is MedicationKnowledge1, which is a package for MedicationKnowledge2
Lloyd McKenzie (Jul 10 2020 at 21:21):
I'd be opposed to such a reference as anything other than an extension because I'm quite confident that nowhere near 80% of existing systems would have a capability like that. Most systems just have a code or a set of codes and send whatever they've got.
Jose Costa Teixeira (Jul 10 2020 at 21:37):
This is for cross-border prescription so I don't think it is expected to be in 80% of the systems, nor 80% of the cases.
Jose Costa Teixeira (Jul 10 2020 at 21:38):
but the same concept is already in our prescription systems: We send some product code and we send adjuvant information.
Jose Costa Teixeira (Jul 10 2020 at 21:38):
IHE templates have this, which if i'm not mistaken means EPSOS has this.
Jose Costa Teixeira (Jul 10 2020 at 21:39):
and we are talking about international - meaning that the code in which the prescription was issued is mostly useless when you cross the border.
Jose Costa Teixeira (Jul 10 2020 at 21:42):
so - IMO the concept of sending a code AND some additional key information would actually a good candidate for core, because it is used. But our resources don't have it, I have no idea if implementers need that, and in any case, we will never finish the debate for "which additional information to send along".
Jose Costa Teixeira (Jul 10 2020 at 21:43):
so an extension would be the thing for International profiles. I don't think most implementations would do that.
Øyvind Aassve (Jul 11 2020 at 09:30):
@Jose Costa Teixeira - just curious on your take on "international". To what extent is your opinion that in IPS FHIR IG will be limited to international use? And to the use case of "patient summary"?
Jose Costa Teixeira (Jul 11 2020 at 09:38):
perhaps I am out of context and projecting the unicom discussions, but answering your questions:
I believe the expectation is for the International Patient Summary to be used inside a country and across borders.
Also IMO, the patient summary would be used in many use cases - but it still represents a summary view. It does not capture all the details of a patient's medication record
Jose Costa Teixeira (Jul 11 2020 at 09:38):
@Øyvind Aassve
Øyvind Aassve (Jul 11 2020 at 09:46):
OK, good, as we also discussed earlier - to me there seems to be a need to make profiles domain specific . What is appropriate in a summary might not be appropirate for other use cases that might require more detail. This is what we are doing in Norway differing between base profiles - national profiling that applies to all use of a resource on national level - and domain profiles - national profiling that applies to a certain context - ex summary, prescription, exchange between EHR and charting systems etc. But it is interesting to ponder the cross-dependencis - what effects, if any, will a choice done for a summary use-case influence a lets say prescripton use-case.
Jose Costa Teixeira (Jul 11 2020 at 10:07):
Øyvind Aassve said:
What is appropriate in a summary might not be appropirate for other use cases that might require more detail.
My starting point on this is: By default, nothing about the medication in a summary is appropriate for other uses. because summary removes details by design.
In other words, inappropriate until proven OK. Which is why I'm not surprised if summary stays with ATC - having ATC can alert the physician that there is something.
Jose Costa Teixeira (Jul 11 2020 at 10:08):
(I'm not downplaying the summary, I'm alerting for reuse)
Øyvind Aassve (Jul 11 2020 at 10:23):
@Jose Costa Teixeira . I agree. In some other areas it might be easier to resuse summary-IGs, Medication is not the best case.
Rob Hausam (Jul 11 2020 at 16:29):
Maybe this was covered to some degree earlier in the topic, but regarding "re-use" of patient summary data, what types and cases for re-use are being considered (likely other than medication)?
Christof Gessner (Jul 11 2020 at 18:50):
If I understand correctly, the statements are about the reuse of specifications, not data.
Rob Hausam (Jul 11 2020 at 19:00):
Yes, that's a good point. They're of course related, and I think the question is also relevant in the context of the specifications.
Jose Costa Teixeira (Jul 19 2020 at 11:27):
I'm finding other questions about using ATC and similar high-level enough concepts:
- At some point, too high-level concepts don't serve much of a purpose any more - For example if there is an ATC code J07BX02 for Covid-19 vaccine, that only says "this person took something against covid" - you really cannot follow whether it was RNA, or virus vaccine.
- Conversely, to me there's a difference between saying "this person did not take any vaccine for covid" and "this person did not take this RNA vaccine for covid" - and expressing those as code translations is not giving me that distinction.
Lloyd McKenzie (Jul 19 2020 at 14:15):
High level codes are useful for some things and not for others. We allow them to be sent with the detail codes because of the things they are useful for - such as searches on systems that don't support subsumption (which is quite a lot of systems...)
Jose Costa Teixeira (Jul 19 2020 at 15:20):
That is valid (at least for hierarchies, which ATC kind of is), and it's useful. I'm using that.
But I think we need a way to differentiate "what was meant" (and similar codings e.g ICD-9 to ICD-10) and all the other "groups/classifications".
I have these questions while doing vaccines work and trying to rely on coding translations.
Jose Costa Teixeira (Jul 19 2020 at 15:22):
I guess this is not an issue for IPS (anyway, I expect this will get more interesting /real with IDMP and unicom).
Lloyd McKenzie (Jul 19 2020 at 16:36):
"What was meant" is what's in the text. It's also coded in a variety of ways. If all you've got is an ATC and no text, then that's what you've got. It may or may not be useful. If you need a particular granularity of coding for your use-case, you're free to mandate that in your IG.
Jose Costa Teixeira (Jul 19 2020 at 18:00):
All of this is for particular ImplementationGuides (namely IPS and other places where we need to identify medication). This discussion is for debating a consistent way to do this (that is my purpose).
Jose Costa Teixeira (Jul 19 2020 at 18:00):
I think we can require userSelected for identifying what was meant. I don't see how text would fit that purpose across borders.
Jose Costa Teixeira (Jul 19 2020 at 18:06):
I will develop my use cases for vaccines and cross-border use.
And we will use ATC. The gap is not on ATC, is whether to use it to identify a medication to continue a treatment- apparently doesn't suffice.
Øyvind Aassve (Aug 03 2020 at 08:14):
Back to the other slice for Medication.code - SNOMED CT. Does the specification (or planned use in Europe) include that SNOMED CT is thought used for covering identifiying medication brands and packages (not onlye generic drugs)? The concern is that this is is a huge set of instances, and many of these will be specific for each nation. What is the expected time frame for IDMP support for identifiers at this level?
Jose Costa Teixeira (Aug 03 2020 at 10:09):
Normally the MPIDs (identifiers for standardized product concepts at brand name level) are expected to be assigned by each country. I'm not sure it's the goal from SNOMED to catch up on all those and produce a master value set.
Jose Costa Teixeira (Aug 03 2020 at 10:10):
I did ask a confirmation, will ping when I have some feedback
Jose Costa Teixeira (Aug 03 2020 at 10:32):
Update: I think this will be handled by national SCT extensions
Øyvind Aassve (Aug 03 2020 at 11:31):
I agree this could be handled with national SCT extensions, but this requires a huge maintenance job (as there will be very many products and packages in each country). My other question was when it is expected that IDMP will these kind of identifiers. If there will be a different set of MPIDS for IDMP they would have to be mapped to SNOMED CT and these maps needs to be continuously maintained. My understanding is aslo that the SPOR database also will contain all products on national level, so that this new IDMP identifier will be much more efficient than using SNOMED CT ....
Christof Gessner (Aug 03 2020 at 12:26):
My understanding is, that SNOMED is partner in the UNICOM project and involved directly in two WPs.
Rob Hausam (Aug 03 2020 at 12:34):
My understanding is also that SNOMED is involved, but I'm not particularly clear at the moment about the nature and extent of their current and anticipated involvement. It would be good to have a clearer picture of that. I can try to do some inquiry on the SNOMED side, but anything about it that anyone is able to pass along would be good to have.
Øyvind Aassve (Aug 03 2020 at 12:35):
UNICOM is a valueable reference. The question might be what is the best strategy with regards to taking decisions at the current time - as the UNICOM project still as I understand it is in its early infancy. If it is very likely that IDMP identifiers will be used for MPIDs - it might be not the best investment to convert all you products and packages to SNOMED CT.
Øyvind Aassve (Aug 03 2020 at 12:36):
.. as a temporary measure
Jose Costa Teixeira (Aug 03 2020 at 12:48):
The update I gave was from UNICOM. (actually @Julie James).
I haven't read the documentation yet, but if SCT supports the same concepts as MPIDs and PCIDs, then wither SCT adopts those codes (hardly) or indeed a mapping would be necessary.
Jose Costa Teixeira (Aug 03 2020 at 12:50):
Hence my first reaction - i expect these codes to be mastered at country level, and I do not see a reason why SCT would map them to a common set of codes - would be easier for some agency to just maintain the set of codes for the countries, insteading of adding one more code set.
Julie James (Aug 03 2020 at 12:58):
Wow - what a lot of text to describe the age old problem of blending together the terminology model and the information model, particularly where one is basic and the other is detailed. Everything is solvable, but probably not on a Zulip chat, despite the constant desire for that to be the case. I can explain both IDMP and SNOMED options, plus how they work together.....if anyone wants the detail, please reach out directly
Øyvind Aassve (Aug 03 2020 at 14:01):
Thanks @Julie James - I guess my main curiousity for now is a ballpark perspektiver on when a set of IDMP MPIDs could be expected to be ready. And is the hash algorithm approach to produce them still the planned way to go?
Jose Costa Teixeira (Aug 03 2020 at 14:17):
The hash algorithm has been considered for PhPID, not MPIDs, AFAIK
Christof Gessner (Aug 03 2020 at 15:27):
In order to have all constituents of potential future MPID already in place, we added information on the Market Authorization Holder (including an ID) to CDA ManufacturedProduct in eHDSI Patient Summary and ePrescriptions: https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/CP-eHealthDSI-019%3A+Include+Marketing+Authorization+Holder+%28MAH%29+in+the+description+of+the+Medicinal+Product (without the full machinery of the CPM, of course)
Derek Ritz (Sep 16 2020 at 20:02):
I think the ATC can play a useful role in identifying what something IS (it's chemistry) so that drug-to-drug interactions can be detected. What a medicine's GTIN is indicates manufacturer's product right down to the packaging level (different pack size of identical drug... different GTIN). Different manufacturer's make functionally equivalent products with different trade names... but made out of the same active ingredients. These would have the same ATC codes, as I understand it. For this reason, I think the ATC code adds a useful bit of value to the medicationStatement in the IPS.
Jose Costa Teixeira (Sep 16 2020 at 21:10):
All classifications do add value. I think ATC should not be mistaken with a product code for different GTINs. ATC is much coarser than that. Fortunately we (will (eventually)) have IDMP to bring additional codes.
Jay Lyle (Jan 20 2022 at 14:15):
Is there a more recent thread on this topic?
This thread addresses questions about 1) slicing an element with a cardinality of 1 (as I see it, creating a "choice" structure) and 2) how widely the granularity of codes can vary in a CodeableConcept. I'm interested in #2.
I don't think I see a clear consensus on that question. Conceptually, it seems that ATC and NDC could both be used, the NDC to identify the medication in the workflow and the ATC for reference or classification. I also think the concern about using such a broad code in, e.g., an order or dispense, is significant. Is it reasonable to think we can assert rules about using the most specific code, not the first code you can resolve, or about context of use (allow ATC on historical query results including orders, not on order placement)?
I have a case for a historical query where the classification would be useful, and where the instantiation of MedicationKnowledge seems heavy. @Rob Hausam @Melva Peters
Rob Hausam (Jan 21 2022 at 22:48):
@Jay Lyle I don't know if there is a more recent thread (i'm not recalling one). I think I would say a couple of things: (1) Use the code that most precisely represents the meaning that you want to convey (within the limits of the codes that you have available - based on whatever particular constraints may apply in your situation); (2) Include all of the appropriate codes that you know. In most medication cases, I think that both ATC and NDC would probably fit within #2. For ordering, as long as you send a specific code that, along with the other information model attributes, accurately specifies the item that you intend to order and that your ordering system can appropriately respond to, it would be acceptable (and maybe in some cases desirable) to also include a classification code (e.g, ATC). I don't think it needs to be exclusive in that regard. Also, carrying that a bit farther, it might even be possible to design an ordering system using "classification" codes, provided that the additional required specificity for the ordered item is being properly encoded via the other information model attributes (i.e. "post coordination" in the information model).
Last updated: Apr 12 2022 at 19:14 UTC
