Stream: implementers
Topic: Medication's "Therapeutic class"
John Silva (Jan 17 2018 at 10:30):
Is there a way to represent a medication's "therapeutic class", e.g. "Cardiovascular", "Analgesics", "Antibacterials", etc. If not, is this something that should be balloted for R4 or is this better handled by the Pharmacy working group?
For an examples see the US "USP Therapeutic Model Guidelines" and the AHFS "Pharmacologic Therapeutic Classification" here:
http://www.usp.org/health-quality-safety/usp-medicare-model-guidelines
http://www.ahfsdruginformation.com/ahfs-pharmacologic-therapeutic-classification/
Jose Costa Teixeira (Jan 17 2018 at 10:48):
This has / is being discussed. Currently we are looking at product definitions, and there are two approaches:
EntryDefinition is a definitional wrapper that can be used on Medications, and has a "classification" attribute.
There are some open discussions around a "healthProduct" definitional resource, and a "medicationKnowledge".
Also, BRR has a set of new resources where this could fit, but I can't find classification there. Only medicinalproductpharmaceutical.characteristics.
Jose Costa Teixeira (Jan 17 2018 at 10:49):
I assume that the "classification" can be also context-specific - i.e. one provider may have a classification, other provider a different classification. There are global or national classifications as you mention.
Jose Costa Teixeira (Jan 17 2018 at 10:50):
but directly answering your question, yes, there should be a solution, and entryDefinition.classification was made exactly to address this purpose. We may alter that, but that is afaik the attribute tat covers that.
John Silva (Jan 17 2018 at 11:15):
@Jose Costa Teixeira thanks for the response. Are "healthProduct" and "medicationKnowlege" proposed (new) properties on the Medication resource? (What is BRR?)
Jose Costa Teixeira (Jan 17 2018 at 11:28):
HealthProduct is a discussion ogoing, to make life easier for implementers, esp when having to choose whether a product is a device or a medicine - the standard should not be too prescriptive there.
medicationKnowledge i think is also an ongoing discussion. They are independent resources.
Jose Costa Teixeira (Jan 17 2018 at 11:29):
BRR is the working group that defines regulatory and research stuff, and since medications are regulated products, they hve implemetned a few concepts as proposals.
Jose Costa Teixeira (Jan 17 2018 at 11:31):
since we now have quite many "product" resources where the boundaries are not always clear in practice - and the certainty that there will always be more products, someone mentioned whether these could be reunited under a pattern or resource. HealthProduct would be that.
Jose Costa Teixeira (Jan 17 2018 at 11:32):
additional insight: entryDefinition may be merged onto healthProduct when healthProduct becomes real thing.
Melva Peters (Jan 17 2018 at 15:02):
@John Silva Pharmacy is considering a new medication related resource that we have tentatively called "MedicationKnowledge" where information such a therapeutic categories/classifications, and other types of knowledge could be included. If you have other requirements, it would be great if you could join the Pharmacy WG in New Orleans or on a teleconference with your requirements or create a tracker item.
Igor Sirkovich (Jan 17 2018 at 15:50):
In Ontario, we use STU3 for our Medications project. To convey therapeutic class and subclass (along with the Health Canada DIN - drug identification number), we use repetitions of Medication.code.coding.
Igor Sirkovich (Jan 17 2018 at 15:51):
To be more precise, we had sliced the Medication.code.coding into several slices, each with its own terminology binding.
Jose Costa Teixeira (Jan 17 2018 at 15:55):
@Igor Sirkovich that is a choice, although classification is technically not a code - same product can have many classifications, there are surely many products with the same classification. And there are limitations to that (we've discussed a few here, such as when you have Aspirin and give it the code for Aspirin and also the code for ASA - you are describing Aspirin, not ASA. Aspirin can have a medication.manufacturer, but ASA does not have a manufacturer)
This approach you have is sufficient for prescriptions but not for definition of the product.
Jose Costa Teixeira (Jan 17 2018 at 15:56):
in short: the slicing works in practice. your mileage may vary. For different purposes, requirements will differ.
Jose Costa Teixeira (Jan 17 2018 at 15:58):
BTW, the fact that we have different approaches to provide classifications. Implementers may dictate requirements but also rely on the norm as guidance (at least I did).
Igor Sirkovich (Jan 17 2018 at 16:05):
I agree. This is a workaround until there is a better permanent solution. But this was a pragrmatic approach recommended by the Pharmacy group that had allowed us to meet our business requirement and to go into production last year.
Lloyd McKenzie (Jan 17 2018 at 16:20):
Many products with the same classification doesn't mean it's not a code - it's just less granular. Multiple applicable classifications is more of an issue as all coding repetitions are expected to be encoding the same concept, not describing different aspects of it.
Lloyd McKenzie (Jan 17 2018 at 16:21):
One of the things MedicationKnowledge will need to figure out is what the boundaries are (and what the overlap is) around what appears on Medication vs. MedicationKnowledge.
Jose Costa Teixeira (Jan 17 2018 at 16:43):
@Lloyd McKenzie
all coding repetitions are expected to be encoding the same concept, not describing different aspects of it.
Yep, and that is where using classification codes as produt codes will have issues. And classifications may be context-bound, which is another challenge.
Jose Costa Teixeira (Jan 17 2018 at 16:46):
at least this discussion seems to confirm the issue / requirement. I'd leave the "which resources" for when we have a solution that works, or several.
Eric Haas (Jan 17 2018 at 17:17):
Why isn't a straightforward element like category 0..* CodeableConcept being considered? Then you can apply any classification system , like therapeutic class, you want.
Jose Costa Teixeira (Jan 17 2018 at 17:34):
The question was (i think) which element to use. Category or Classification could work, but the resource medication does not have it. and we ahve to make sure of the impact.
Jose Costa Teixeira (Jan 17 2018 at 17:35):
the discussion on codes and classifications is about that impact - in short, you should not use a code to say "this aspirin has also the code for ASA, so it contains ASA"
Eric Haas (Jan 17 2018 at 17:45):
The question was (i think) which element to use. Category or Classification could work, but the resource medication does not have it. and we ahve to make sure of the impact.
...Then create a category extension for your use case
Jose Costa Teixeira (Jan 17 2018 at 17:47):
correct, @Eric Haas - but this is input for changes that are planned in the resources, anyway, hence diving into it.
For implementations today, an extension would be best indeed.
Robert McClure (Jan 17 2018 at 22:57):
@Jose Costa Teixeira I'm really confused reading this by what you have in mind as "a classification." I'm going to assume you really mean "a category" to whit, you mean a grouper where multiple other drug concepts in this case are considered "in the group." Usually that means "is-a" but in this case it might also mean "is contained in" (such as Aspirin-containing medication.) Whatever the "grouper/class" is, would be a terminology concept from a code system (essentially like those you listed above) and they would be represented by a code from the code system. So you'd use FHIR datatype coding to capture it when you want to include it with a medication. Keep in mind that doing so is in essence an point in time view of a grouper (class) for that medication. Am I following what you are asking for?
John Silva (Jan 18 2018 at 02:14):
I'm glad this topic has generated some discussion. My intent (or need) is to have a mechanism to describe the taxonomy of drugs, as the USP and AHSF groups do. An Aspirin is a type of analgesic; I suppose it could also be considered a 'neural agent' (not knowing about the multi-axial nature of drug classifications). My basic question was about what to use in the Medication resource since I didn't see any (obvious) way to do this. Jose's mention of using EntryDefinition I suppose would be very useful because it could be used to represent the same drug in multiple classifications (places in the taxonomy). For simplicity's sake it would be simpler for my use case to have a category property on Medication. (I'm not sure I understand why the additional complications are needed but of course there are probably many other use cases out there beside the simpler example I have.)
Jose Costa Teixeira (Jan 18 2018 at 05:16):
@John Silva Yes, if you use medication resource to define the medicine, you could have a medication.classification (i.e. "i'm declaring that aspirin is an analgesic, an antiplatelet...")
Jose Costa Teixeira (Jan 18 2018 at 05:22):
if you use medication to specify what you are ordering/delivering, you can also use medication.classification, but it have different values (i.e. "i am prescribing aspirin, and I am stating it is an analgesic, so please substitute accordingly if you need to - meaning, don't substitute for an antiplatelet because i am only referring to the analgesic class").
I hope this differentiation between "defining a product" and "specifying a product" is useful - it is not obvious and it is a thought aid, but has helped me a lot since I learned it.
Jose Costa Teixeira (Jan 18 2018 at 05:25):
@Robert McClure for classification, i mean e.g. ATC. I know it is coded, so it works as you say. I am guessing your doubt stems from the discussions "why not use a coded element"- which is fine and agreed, but what was being discussed was where what that coded element.
medication.code does not make a good place for it.
Robert McClure (Jan 18 2018 at 18:29):
@Jose Costa Teixeira and @John Silva If you are discussing this to propose that FHIR resources be the way medication knowledge about drugs - not an instance of a patient taking a drug - is represented, then I'd participate in @Melva Peters "MedicationKnowledge" work (although one wonders why FHIR? in this situation.) If you want to do something like what Jose suggested, then the information should be derived from what the prescriber put into the ReasonCode in the MedicationStatement. Perhaps that could be influenced by classification information available from a drug information database, or from the "MedicationKnowledge" resource. But I'm concerned you want to support anyone to insert whatever class concept they want on a medication resource in some server. Not vetted, not good.
Jose Costa Teixeira (Jan 18 2018 at 18:36):
I'm concerned you want to support anyone to insert whatever class concept they want on a medication resource in some server. Not vetted, not good.
Why is this a concern? I don't see why the discussion above should derive that someone wants that.
Lloyd McKenzie (Jan 18 2018 at 18:40):
Vetting policy is outside of HL7. FHIR allows anyone to assert anything they want. It's up to server business rules to decide what changes can actually be made and by whom.
Scott Robertson (Jan 18 2018 at 18:40):
@Jose Costa Teixeira therapeutic classes should not be something that "any user" can add to a Medication. Therapeutic class(es) is a static characteristic of the medication.
Jose Costa Teixeira (Jan 18 2018 at 18:41):
@Scott Robertson sure, that is why we have it in the ProductDefinition.
Jose Costa Teixeira (Jan 18 2018 at 18:41):
but it COULD be put in a prescription.
Scott Robertson (Jan 18 2018 at 18:43):
I don't know what you mean by "it COULD be put in a prescription". Those assignments exist. Whether or not it is explicitly expressed in a prescription (as an aspect of the medication) is trivial ... it doesn't impact the prescription
Jose Costa Teixeira (Jan 18 2018 at 18:43):
Say aspirin has ATC class N02BA and B01AC. in a prescription you may want to put one of those.
Jose Costa Teixeira (Jan 18 2018 at 18:44):
if you put both, it is not clear why you are prescribing it for
Scott Robertson (Jan 18 2018 at 18:44):
that indication, not classification
Jose Costa Teixeira (Jan 18 2018 at 18:44):
that is classification.
Jose Costa Teixeira (Jan 18 2018 at 18:45):
well, indication is the condition supposed to be treated, right?
Jose Costa Teixeira (Jan 18 2018 at 18:45):
and in some cases, indication is not in the prescription.
Scott Robertson (Jan 18 2018 at 18:46):
indication is the specific condition being treated. just because aspirin is an analgesic, it is not prescribed to be analgesic, it is prescribed for some (specific) pain
Jose Costa Teixeira (Jan 18 2018 at 18:46):
agree
Scott Robertson (Jan 18 2018 at 18:47):
in the US, and I believe around the world, there is a big push to strongly advise, or even require, the inclusion of indication in all prescriptions
Jose Costa Teixeira (Jan 18 2018 at 18:47):
yes, but afaik, in some situations it is actually forbidden
Jose Costa Teixeira (Jan 18 2018 at 18:49):
so perhaps atc here is a confusing example , let's consider you want to send the drug schedule, or any other classification (not therapeutic), so that the receiving system does not need to have a (synced) drug database to understand how to handle.
Scott Robertson (Jan 18 2018 at 18:49):
yes, which is why I didn't say just "require". It's kind of nonsensical because in those cases the "prohibited" information is usually easily inferred
Jose Costa Teixeira (Jan 18 2018 at 18:50):
another example (sorry, i am trying to funnel lots of info) is narcotics. Something classified as narcotics in one side may not be classified as narcotic in the other. It may be good (or not) to send that classification over the wire, right?
Jose Costa Teixeira (Jan 18 2018 at 18:50):
all of this is actually why we have the work on Catalog.
Jose Costa Teixeira (Jan 18 2018 at 18:53):
so, going back to the (simple) question:
1. There is no way to handle classification in medication resource.
2. When you want to do that, i advise to clarify if you are defining the medication (as in a catalog or drug database) or conveying additional info in the prescription to support identification.
Scott Robertson (Jan 18 2018 at 18:55):
"narcotic" medically always means the same thing. "narcotic" as used in regulation can vary by jurisdiction. whether or not a product is specifically noted as a "narcotic" in the order, it is still a "narcotic" - there may be clinical considerations for that order AND there may be procedural/regulatory considerations for the order.
I agree that this particular "sub-thread" has diverged from the original question. There is work going on which should address this capability
Jose Costa Teixeira (Jan 18 2018 at 18:56):
and we have worked on entryDefinition which is a proposed(some may call it scaffolding) resource, which has classification and can be used around medication
Jose Costa Teixeira (Jan 18 2018 at 18:57):
"narcotic" medically always means the same thing. "narcotic" as used in regulation can vary by jurisdiction. whether or not a product is specifically noted as a "narcotic" in the order, it is still a "narcotic" - there may be clinical considerations for that order AND there may be procedural/regulatory considerations for the order.
I agree that this particular "sub-thread" has diverged from the original question. There is work going on which should address this capability
Agree, Scott. Just an example of classifications. We can consider "distribution Class", "price class"... all of which can have their interest. The idea is that a) you do not want to send the entire product definition over the wire and b) you may not be able to guarantee that the receiver shares the same data set as the prescriber, so you want to send some additional attributes on the drug.
Jose Costa Teixeira (Jan 18 2018 at 19:01):
BTW, I was asked for recommendation on a medicines database / "terminology" and to me the only solution that would work is the one on Catalog. But i look forward to see what is "medicationKnowledge" when it is available - and hope it is aligned with BRR resources and catalogs. Pharmacies do not define most of the drug knowledge, manufacturers and regulators do.
Melva Peters (Jan 18 2018 at 22:45):
@Robert McClure The use case we have is related to representing and sharing what I call "drug information" and is often maintained by drug knowledge base vendors such as First DataBank or Multum. Pharmacy has separated this out of a medication that you would prescribe or dispense as it can contain more information such as classifications, etc. Lots of discussion still to take place and meetings/quarters are scheduled in New Orleans
Dion McMurtrie (Jan 19 2018 at 03:38):
One of the issues I pick up on in this conversation (sorry I'm late to it) is that there are defining characteristics of a medication that are always true, then there are contextual characteristics. Classifications (depending upon what you mean when you are talking about them) get into this space, and this is where the "is-a" hierarchical relationships get difficult.
So a drug may contain an ingredient and that is defining of that drug, and always true, but depending upon the context/dose/etc it may be performing a different role - there are many drugs that can perform different roles. The fact that a drug can perform one of these roles means it has that "disposition", but because it has that disposition doesn't mean it will be used in that role. Then there's the regulation which licences the drugs to be used for certain purposes (in certain roles)
One thing that has been useful to distinguish in the SNOMED CT drug modelling discussions the difference between the following properties of a drug
- defining characteristics (like its ingredient or form)
- the disposition/s it has because of those defining characteristics (its potential uses)
- the role/s it is performing in a particular event
For example petrol is a substance we can define chemically, it has the disposition of being flammable or being a solvent, and when I'm driving my car I'm using its flammable disposition to use it in the role of being a fuel.
Understanding that these properties have different characteristics and temporality is useful to consider where those properties should be modelled.
Personally I like the idea of scoping Medication resources to be a pure statement of what the medication is (the defining characteristics) and separating out
- what the medication could potentially be used for or may interact with (like MedicationKnowledge for disposition)
- what the medication is licensed for in any particular realm at any given time (regulatory information)
- what the medication is being used for (or intended to be) in a specific encounter (role)
Jose Costa Teixeira (Jan 19 2018 at 09:08):
@Dion McMurtrie
perhaps the semantics discussions (the "is a" were not well framed).
Jose Costa Teixeira (Jan 19 2018 at 09:08):
agree with :
there are defining characteristics of a medication that are always true, then there are contextual characteristics. Classifications (depending upon what you mean when you are talking about them) get into this space
Jose Costa Teixeira (Jan 19 2018 at 09:09):
(that is a requirement we have been slowly trying to push - more than a "knowlegde" artifact, we need to capture the "definition" of a product. Hence we having our "entryDefinition". Which may be collapsed when we have "productDefinition".
Jose Costa Teixeira (Jan 19 2018 at 09:10):
and that definition is master data, although it is somewhat contextual.
Jose Costa Teixeira (Jan 19 2018 at 09:12):
the transactional data is different.
Medication was designed to be an operational data - to be put in prescriptions, etc.
What we in openMedicine called "specifying a product" (in opposition to "Defining a product").
Jean Duteau (Jan 19 2018 at 16:11):
We all have to keep the distinction between the Catalog resource and its Catalog entries versus the things that are referenced in that Catalog. If I am creating a Catalog of Medication resources, say to represent my jurisdictional formulary with costs and such, I would NOT necessarily use the Catalog classifications to represent the Drug classes. I would use the Catalog classifications for however I am grouping the medications in my formulary. I would ALWAYS use the MedicationKnowledge resource's means for identifying the various medication classes we have - such as ATC class, Allergen Groupings, etc.
Jose Costa Teixeira (Jan 19 2018 at 16:14):
@Jean Duteau that is an option indeed, but not what the catalog was conceived for. We can iterate now and the Catalog stuff is visible exactly to get this feedback. Is there any information on the medicationKnowledge? I am not even sure the scope is clear but from this message it seems that the resource is already done.
Jean Duteau (Jan 19 2018 at 16:40):
@Jose Costa Teixeira Here is the statement on the Catalog profile: "The Definitional resources contain static, immutable attributes. The Catalog provides the curated, approved and context-specific attributes and relations." That seems rather clear to me. The inherent relationships of a medication to its drug class, a branded product to its generic formulations, etc. are all "static immutable attributes" of the medication and so that seems to be out-of-scope for the Catalog and the Catalog entries.
Jean Duteau (Jan 19 2018 at 16:44):
BTW, the Pharmacy WG is proposing the MedicationKnowledge resource as the foundational resource for formularies, drug catalogs, and other knowledge bases. The scope of this resource will be enough attributes to convey the information that is needed for those use cases, as opposed to the existing Medication resource which is only enough attributes to convey what has been ordered/dispensed/administered/stated.
Jose Costa Teixeira (Jan 19 2018 at 16:46):
BTW, the Pharmacy WG is proposing the MedicationKnowledge resource as the foundational resource for formularies, drug catalogs, and other knowledge bases. The scope of this resource will be enough attributes to convey the information that is needed for those use cases, as opposed to the existing Medication resource which is only enough attributes to convey what has been ordered/dispensed/administered/stated.
Glad to hear that. In 2015 it was not accepted , so i look forward to see what is proposed and if that meets the requirements.
Lloyd McKenzie (Jan 19 2018 at 17:00):
I'm relatively certain that there won't end up being a "Catalogue" resource or any other resources that are catalogue-specific. Instead, we'll end up with patterns. The reason is that "catalogues" are just publication mechanisms for information that's defined and used elsewhere. There's no piece of information that only exists in the context of a catalogue. Price, insurance coverage, relationships between products, etc. all need to be shared and maintained in situations where no catalogue exists or will ever exist. And the introduction of a catalogue can't change where those data elements are defined. All a catalogue can do is take a particular subset of interrelated resources and publishe them together - i.e. as a document.
Jose Costa Teixeira (Jan 19 2018 at 17:02):
I'm relatively certain that there won't end up being a "Catalogue" resource or any other resources that are catalogue-specific. Instead, we'll end up with patterns. The reason is that "catalogues" are just publication mechanisms for information that's defined and used elsewhere. There's no piece of information that only exists in the context of a catalogue. Price, insurance coverage, relationships between products, etc. all need to be shared and maintained in situations where no catalogue exists or will ever exist. And the introduction of a catalogue can't change where those data elements are defined. All a catalogue can do is take a particular subset of interrelated resources and publishe them together - i.e. as a document.
Yep, I think we are moving in that direction
John Silva (Mar 30 2018 at 19:20):
Follow-up to this; is there a FHIR-recommended URI to use for AHFS as a coding system? (thinking of using http://ahfs.ashp.org/ unless there is a better one already in use or registered)
Last updated: Apr 12 2022 at 19:14 UTC
