Stream: genomics
Topic: handling medication information such as drug class
Bret H (Oct 05 2021 at 19:19):
Suggestion with regards to JIRA FHIR-32715. "Specifically, within our Therapeutic profile add the ability to reference an instance of Medication Knowledge Resource. This need not be a required field." This is a single reference to an existing profile, or a component which contains the reference. This allows better clarification of the medication grouping, when used, and is in line with data currently sent in PGx reports. Our IG is universal. The scope of the addition to the IG would be small and the work minimal - adding a reference for medication knowledge resource as a means to communicate drug class. The divinci groups adoption of the resource is evidence of a spreading value/acceptance of the resource. Seems pretty straightforward.
https://jira.hl7.org/browse/FHIR-32715
MORE DETAILS
Drug classification is an important but additional piece of information about a medication. There are several sources of classification, which source is being used can be defined using a classic code data type. The information appears with medications.
For example, in reports from Coriell a drug classification is used to group medications together. But one would need to treat the data like any other coded value. Again I recommend working closely with the HL7 Pharmacy teams.
Revised proposal follows:
From
MedicationKnowledge - FHIR v4.0.1 (hl7.org)
medicineClassification 0..* BackboneElement Categorization of the medication within a formulary or classification system
type 1..1 CodeableConcept The type of category for the medication (for example, therapeutic classification, therapeutic sub-classification)
classification 0..* CodeableConcept Specific category assigned to the medication
The divinci group has included it in a formulary resource: http://hl7.org/fhir/us/davinci-drug-formulary/ mapped to medicationknowledge.medicineClassification
Medication Classification can be found on https://www.hl7.org/fhir/medicationknowledge.html. The proposal is that our IG use the medicationknwowledge resource to provide the medicineClassification field to be used for drug classifications. Specifically, within our Therapeutic profile add the ability to reference an instance of Medication Knowledge Resource. This need not be a required field. recommend working with Pharmacy on this.
Drug class on it's own is not sufficient to define a medication. But it is a very valuable data element for grouping. I'll grab a screen shot of it being used in production.
Bret H (Oct 05 2021 at 19:22):
What are the concerns?
Bret H (Oct 05 2021 at 19:24):
@Jamie Jones @Patrick Werner @Bob Freimuth any comment? I am curious what others think. The medicationknowledge resource seems well suited for communicating medicationknowledge, adding an optional element does not seem burdensome to implementers and does provide a means accepted by the divinci group of sharing the information for those implementors which need/would like to send it.
Kevin Power (Oct 05 2021 at 20:10):
Wanted to add @Bob Dolin as well who had some thoughts on this during the call today.
@Bret H - So, your original proposal was to add a reference to a MedicationKnowledge resource from our Therapeutic profile, but to be clear, are you now suggesting adding a new backbone element (medicineClassification) that has the type and classification attributes (which are the key attributes of MedicationKnowledge you wanted to use)?
edit: Actually, in re-reading, I think you still suggesting the reference to the MedicationKnowledge resource from our Therapeutic Profile, and pointing out the specific 'medicineClassification' backbone element that could be used in that resource. If this is correct, what would we do with our current 'medication-assessed' component? Would we need to duplicate its code in the MedicationKnowledge.code attribute? Or perhaps add a rule to use either the existing component OR this new reference?
Bret H (Oct 05 2021 at 23:56):
Yes, refer to MedicationKowledge.medicineClassification. Good question, I think "perhaps add a rule to use either the existing component OR this new reference" is an interesting option. But do you think the redundancy of the .code attribute be a big problem for folks?
Kevin Power (Oct 06 2021 at 04:33):
We probably don’t need the rule as a starting point but we would need some guidance / documentation at a bare minimum.
Kevin Power (Oct 06 2021 at 15:14):
What do others think about adding a reference to MedicationKnowledge from our Therapeutic profile? My thoughts:
- It would need to be an extension, keep it as optional of course.
- Probably not an invariant, but we would need to document how to use this resource versus the 'medication-assessed' component.
- It would be easy to add, but I still believe expecting implementors to figure out a new resource for this purpose is a bit heavy handed (but that doesn't mean it is the wrong approach for a complicated topic).
Tagging @Jamie Jones @Patrick Werner @Bob Freimuth @Bob Dolin to request input.
Bob Dolin (Oct 06 2021 at 15:26):
@Kevin Power @Bret H Apologies for not having been following this thread that closely, but Bret, I think I'm not understanding where we'd need any more than a single drug code. I see some potential issues where, for instance, a PGx interaction is applicable to just one ingredient within a class. Can you give a couple examples of where you'd want to also communicate MedKnowledge?
Kevin Power (Oct 06 2021 at 15:32):
@Bob Dolin - This isn't about multiple drug code's necessarily. @Bret H is proposing to provide an option for implementors to use the MedicationKnowledge resource to communicate drug classification details, via the medicineClassification backbone element. We would add the ability to link to the MedicationKnowledge from our Therapeutic Profile.
Patrick Werner (Oct 06 2021 at 15:58):
Hmm. MedicationKnowledge points to Medication. And the Implication points to the medication.
Patrick Werner (Oct 06 2021 at 16:03):
I don't think we need/should add an extension to jump over the medication resource.
Patrick Werner (Oct 06 2021 at 16:04):
if you just want to point to a drug class, you can bind your medication resource to a VS containing drug classes.
Jamie Jones (Oct 06 2021 at 16:09):
I'm pretty sure we currently only reference drugs as a codeableconcept. A medicationRefence extension that could refer to either Medication or MedKnowledge sounds good to me, with guidance to say don't populate both if it is conflicting or confounding
Kevin Power (Oct 06 2021 at 16:14):
Jamie Jones said:
I'm pretty sure we currently only reference drugs as a codeableconcept. A medicationRefence extension that could refer to either Medication or MedKnowledge sounds good to me, with guidance to say don't populate both if it is conflicting or confounding
+1 on the current reference we have.
re: new extension, would you suggest we still keep the 'medication-assessed' component as well? That will need to be some good guidance if we end up with 3 options :smile:
Bob Dolin (Oct 06 2021 at 16:40):
I guess I still don't know of any use case where we'd need more than a drug code, and I see some risk in sending classification details (since many interactions are only relevant to a particular ingredient within a class)
Kevin Power (Oct 06 2021 at 16:44):
Bob Dolin said:
I guess I still don't know of any use case where we'd need more than a drug code, and I see some risk in sending classification details (since many interactions are only relevant to a particular ingredient within a class)
I am not sure how this changes anything around multiple drug codes (@Bob Dolin am I missing something?), but I will let @Bret H speak to your concerns about the classification details.
Bob Dolin (Oct 06 2021 at 16:47):
@Kevin Power That's probably because I'm confused :-). In the current TherapeuticImplication profile, we have (0..*) medication-assessed component. I don't think I know of any use cases where that isn't sufficient.
Kevin Power (Oct 06 2021 at 16:56):
For the 0..* on medication-assessed, a quick review of the IG shows we give this guidance:
From the Therapeutic profile:
Note: if multiple medications are used in medication assessed, the usage implication should describe the combined effect.
From the PGx page:
The medication-assessed component can be repeated to represent combination therapies. Otherwise, the recommendation is to limit Observations to one drug each to maintain semantic relationships in downstream systems.
Kevin Power (Oct 06 2021 at 16:57):
So, if we do add the extension, we need to consider the cardinality and how to integrate that in with our guidance.
Bret H (Oct 06 2021 at 22:14):
FYI: example report. Here the classification is labeled as Therapeutic class. https://intermountainhealthcare.org/-/media/files/misc/rxmatch-sample-report-6-3-19.pdf?la=en
Patrick Werner (Oct 07 2021 at 08:34):
Jamie Jones said:
I'm pretty sure we currently only reference drugs as a codeableconcept. A medicationRefence extension that could refer to either Medication or MedKnowledge sounds good to me, with guidance to say don't populate both if it is conflicting or confounding
+1
Bret H (Oct 11 2021 at 18:00):
(deleted)
Kevin Power (Oct 11 2021 at 19:55):
@Bret H - Are you OK with Jamie's proposed resolution ?
We currently only reference drugs as a codeableconcept (medication-assessed component on Therapeutic Implication). A new medicationReference extension that could refer to either Medication or MedKnowledge would work, with guidance to say don't populate both (component and extension) if it is conflicting or confounding
Bret H (Oct 11 2021 at 20:03):
That will give some good options. Thanks!
Bret H (Oct 11 2021 at 20:04):
it'll be up to the implementer to make sure they handle the med knowledge resource well, but a smart implementer will maintain a library of pre-made instances to use...look forward to the vote.
Bret H (Oct 11 2021 at 20:07):
what happens next with the JIRA ticket?
Kevin Power (Oct 11 2021 at 20:26):
I have proposed a resolution on the JIRA, and tentatively slotted it into a future block vote.
Arthur Hermann (Oct 14 2021 at 17:14):
Bret H said:
FYI: example report. Here the classification is labeled as Therapeutic class. https://intermountainhealthcare.org/-/media/files/misc/rxmatch-sample-report-6-3-19.pdf?la=en
@Bret H could you upload this document here? I can't reach it via the link and would be interested in seeing it and adding it to our collection of reports on our IG Google Drive. Thanks!
Robert McClure (Oct 14 2021 at 17:57):
Hi folks, just passing through. Just a reminder that in general (in US for sure) we are targeting the use of SNOMED CT as the drug product classification concepts because RxClass (from NLM) links the SCT drug class concepts (in the product hierarchy) to RxNorm ingredients. This allows users to have an open-access specific list of drugs that fall within a class. That is not to say other class definitions are off limits but the baseline is SCT. I also like that the RxMatch report fro IHC includes information about all the drug ingredients presumed to be in a class so no confusion can occur. But not sure what class grouping that is using to generate its data. Who is acting as the terminology SME for your work?
May Terry (Oct 14 2021 at 18:33):
very interesting and promising FYI @Robert McClure - can you give me an example of how this is represented or retrieved using the RxClass API? I don't easily see the SNOMED code for a given drug class in the return messages in say findClassByName(). And in finding the class by RxCUI, I still see only MEDRT by default in https://rxnav.nlm.nih.gov/REST/rxclass/class/byRxcui?rxcui=7052&relas=may_treat
May Terry (Oct 14 2021 at 19:10):
ah...k. So I got it working. I removed one of the search parameters which was unique to MEDRT. The SNOMED code of a class was displayed for a given RXCUI... https://rxnav.nlm.nih.gov/REST/rxclass/class/byRxcui?rxcui=7052
And I can also see the return if just passing a unique SCT code: https://rxnav.nlm.nih.gov/REST/rxclass/classTree.json?classId=350297008
Bret H (Oct 14 2021 at 19:22):
@Robert McClure regards medication terminologies, the pharmacy WG owns the space. The proposal here is to use the pharmacy resource when more medication knowledge is needed. See the initial post.
Bret H (Oct 14 2021 at 19:30):
Mechanism of action terminologies are fun too, NDF-RT....but that's not genomics...love to see molecular functional consequences tied to those terms in an ontology of some sort...but that's beyond most folks current reporting scope...love the comments on snomed and the api btw, Thanks!!!
Last updated: Apr 12 2022 at 19:14 UTC
