Stream: implementers
Topic: URI for AHFS?
John Silva (Apr 03 2019 at 12:42):
I tried searching hl7.org/fhir and can't seem to find a URI for the codeSystem (or is it a valueSet) for the AHFS (therapeutic category) coding system. Does one exist? Is it documented anywhere on the HL7.org website?
David Pyke (Apr 03 2019 at 12:45):
There are a number of code systems not yet incorporated by FHIR. You may need to refer to it by OID (2.16.840.1.113883.6.234)
John Silva (Apr 03 2019 at 13:21):
@David Pyke -- Thanks! I had found this (http://hl7.ihelse.net/hl7v3/infrastructure/vocabulary/voc_ExternalSystems.html ) but I was hoping for a URI. OID's seem so opaque (I suppose on purpose) and not 'human readable'. Is their use preferred in FHIR or are URIs preferred?
David Pyke (Apr 03 2019 at 13:28):
URIs are preferred but it takes a while for a codelist to be added to FHIR, even if there is a V3 entry. Opening a CR is the first step and then getting a WG to sponsor it and do the work of getting it added. Until then, the OID will work for any system that has a license
Lloyd McKenzie (Apr 03 2019 at 15:04):
URIs don't take that long - generally only a week or two. And you should avoid using OIDs if humanly possible for two reasons:
- OIDs are hard for developers and testers to understand and you don't want them polluting your FHIR instances if you can possibly avoid it
- If HL7 later assigns a URI to a concept you're using an OID for, you're automatically non-conformant and will be expected to migrate to using the approved URI. So you save yourself work by just getting a URI in the first place.
Lloyd McKenzie (Apr 03 2019 at 15:06):
There's no need to get a WG to sponsor. Just click on the "propose a change" link at the bottom of any page in the spec and indicate what you want the URI for. All such requests are managed by the vocabulary work group. (Not sure what @David Pyke was referring to when he talked about a license... No license is required to use OIDs or URIs.)
John Silva (Apr 03 2019 at 15:41):
@Lloyd McKenzie -- OK, I'm 'game' -- which page do I use to request the URI for AHFS, the one I referred to earlier (on V3) -- or it doesn't matter which page; i.e. just enter a GForge item? I'll do this then.
BTW, I think your 1st bullet is not what you intended?
Jean Duteau (Apr 03 2019 at 15:44):
Lloyd McKenzie -- OK, I'm 'game' -- which page do I use to request the URI for AHFS, the one I referred to earlier (on V3) -- or it doesn't matter which page; i.e. just enter a GForge item? I'll do this then.
Any page because your request isn't page-specific. Or you can just go enter a GForge item directly.
Lloyd McKenzie (Apr 03 2019 at 15:47):
Corrected the first bullet. And yes, any page in the spec.
John Silva (Apr 03 2019 at 16:41):
OK, GForge 20655: "Assign a URI for AHFS coding system"
Grahame Grieve (Apr 03 2019 at 19:28):
where is this AHFX code system published?
John Silva (Apr 03 2019 at 19:33):
@Grahame Grieve - (AHFS) - It's an American Therapeutic drug categorization 'standard':
https://www.ahfsdruginformation.com/ahfs-pharmacologic-therapeutic-classification/
Grahame Grieve (Apr 03 2019 at 20:49):
@Ted Klein @Rob Hausam @Robert McClure @Scott Robertson do we have any contacts at AHFS to ask about permalinks?
Rob Hausam (Apr 03 2019 at 21:07):
I'm familiar with AHFS, but I personally haven't used it for a long time. As I recall the last time I used it it was in a rather thick book with a red cover. :) I don't know of any specific contacts at AHFS, but possibly someone does. We will plan to try to address this issue of getting the URIs assigned on the Vocab WG call tomorrow (3:30 Eastern). I haven't added it to the agenda yet, but I will (that will be our main FHIR topic tomorrow, I believe).
Grahame Grieve (Apr 03 2019 at 21:10):
https://www.ahfsdruginformation.com/ahfs-pharmacologic-therapeutic-classification looks like a permalink to me
Rob Hausam (Apr 03 2019 at 21:12):
Yeah, that looks good to me, too.
Grahame Grieve (Apr 03 2019 at 21:12):
so unless we hear from them, that's what we would fall back to. But it is good to ask if we can
Rob Hausam (Apr 03 2019 at 21:13):
I agree. One thing we can discuss tomorrow is how (and who) to make the ask.
John Silva (Apr 03 2019 at 21:16):
Thanks folks!
Scott Robertson (Apr 03 2019 at 21:34):
@Grahame Grieve I have a contact in AHSP (they publish AHFS). I'll check with him and see if he can provide a lead.
Rob Hausam (Apr 03 2019 at 21:36):
Thanks, @Scott Robertson.
Igor Sirkovich (Apr 05 2019 at 19:32):
Thank you for raising this topic. We are going to use AHFS codes in Ontario, Canada and were just about to request an URI.
Robert McClure (Apr 06 2019 at 00:39):
Well chap-my-hide, I've not heard of this one before. Which is an embarrassment. I've also reached out to them because I need to better understand what they have. @Grahame Grieve if you want me to follow up on a url, let me know. @Scott Robertson Who is your contact? Maybe send me an email?
John Silva (Apr 06 2019 at 11:15):
@Robert McClure - I learned about this from the clinicians I work with; there are requirements for needing to classify drugs by their therapeutic category (why I started the discussion about the needs for MedAdmin.category property representing multiple, orthogonal categories),
There is a (sort-of) equivalent defined in SNOMED-CT called: Medicinal product categorized by therapeutic role (product) SCTID: 763087004
Robert McClure (Apr 07 2019 at 18:29):
@John Silva Categorizing things is a complicated business and is driven by the use case. In addition for drugs, we need to decide if the focus will be substances which are easier to link and collect (think Active Ingredient), or products which can have MANY ingredients that restrict the therapeutic intent. I'm focused on substances but understand that means there are some very important outliers. IMO there are three major use cases for drug category concepts: 1) grouping drugs by therapeutic intent so that clinicians can be presented a list of options once they have decided to treat. 2) Grouping drugs based on cross-reactivity to be used for substance avoidance. 3) Grouping drugs based on a common characteristic because you need to do some common thing across the group. Such as engage a CDS tool or find common clinical impacts. The work I'm involved with for opioid management is a good example of this last one. There are some big nasty issues in using terminological ontologies to represent these types of categories (particularly those for allergies) but all of these REQUIRE that the class concept be linked to a set of drug ingredients which can lead to orderables and products, and sometime drug products directly. This is not runtime stuff.
If a clinician wants to use "a drug class" to say something about a particular drug they have ordered, then I wonder what they really want to accomplish. The mostly likely thing is they want to represent therapeutic intent for that particular drug for that particular patient. I wonder if that is in part what you are hearing. If so, then I'd strongly suggest capturing as therapeutic intent and using a condition with a likelihood or risk of or something to capture that the patient may not even have the thing yet (think vaccine or preventative care.) I look forward to the discussion tomorrow or whenever. I have a conflict for the call but will try to be there.
As for the SCT hierarchy you linked. It does not meet the criteria I see as needed: it does not link to actual products (and SCT will not do this because its hard, changes, and is realm-specific) and it looks likes lots of therapeutic intents to me which as I noted, can be useful for classifying but as such are fraught with maintenance issues. I'm more interested in using SCT for concepts like Substance with opioid receptor agonist mechanism of action (substance) but finding all of them simply is a challenge.
John Silva (Apr 08 2019 at 10:03):
@Robert McClure - Thanks for your input. Yes, #1 is the main reason for needing the categorization. You could argue that this should be associated with the Medication, but if that is from the 'formulary' then it might not work because a specific drug, in a specific use (admin) is being used at that point for a specific therapeutic reason. I'm a technologist, not a clinician, but I believe drugs have (or can have) multiple therapeutic uses, so I imagine these multiples being associated with the Medication. However, at the time of being ordered and administered, there is a specific therapeutic mode intended. (someone can give a clinically valid example)
The other thing that just doesn't 'feel right' is that if I, or the clinical application team I work with, finds a use case for MedAdmin categories, why can't FHIR support that? I understand the 80% rule here and the normal answer, 'use an extension', but I've got to believe that other clinical systems, especially those with user interfaces designed for clinicians, need to use, at a minimum, the therapeutic category, for helping to organize the presentation of the patient's drugs. I was quite surprised that MedAdmin category property was designated for inpatient/outpatient/home use, which to me doesn't seem to address (very well) the inpatient use in an acute care setting (and the fact that it allows only one repeat.)
Jean Duteau (Apr 08 2019 at 15:00):
Yes, #1 is the main reason for needing the categorization. You could argue that this should be associated with the Medication, but if that is from the 'formulary' then it might not work because a specific drug, in a specific use (admin) is being used at that point for a specific therapeutic reason. I'm a technologist, not a clinician, but I believe drugs have (or can have) multiple therapeutic uses, so I imagine these multiples being associated with the Medication. However, at the time of being ordered and administered, there is a specific therapeutic mode intended. (someone can give a clinically valid example).
What you just mentioned - why the drug was ordered for in this specific instance - is not done via categorization but via the reasonCode (or reasonReference). And the major push back is that we have seen different ways of categorizing the ordering of the medication, but not the administration. That is why we have asked for the implementer community to chime in here.
Jean Duteau (Apr 08 2019 at 15:03):
The other thing that just doesn't 'feel right' is that if I, or the clinical application team I work with, finds a use case for MedAdmin categories, why can't FHIR support that? I understand the 80% rule here and the normal answer, 'use an extension', but I've got to believe that other clinical systems, especially those with user interfaces designed for clinicians, need to use, at a minimum, the therapeutic category, for helping to organize the presentation of the patient's drugs. I was quite surprised that MedAdmin category property was designated for inpatient/outpatient/home use, which to me doesn't seem to address (very well) the inpatient use in an acute care setting (and the fact that it allows only one repeat.)
Why can't FHIR support that? Because the base FHIR specification is not intended to support every single use case from every single implementation. That was the downfall of v3, and to a lesser extent, one of the criticisms of v2. The extension mechanism in FHIR is a normal means of supporting specific use cases and is, in fact, how FHIR tends to support most use cases. As I mentioned in my earlier answer, that is why we need to have implementer feedback to see if anyone supports categorization of the administration in general and if they support multiple categorizations specifically.
John Silva (Apr 08 2019 at 16:59):
I just looked at reasonReference (of both MedAdmin and MedRequest) and the Example ValueSet doesn't seem to have anything to do with the categorization of the drug, just if it was for an Emergency or such. (I suppose since this is an Example ValueSet it is valid to define a different valueSet to be used, but this doesn't fit with our use case anyway.) I can imagine that the MedRequest.category array might be a more appropriate place to have this therapeutic categorization but in the existing FHIR model for MedAdm/MedRequest the category property seems to share the same conceptual use. i.e inpatient/outpatient/home.
BTW, at one point in my discussion here I asked about how to properly create an extension for this purpose since I guessed that this would be the way that would be recommended by the FHIR experts here. I'll still pursue that path but was raising the concern about why MedReq and MedAdmin has different cardinality on the same property (category) and if the CodeableConcept has a need for a value/system to define what the instances of it mean (not just for Med resources).
Jean Duteau (Apr 08 2019 at 17:07):
I just looked at reasonReference (of both MedAdmin and MedRequest) and the Example ValueSet doesn't seem to have anything to do with the categorization of the drug, just if it was for an Emergency or such. (I suppose since this is an Example ValueSet it is valid to define a different valueSet to be used, but this doesn't fit with our use case anyway.) I can imagine that the MedRequest.category array might be a more appropriate place to have this therapeutic categorization but in the existing FHIR model for MedAdm/MedRequest the category property seems to share the same conceptual use. i.e inpatient/outpatient/home.
reasonReference is a reference to a condition, observation, or diagnosticReport (in the case of an administration). The reasonCode for a request points to the SNOMED condition axis. The reasonCode for the administration is different because of this same issue I'm raising here - no one before has asked to categorize the actual administrations.
John Silva (Apr 08 2019 at 18:11):
I still don't see how 'reasonReference' has applicability for the use case I've asked about, especially since it references an Condition/Obs/DiagRpt.
At any rate, MedRequest does allow multiple categories so, if the committee decides that multiple categories isn't appropriate for MedAdmins, I suppose I could work around this by having this in the MedRequest (orders) and then the MedAdmin's would have a reference to the MedRequests which have the information I need.
Igor Sirkovich (Apr 08 2019 at 18:28):
The way we use AHFS in Canada is to categorize drugs and as such we only apply this on the Medication resource (as a repetition of medication.code), even though the main focus of my project is MedicationDispense. We are using Health Canada product database, where there is one or more (with the current data, one to three) AHFS categories assigned to each drug product.
Grahame Grieve (Apr 08 2019 at 21:46):
I am interested to know whether PHx has any specific reason for different cardinalities on MedAdmin and MedRequest. @Scott Robertson @Melva Peters
Jean Duteau (Apr 08 2019 at 23:40):
I am interested to know whether PHx has any specific reason for different cardinalities on MedAdmin and MedRequest. Scott Robertson Melva Peters
Different use cases. Even though the data elements are named the same, they are actually different purposes. We had a good discussion about this at our Pharmacy call today.
Grahame Grieve (Apr 09 2019 at 02:50):
ok. can you give a 1-2 paragraph summary for me?
Scott Robertson (Jul 09 2019 at 00:58):
Not sure anybody provided @Grahame Grieve with an answer through another channel. Here's my 1-2 paragraph differentiation:
MedRequest must account for "options" available for medication selection, administration, and delivery
MedAdmin records the specific details of the activity related to a MedRequest
I only found "category" having different cardinalities in MedRequest and MedAdmin
- MedRequest.category indicates the type of medication request (e.g., inpatient, outpatient, community, discharge). It is conceivable that the prescriber could indicate the order is for both inpatient and discharge, or that the medication (e.g., an single-dose antibiotic) can be administered in a clinic, at a pharmacy, or in another community setting. In both cases, multiple category entries allow for the option of multiple "types."
- MedAdmin.category, on the other hand, indicates where the medication was/will be administered or consumed. ("will be" is necessary if MedAdmin.status is not "completed".) There may be multiple "categories" in the MedRequest, but there can only be one in the MedAdmin. For the single-dose antibiotic example, the administration will occur in one place.
Grahame Grieve (Jul 10 2019 at 22:46):
so your description of category is multi-axial - which is usually the case for category. It's not clear why MedAdmin.category is not multi-axial too
John Silva (Jul 11 2019 at 16:46):
This reminds me; back in May I submitted a GForge request for a URI for AHFS; I just looked at it and it seems like it hasn't changed status since then. https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20655
Anyone know why or who might be involved in moving this forward? @Rob Hausam marked it as "Moving to 'H' group for HTA review."
Rob Hausam (Jul 11 2019 at 20:32):
Right. That was the plan. We need to see how HTA is planning to more forward with these. @Robert McClure?
John Silva (Jul 11 2019 at 22:15):
@Rob Hausam - thanks! (what is HTA - is that a board or subgroup in HL7?)
Rob Hausam (Jul 11 2019 at 22:22):
HL7 Terminology Authority. I think it's described as a board appointed committee (something like that)? Details here.
Robert McClure (Jul 16 2019 at 14:17):
@Rob Hausam we need to punch this up the agenda tree for HTA. Any chance you can find all the situations where we need to define a specific URI so we can review, make some general policy, and then complete the specific ones? And send that to the HTA listserve?
Rob Hausam (Jul 16 2019 at 15:29):
@Robert McClure Agree. I'll try to get that in the queue - can start with what we've categorized already in GForge.
Mona O (Aug 15 2019 at 22:31):
@Rob Hausam @Robert McClure
For AHFS has this URI https://www.ahfsdruginformation.com/ahfs-pharmacologic-therapeutic-classification/ been confirmed? I checked https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20655 and didn't see a reference to the URI so I wanted to confirm prior to utilizing it for AHFS. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
