Stream: implementers
Topic: MedAdmin category [0..1]?
John Silva (Apr 01 2019 at 21:29):
The MedRequest.category property was changed to cardinality of [0..asterick] between STU3 and R4 but the same wasn't done in MedAdmin.category. We have a need to send in multiple categories for MedAdmin.category, which is not allowed in STU3 or R4. I was thinking of using an Extension but not sure how to implement an extension that allows us to define this. Would I just 'override' (sort of speak ) the MedAdmin.category property with the [0..asterick] cardinality (not sure I can change cardinality to increase it) or do I need to use an Extension? If the later, how would I proceed.
Thanks in advance, John
Lloyd McKenzie (Apr 01 2019 at 21:30):
You'd define an extension that carries the additional category repetitions (and choose which one should live in the primary location and which should live in the extensions - the latter being more prone to being ignored).
John Silva (Apr 01 2019 at 21:32):
OK, so leave the original category property there but don't use it for our purposes? I'm still not sure how the extension would allow me to define the repeats I need? Do just create MedAdmin.myCategory [0..asterisk] [using this because Zulip asterisk is special char] and then just have the extension have value = CodeableConcept datatype?
Lloyd McKenzie (Apr 01 2019 at 21:57):
No, you should put one of your categories (the most important one) in the 0..1 attribute and send the extras in an extension.
Melva Peters (Apr 02 2019 at 01:24):
That has now been fixed in the Current Build. The MedicationAdministration.category has a cardinality of 0..*
John Silva (Apr 02 2019 at 09:45):
@Melva Peters -- thank you!! I was going to ask Lloyd if I should submit a GForge item for this; I was surprised to not see this as the case since I knew this had been done for MedRequest! I assume this was an oversight not done to specifically not allow multiple categories for the MedAdmin?
So, I think, rather than creating an extension, I'll just "pre-anticipate" that MedAdmin.category allows an array and use that for our needs. I had done that for MedReq.category expecting that change there. (So will this be an R4 change or will it wait until R5?)
Lloyd McKenzie (Apr 02 2019 at 15:20):
It will wait for R5. You can't pre-adopt cardinality changes into a prior version of FHIR and be conformant (or work with any of the reference implementations, test tools, etc. If you need to implement R4 or earlier, you'll have to use an extension for the extra repetitions.
John Silva (Apr 02 2019 at 17:24):
Argh! I wish I caught this in R4 ballot timeframe. At that time I was only concerned with MedRequest and would have assumed that the same change was made to both; yeh, bad to assume! ;-)
John Silva (Apr 03 2019 at 19:16):
A follow-up to this. Even if the MedAdmin.category allowed many, the CodeableConcept doesn't seem to have a good way to identify the type of each category in the repeats. (same problem in MedRequest.category which already allows repeats.) What I mean by this is that if I need to represent multiple categories for a single MedAdmin, e.g. AHFS (Therapeutic category) in 1 repeat, and Administration category (sort of like route and method but not exactly), inpatient/outpatient/home med, etc. it doesn't seem like CodeableConcept has a way to do this (well)? First, each of these category concepts are different 'things' so I can't just use repeats of coding. Second, I might have multiple categories that use, e.g. LOINC or SNOMED to identify the category (type) so I can't differentiate by the coding.system property either. It seems like I need a new dataType, similar to Identifier, for this purpose. Am I 'barking up the wrong tree' or is there a simpler way to do this? Should there be a new datatype for this type of use case? Thanks in advance
Lloyd McKenzie (Apr 03 2019 at 19:21):
If the category repeats, then you'd sende each category in a separate CodeableConcept repetition. Agree that using multiple codings within CodeableConcept to talk about different categories wouldn't be appropriate.
Grahame Grieve (Apr 03 2019 at 19:29):
I think the question is how to differentiate the codeableconcept functionally, since they are performing different functions. At this time, there's no way to do that.
Jean Duteau (Apr 03 2019 at 19:33):
Yes, to convey what you want, you'd need to have an extension. In MedKnowledge, we have a medicineClassification and we allow multiple classifications, so we have a BackboneElement that has a code for the type of classification and then the actual code of the classification. You'd be proposing something like that for category if that is what you needed.
John Silva (Apr 03 2019 at 19:35):
@Grahame Grieve @Lloyd McKenzie -- yes, that's my point! The CodeableConcept datatype doesn't give us a good way to do this. I've tried a 'hack' -- using the text property to (sort-of) identify the category type, but that isn't good for the 'long term' (or not even the short term). That's why I'm asking if it should (could) be a new datatype. I'm trying to come up with an extension for this purpose, right now focused specifically on my use case but I'd like to be able to 'dove tail' it into a more general use case.
John Silva (Apr 03 2019 at 19:35):
@Jean Duteau -- can you point me to that extension? Is it on Simplifier.net? Thanks!
Lloyd McKenzie (Apr 03 2019 at 19:36):
The category type needs to be inferred from the code system.
Grahame Grieve (Apr 03 2019 at 19:36):
that's not an extension -see http://build.fhir.org/medicationknowledge.html
Lloyd McKenzie (Apr 03 2019 at 19:36):
Or the hierarchy of the code system
Jean Duteau (Apr 03 2019 at 19:37):
No, I was saying that you'd have to make an extension on MedicationRequest.category to include a code that indicates the type of category. Then I pointed out that we had something like this on MedicationKnowledge, but it's part of the resource there because we knew we'd need to handle multiple types of classifications.
Jean Duteau (Apr 03 2019 at 19:37):
The category type needs to be inferred from the code system.
No, you can't infer from the code system because I could be using the same code system, eg. SNOMED, for each classification.
Jean Duteau (Apr 03 2019 at 19:39):
MedicationRequest.category.extension[url=.../categoryType].valueCodeableConcept
John Silva (Apr 03 2019 at 19:39):
@Jean Duteau Exactly, I can have multiple category 'types' that are defined by the same code system, e.g. SNOMED.
Grahame Grieve (Apr 03 2019 at 19:43):
Lloyd is saying that you should go look inside the code system to figure it out. And the terminology services can help you with that
Grahame Grieve (Apr 03 2019 at 19:44):
or more particularly, since you can do it that way, the element you are is in effect a denormalization for efficiency, which makes it more like that it's appropriate as an extension
John Silva (Apr 03 2019 at 19:45):
So which property in MedKnowledge are you referring to, relatedMedicationKnowledge ? For now I'll have to create an extension (on MedAdmin) but I was looking at the 'bigger picture', should there be a datatype for Category, that looks similar to Identifier, i.e. it has a code to identify the Category (type), and another code (or Coding or CodeableConcept) that identifies the specific instance within that category.
To be more specific, if one of my repeats of category is for AHFS code, I need something to identify that this repeat is for the AHFS category, then, in the CodeableConcept, I would have the specific instance for the specific medAdmin, e.g. A_123456 (which represents 'Analgesic')
(In my environment I don't have a terminology server anyway and shouldn't need one.)
Jean Duteau (Apr 03 2019 at 19:46):
Lloyd is saying that you should go look inside the code system to figure it out. And the terminology services can help you with that
Huh, how would knowing the code system or even the specific hierarchy of the code system infer the type of category? I don't think that is possible.
May Terry (Apr 03 2019 at 19:48):
@John Silva - I think the reference on MedKnowledge is First Data Bank's drug knowledge base called "MedKnowledge" which contains support for multiple types of drug classification systems, including AHFS, ATC, and FDB's proprietary Enhanced Therapeutic Class (ETC).
Lloyd McKenzie (Apr 03 2019 at 19:48):
Typically if a code system is supporting multiple categories, they'll be organized such that all codes from a single category will be organized under the same abstract code or share a common property or something. If the code just has an arbitrary set of codes and no organization, then the idea of a 'type' for the category is something that's being externally imposed
John Silva (Apr 03 2019 at 19:52):
@Lloyd McKenzie -- the categories are orthogonal -- so there's no common hierarchy. There's nothing in common between ValueSet/medication-admin-category and AHFS -- they come from two different worlds but yet they are both ways that I might like to categorize my drugs. Think of an inpatient setting where some drugs in the EMR were hand-entered from home drugs and some are from inpatient admins and the CPOE or EMR wants to provide the clinician a view of these drugs based on these categories, e.g. organized by home vs inpatient or by therapeutic category -- Analgesic or Thrombotic or whatever.
Grahame Grieve (Apr 03 2019 at 19:54):
they're different code systems. you understand the code system, or you don't. The code system you raised where the code system doesn't differentiate is SNOMED, and I'm sure it's differentiated by heirarchy there
John Silva (Apr 03 2019 at 19:55):
OK, thanks. I suppose each of these though are doing the same thing -- providing a therapeutic category.
Jean Duteau (Apr 03 2019 at 19:57):
they're different code systems. you understand the code system, or you don't. The code system you raised where the code system doesn't differentiate is SNOMED, and I'm sure it's differentiated by heirarchy there
Okay, so I'm using SNOMED for my two different categorizations. Nothing in the CodeableConcept itself tells me which categorization I'm receiving since the system is SNOMED in both cases. I now have to take the code, find the hierarchy it belongs to, and determine the intended categorization type from that hierarchy? And god forbid that I have two different categorizations that use the same hierarchy but different value sets from that hierarchy.
Seems like having a type code on category would be so much simpler and provide way better context.
John Silva (Apr 03 2019 at 19:58):
@Grahame Grieve -- OK, but if I have two different categories that both use SNOMED, how do I know which code value comes from which category? If I were using ...
Thanks @Jean Duteau -- I was just writing the same thing! I think we need some concrete examples and then test to see if the current CodeableConcept can support what we need (without Terminology service)
Yes, can we define a Category DataType that essentially looks like the Identifier type where it has a type (and system) property to do what we're asking for?
(Or should I just use an extension that uses the Identifier datatype and wait until this makes it into the Med-related resources? but ... there are other things that need to be categorized besides meds ...)
Grahame Grieve (Apr 03 2019 at 19:59):
And god forbid that I have two different categorizations that use the same hierarchy but different value sets from that hierarchy.
good luck showing how that works. I don't think that's a reasonable use case
Grahame Grieve (Apr 03 2019 at 19:59):
but yes:
I now have to take the code, find the hierarchy it belongs to, and determine the intended categorization type from that hierarchy
Grahame Grieve (Apr 03 2019 at 20:00):
As far as defining a type: we can do that. but then you'd have to go off and discuss with each committee the need for adopting that instead of a plain codeable concept.
Grahame Grieve (Apr 03 2019 at 20:00):
which won't happen for Observation, btw
Grahame Grieve (Apr 03 2019 at 20:01):
or you could discuss just creating the structure on category that you want
Grahame Grieve (Apr 03 2019 at 20:01):
I'm not sure that it's compelling as a base thing yet
Jean Duteau (Apr 03 2019 at 20:01):
BTW, i'm not actually proposing adding a type to CodeableConcept. I totally agree that's overkill for most CCs. I'm proposing that, where a type of code is required, that it be added to the specific resource.
John Silva (Apr 03 2019 at 20:01):
Yes, there can be multiple categorizations for Observations for sure.
Grahame Grieve (Apr 03 2019 at 20:02):
I can't imagine operational systems doing the work to differentiate medication category like this on the administration record. I think it's something that belongs on the medication, or maybe the prescription
John Silva (Apr 03 2019 at 20:03):
@Grahame Grieve -- we have real systems that do this and I'm pretty sure there are CPOE and MAR and EHR systems that have these kinds of use cases. (They probably don't use FHIR yet though.)
Jean Duteau (Apr 03 2019 at 20:03):
ha ha, I tried to find some drug categories in snomed. what a terminology - I can't even figure out what to search for to find a set of terms to use as an example. :)
John Silva (Apr 03 2019 at 20:04):
@Jean Duteau -- yeh, drugs are problematic because they tend to be country-specific and licensed to the big drug DB companies (FDB, etc.) The AHFS example is a US-only one I believe.
Grahame Grieve (Apr 03 2019 at 20:43):
@Melva Peters this is really an issue for pharmacy at this point.
@John Silva you should create a gForge issue to get it on the Phx agenda
John Silva (Apr 03 2019 at 21:15):
@Jean Duteau -- On the SNOMED web query tool search for Analgesic agent:
If you then look at the children you can see a bunch of therapeutic categories like Antibiotic, Digestent, etc.
Rob Hausam (Apr 03 2019 at 21:36):
I think we need to carefully work through a reasonable set of examples of what needs to be supported for this. My suspicion is that we can do what is needed with the existing CodeableConcept and category 0..* machinery, without having to create a new Category data type, but we need the analysis to see what, if anything, actually doesn't fit. I agree that terminology services can be very helpful here, especially with SNOMED CT - but I also acknowledge that people may think they don't need or want to use them. As I said, the details need to be explored to see what works and what doesn't.
John Silva (Apr 03 2019 at 21:53):
My specific use case is related to Pharmacy/MedAdmin but the more general case is wherever some resource needs to be classified by multiple category "types". I'm not sure how or if I should try to move this forward with a GForge tracker or not; I wanted to get a sense here if there's even a possibility. I don't want to spend committee time or mine if this doesn't make sense.
Grahame Grieve (Apr 03 2019 at 22:08):
it's a possibility and I think it's worth the pharmacy committee considering. The more extensive the change you propose higher a mountain you are going to climb
Lloyd McKenzie (Apr 03 2019 at 22:29):
My leaning is that if it's absolutely necessary to break a specific category type out and treat it differently and you can't figure it out from the code system or the code system hierarcy, is to capture it as a separate element - or more likely, an extension.
Melva Peters (Apr 04 2019 at 01:22):
@John Silva Pharmacy is happy to discuss if you add a tracker and join a call to discuss.
John Silva (Apr 04 2019 at 13:42):
@Melva Peters -- OK added GForge # 20673 (MedAdmin category CodeableConcept doesn't provide a way to distinguish). I'll try to attend the Monday Pham call but I'm not sure if i can.
Jean Duteau (Apr 04 2019 at 15:39):
@John Silva can you go back to the tracker item and add some justification for it, i.e. the specific pharmacy use case you have for a) needing multiple categories of administration and b) needing to distinguish type of category.
John Silva (Apr 04 2019 at 15:52):
@Jean Duteau -- OK, just updated the GForge tracker with the sample use case. I also have the link to this FHIR chat thread for reference since there are others (like yourself) who have expanded on the need to be able to differentiate CodeableConcepts when there are multiple, orthogonal concepts that may (or may not) share the same coding system within the Coding element of the CodeableConcept. (I didn't have an example for other FHIR resources besides MedAdmin but there surely exist other examples.)
Robert McClure (Apr 06 2019 at 00:55):
@Melva Peters and @John Silva I'd like to be in on the call where this is discussed. Can you indicate which meeting you think this will come up?
Jean Duteau (Apr 06 2019 at 15:55):
We've had some push back on the need for a category on the administration in the first place.
@Jenni Syed @Danielle Friend Does either Cerner or Epic record a category on the administration? And if so, do you allow for multiple categories?
John Silva (Apr 06 2019 at 16:03):
@Jean Duteau - On the 'push-back' -- is this because it doesn't fit the 80% rule? I've worked on clinical systems that use categories (therapeutic and pharmacological ) to organize the MedAdmin's given to patient, both before (pending/scheduled admins) and after the admin. I do not have first-hand experience with an MAR or CPOE system but I would highly suspect that they would need this kind of mechanism to organize medAdmins on their UIs. (yes, FHIR/HL7 is not about prescribing application behavior but the mechanisms need to be there to support these app behaviors.)
John Silva (Apr 06 2019 at 16:03):
@Robert McClure -- @Melva Peters just posted the Pharmacy agenda for Monday and it looks like this category GForce item will be on there: https://confluence.hl7.org/pages/viewpage.action?pageId=48236974
Jose Costa Teixeira (Apr 07 2019 at 07:45):
yes, FHIR/HL7 is not about prescribing application behavior but the mechanisms need to be there to support these app behaviors.
Indeed
Scott Robertson (Apr 07 2019 at 17:50):
@John Silva I have also seen different systems organize meds in various manners. This is usually in regards to the viewer of the information: Nursing MARs are usually by administration characteristics (oral, injection, prn, schedule); physicians usually by therapeutic category but also by schedule/dose last given; pharmacy by dose type (solid oral/liquid oral, injection, IV, etc), sometimes controlled/noncontrolled, sometimes by schedule (what does the patient need in the next "delivery"). My point is that there are many possibilities.
On your request, and I haven't read the tracker yet, my questions are (1) does your use case meet the 80% "rule" - is it used widely enough, and (2) what is/are the appropriate code system(s). As I described above, there are a number of different sorting/groups concepts. Some are related to characteristics of the medication (e.g., dose form, controlled status usually don't change) and some are related to the order (e.g., schedule).
I'm not saying yea or nay on your request, I just need to understand it better.
Robert McClure (Apr 07 2019 at 18:33):
My response to John here is germane to this topic.
Jose Costa Teixeira (Apr 08 2019 at 06:25):
Interesting point was raised - Do we need a Type of Administration (besides a Type of Drug)?
John Silva (Apr 08 2019 at 10:08):
@Scott Robertson - Yes, there are different 'user views' based on the type of user, nurse, pharmacist, physician, etc. and some of the drug attributes for the MedAdmin for viewing have to do with scheduling information, route, infusion vs 'medication', etc. Also, some systems (and their user interfaces) allow the user(s) to dynamically switch among these different views. However, to support any of these views the information needs to be part of the MedAdmin (or some resource) in order to be available for the user interface code to be able to give these options to the clinician.
As I mentioned in my response to @Robert McClure , I'm a 'technologist' but the clinical team I work with has this use case so it's 'real' and needed for what they are trying to do clinically. I imagine they are not the only clinician's that have this or similar use case. Whether or not it fits the 80% rule is hard for me to guess at since I'm coming at it from a single use case perspective. However, even within my experience I've seen at least four developed (i.e. real -- in clinical use) products that use multiple categorizations to organize the drug displays for clinicians (and dynamically lets them switch views). Is that enough to reach the 80% threshold, I doubt it, but as an individual FHIR contributor, that's all I can present.
Last updated: Apr 12 2022 at 19:14 UTC
