FHIR Chat · concept type extension · australia

Stream: australia

Topic: concept type extension

Steve Swinsburg (Mar 03 2017 at 02:18):

Hi all, we have a need for the concept type (eg MPP, MPUU, TPUU etc) to be presented in the Medication resource. Currently we do not have a valueset defined for these types and we do not have a terminology server. But our downstream system needs to be able to consume the FHIR Medication and get at the type. We already have a number of extensions on the Medication model and I was going to add another called medication-type (with an appropriate URL) - sound reasonable? @Brett Esler , Graham suggested I talk to you about it. Note this isn't Australia specific though, other terminologies need this data.

Grahame Grieve (Mar 03 2017 at 02:20):

but could you define it in a cross- terminology way? I'm sceptical

Steve Swinsburg (Mar 03 2017 at 02:23):

AMT has MP, MPUU, MPP, TPUU, TPP, CTPP.
DM+D has VTM = MP, VMP=MPUU, VMPP = MPP, AMP = TPUU, AMPP=TPP, TF=TP
RxNorm has SCD = MPUU, SBD = TPUU etc.

Steve Swinsburg (Mar 03 2017 at 02:23):

Vidal in France has similar types

Steve Swinsburg (Mar 03 2017 at 02:24):

NZULM has the same as AMT

Steve Swinsburg (Mar 03 2017 at 02:24):

We model all five of these and are expressing them back out as Medication resources

Steve Swinsburg (Mar 03 2017 at 02:24):

and our systems need to know what type of data they are getting so they can do the appropiate actions

Steve Swinsburg (Mar 03 2017 at 02:27):

So I am proposing http://fhir.hl7.org.nz/dstu2/StructureDefinition/medication-type

Steve Swinsburg (Mar 03 2017 at 02:28):

See http://fhir.hl7.org.nz/dstu2/StructureDefinition/medication-isControlledDrug for example of another extension.

Brett Esler (Mar 03 2017 at 03:10):

I guess this is a case of wanting more of the medications terminology model encapsulated in the Medication resource itself rather than relying on terminolgy services to determine the classification. @Andrew Patterson might have some comments. Could we incorporate some indication of reference set as one of the codings i.e. part of AMT + in the MP/MPUU, etc.. ref sets - does that make sense?

Michael Lawley (Mar 03 2017 at 04:04):

Why not just define a ValueSet using the AMT codes (and a ConceptMap to document the VTM = MP, etc relationships)?

Andrew Patterson (Mar 03 2017 at 04:05):

I think a precise definition across terminologies might be hard to pin down.. I find the concepts within AMT even a bit wooly. I mean 'unit of use' doesn't really actually correspond to the 'use' of the medicine - sometimes its a unitary measurement concepts (1ml of liquid), sometimes the physical artifact (capsule), sometimes the actuation of a nebuliser (a measure almost).

Andrew Patterson (Mar 03 2017 at 04:07):

And what we call the container/packaging is pretty arbitrary sometimes

Andrew Patterson (Mar 03 2017 at 04:14):

So given each 'class' (MPUU, MP) has a guaranteed known membership reference set that comes as part of the terminology - is it possible to specify in the Coding that not just is this an AMT code, but this is the AMT code that got picked from X reference set (sorry, using the SNOMED names, not sure of the FHIR equivs)

Grahame Grieve (Mar 03 2017 at 04:16):

there's an extension for that. But these are actually orthogonal issues - which references set it was picked from, and indication that it has a particular value for some property of the code

Andrew Patterson (Mar 03 2017 at 04:17):

Yeah agreed - trying to do terminology without a terminology service is hacky at the best of times

Dion McMurtrie (Mar 06 2017 at 05:20):

I have played with the notion of indicating generically what sort of thing a Medication is. Essentially AMT has 7 things which (mostly) map to Medication resources.

MP = unbranded product with no strengths or form
MPUU = unbranded product with strengths and form
MPP = unbranded package with no container
TP - no translation
TPUU = branded product with strengths and form
TPP = branded package with no container
CTPP = branded package with container

We could have some sort of indicator for the things on the right hand side which we could then map the various medicines dictionaries to. For example an indicator that means "unbranded product with no strengths or form" could have MP and VTM mapped to it.

I've also experimented with indicating "branded parent" and "unbranded parent" references for Medication resources to indicate the links between them that you get from medicines terminology. Again looking for non-terminology specific names.

Michael Lawley (Mar 06 2017 at 07:12):

Agreed @Andrew Patterson , the category definitions are the things that need to be clearly defined.
@Dion McMurtrie Why not use the definitions as the codes (except for "no translation" :)

Dion McMurtrie (Mar 06 2017 at 07:20):

Yes I think that's what is needed @Michael Lawley, the main thing is agreeing that those (or something else) are the set of codes and the mappings from those to the terminologies. I think that those are basically it though, if you look at what Medication resources can express. I suppose you could add in there unbranded/branded product with form but no strength - that's something that AMT doesn't have precoordinated.

Dion McMurtrie (Mar 06 2017 at 07:26):

The important thing is that if we're trying to brand a Medication resource as one of these things we don't use something like "MP" which only works for AMT content, something more general would be nice...

Andrew Patterson (Mar 06 2017 at 07:56):

I definitely like the "branded", "non-branded" terms to refer to the split between left and right of the model. The line is clearly defined (I think) in all jurisdictions and across all drug terminologies. Plus, the actual wording of "branded" and "non-branded" is clear and unambiguous. I think there is already a boolean element for this in Medication (isBrand) - so problem solved going left or right.

Andrew Patterson (Mar 06 2017 at 08:00):

Going up and down the model I think the lines are so much blurrier.. one persons container is another persons package is another persons form.. I've been experimenting with some model changes where rather than fixed boxes we instead have 'counting' relations and 'measuring' relations.. so a vial 'measures' an amount of liquid, but a box 'counts' the number of pills. And so then everything that is the source of a counting relationship is a 'package'. (but you get rid of the actual MPP, MPUU distinction)

Andrew Patterson (Mar 06 2017 at 08:04):

But how you do those distinctions clearly in existing terminologies I don't know. I think a boolean isPackaging (ala isBrand) would be a perfectly valid way to distinguish the very bottom concepts (MPP, TPP, CTPP) across most drug models(?).

Andrew Patterson (Mar 06 2017 at 08:06):

So a combination of isBrand and isPackaging could at least let someone narrow the Medication reference to the approximate quadrant of most drug models..

Steve Swinsburg (Mar 15 2017 at 01:30):

@Andrew Patterson isBrand is fine, but only gets us into the two halves, ie the branded vs unbranded model. However, isPackaging seems redundant when there is already Medication.package which would only be populated for a pack type - however I worry about relying on this being populated to determine this type, ie Medication.package.container plus isBrand would to signal that this is a CTPP - but some terminologies might not have the container info.

Steve Swinsburg (Mar 15 2017 at 01:33):

We have already correlated six global terminologies to the AMT 7 box model (including substance) so I am wondering if we can just publish this mapping and use these types.

Steve Swinsburg (Mar 15 2017 at 01:33):

5 sorry, one was internal. AMT, DM+D, NZULM, RxNorm, Vidal.

Steve Swinsburg (Mar 15 2017 at 01:43):

I'll attach the same screenshot here.Screen-Shot-2017-03-15-at-12.39.56-PM.png

Dion McMurtrie (Mar 16 2017 at 11:47):

Yes that's why I favour using generic names for these things in FHIR, but providing the mapping from well known medicines terminologies to these categories.

@Andrew Patterson I think the issues with forms and packages and "units of use" is a long standing issue with AMT. Because different use cases have been tied to the different boxes the modelling has been fudged to have "an MPUU for this" rather than modelling what is actually there. I think that the modelling can be corrected to make concepts that do fit between the various forms and packages. The thing this breaks is the use cases attached to concepts from a given "box" in the AMT model, which is what I think needs to change.

Rather than attaching the use case to a "box" (or a reference set made up of concepts from that box), I think we need to create reference sets that are use case specific that cut across the "boxes" as needed to meet the use cases, and then stick to modelling reality when defining concepts in those boxes. This will stop the warring between the modelling and the what needs to be in a refset to meet a use case. @Matt Cordell has done quite a bit of work on this.

An example of this is ancestim 1.875 mg injection, 1.875 mg vial (medicinal product unit of use) when clearly a vial is a container.

I think this is similar to your idea of not worrying about boxes and modelling what is there, I think we can do that by modelling according to the boxes but carve up the reference sets across the boxes instead.

But rather than get tied up in specific AMT issues, and I'm sure the other medicines terminologies have their idiosyncrasies, my point is that each of these terminologies does clearly define layers of abstraction that are equivalent as @Steve Swinsburg points out.

I think creating unambiguous labels for those layers in FHIR that are agnostic of any of the terminologies in question is probably the way to go, and allow for mappings from those terminologies to the agnostic FHIR label. It doesn't matter if there is no mapping from a particular terminology to one or more of the labels in FHIR - it just means that terminology doesn't have that layer. This allows clients of that FHIR label trigger rules or logic off those labels and have that code work regardless of the underpinning terminology provided it expresses those layers using the agnostic labels.

Is there a problem with something like the following categories? Probably more intuitive than "MPUU" for the non-AMT/NZMT initiated.

• unbranded product with no strengths or form
• unbranded product with form but no strengths - AMT doesn't have this one, but I believe this is planned for the SNOMED CT drug content, not sure of the exact use case/s
• unbranded product with strengths and form
• unbranded package with no container
• branded product with strengths and form
• branded package with no container
• branded package with container

Steve Swinsburg (Mar 17 2017 at 02:19):

@Dion McMurtrie would you imagine that being turned into a set of codes made up of those sorts of value? Or should there be some sort of acronym with an associated description as above? Also could substance/ingredient be added?

Steve Swinsburg (Mar 17 2017 at 02:19):

Actually subtance should probably just be a Substance resource

Steve Swinsburg (Mar 17 2017 at 02:20):

so not included in the list of types for a Medication

Matt Cordell (Mar 17 2017 at 05:39):

So @Dion McMurtrie has dragged me into this, reminding me thatthere's this zulip channel :)

I like the 7 categories Dion's listed above. You could generate lists of concepts, based on the available attributes (Similar, but not quite the same as the "foundation" refsets in AMT). (You could even add another category "unbranded package with container")

As Dion says, I've got some ideas around what should happen with the UoU in AMT, as I think there's a lot of overloading the "boxes" to meet _some_ use case(s)... E.g. "MPUUs are for prescribing" (hypothetically).
So we end up concepts which could arguably represent the same thing... For example:

• 45383011000036109|paracetamol 500 mg / 50 mL injection, 50 mL vial (medicinal product unit of use)|
• 47033011000036101|paracetamol 500 mg / 50 mL injection, 1 x 50 mL vial (medicinal product pack)|

I'd prefer the MPUU be something simpler like |paracetamol 10 mg / mL injection|, and use the MPP for the prescribing requirement.
We could even say the PT is "paracetamol 500 mg / 50 mL injection" - which means exactly the same thing as far as I'm concerned - if that's what clinicians are used to..

So rather than say "boxes" are for a purpose. They simply define the meds to a certain level (category). Then define value sets these things for the various purposes (which might contain a mix of MPUU or MPP)

@Andrew Patterson 's comment 'counting' relations and 'measuring' relations - simialr to the distinction I have in mind for the types of products maybe... The "countable" (or discrete) things, have a unitary strength(?), e.g. mg/each (see tablets). The 'measureables" (or countinuants) have a concentration e.g. mg/mL, and the packs are defined as a specifiec mass or volume of the stuff... (as opposed to counts).

I'm still working up a full proposal for consideration, but feel free to send any comments through. (inc. email, if I don't respond here)

Grahame Grieve (Mar 23 2017 at 03:12):

catching up on this, the chatter i'm hearing suggests that every country is going to have the same basic need to categorise medication type, and it would be worth defining these base concepts across countries. If, that is, we can agree on which concepts apply....

Dion McMurtrie (Mar 24 2017 at 00:57):

Sorry, I've been on leave camping away from tech.

Yes Grahame I think that's what's needed - a list of the types of thing a Medication can be that is generic and expresses the things that medication terminologies express. Each medication terminology can map to that and may cover all or only some of the types.

@Steve Swinsburg I think we can start with that list and encompass all the in use variations (there's not that many of them).

As a start how about

{
  "resourceType": "CodeSystem",
  "name": "Medication Type",
  "url": "http://hl7.org/fhir/medication_type",
  "status": "draft",
  "description": "Code system of the different types of medication concepts and the scope that they encompass",
  "compositional": false,
  "content": "complete",
  "concept": [
    {
      "display": "Unbranded product with no strengths or form",
      "code": "UPNSNF",
      "definition": "Concept representing a collection of ingredients as an unbranded medication with no included strengths or form"
    },
    {
      "display": "Unbranded product with form but no strengths",
      "code": "UPFNS",
      "definition": "Concept representing a collection of ingredients as an unbranded medication with a specified form but no strength information for ingredients"
    },
    {
      "display": "Unbranded product with strengths and form",
      "code": "UPSF",
      "definition": "Concept representing a collection of ingredients as an unbranded medication with specified ingredient strengths and a form"
    },
    {
      "display": "Unbranded package with no container",
      "code": "UPNC",
      "definition": "Concept representing a package containing medication/s with no specified container or brand information"
    },
    {
      "display": "Unbranded package with container",
      "code": "UPC",
      "definition": "Concept representing a package containing medication/s with a specified container but no brand information"
    },
    {
      "display": "Branded product with no strengths or form",
      "code": "BPNSNF",
      "definition": "Concept representing a collection of ingredients as a brand specific medication with no included strengths or form"
    },
    {
      "display": "Branded product with form but no strengths",
      "code": "BPFNS",
      "definition": "Concept representing a collection of ingredients as a brand specific medication with a specified form but no strength information for ingredients"
    },
    {
      "display": "Branded product with strengths and form",
      "code": "BPSF",
      "definition": "Concept representing a collection of ingredients as a brand specific medication with specified ingredient strengths and a form"
    },
    {
      "display": "Branded package with no container",
      "code": "BPNC",
      "definition": "Concept representing a brand specific package containing medication/s with no specified container"
    },
    {
      "display": "Branded package with container",
      "code": "BPC",
      "definition": "Concept representing a brand specific package containing medication/s with a specified container"
    }
  ],
  "count": 11,
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>Medication Type</h2><tt>http://hl7.org/fhir/medication_type</tt><p>Code system of the different types of medication concepts and the scope that they encompass</p></div>"
  },
  "versionNeeded": false
}

Richard Townley-O'Neill (Mar 24 2017 at 01:18):

Would anyone want to prescribe an unbranded product with strength but no form? e.g. take 500mg paracetamol as required.

Dion McMurtrie (Mar 24 2017 at 01:21):

No, but medications aren't just for prescribing. I was trying to come up with a list of the sorts of levels there are in terminologies (which have many use cases), but to be fair that specific level isn't something that AMT supports and I'm not sure if others do.

I'd be happy to take the approach of starting with a more limited set and growing it as needed. What I posted was just a straw man possible starting point.

Richard Townley-O'Neill (Mar 24 2017 at 01:28):

Good starting point.

Peter Jordan (Mar 24 2017 at 01:29):

Agreed. I'll attempt to get the NZMT/ NZULM involved in this.

Grahame Grieve (Mar 24 2017 at 01:35):

ok, I think it's time to create a task and propose this on the mai implementers channel

David Cai (Mar 24 2017 at 04:42):

Why are we not adding new elements (strength, form, package, etc.) to the Medication resource, so that each Medication instance can be matched to a category in a specific CodeSystem? Sorry if that's a stupid question.

Grahame Grieve (Mar 24 2017 at 04:54):

we might. but our usual style is to propose it as an extension.

Grahame Grieve (Mar 24 2017 at 04:55):

first. and see how much it is used

Grahame Grieve (Mar 24 2017 at 04:55):

but this one... it's a denormalization of the terminology... we typically find those controversial and they end up as extensions

David Cai (Mar 24 2017 at 04:59):

@Grahame Grieve thanks for the explanation.

Dion McMurtrie (Mar 24 2017 at 05:38):

What's life without a bit of controversy?

Grahame Grieve (Mar 24 2017 at 05:44):

that'd be like working for a government department

Steve Swinsburg (Mar 27 2017 at 06:22):

I'm just wondering if rather than come up with another set of acronyms and definitions that describe the same thing, that we perhaps start with using the existing well known ones. In the diagram I posted earlier, we've already mapped these out for a bunch of national terminologies. As we add support for more terminologies, we'll continue to do this.

Steve Swinsburg (Mar 27 2017 at 06:26):

Also, so I can move this forward, is medication-type ok as a name to represent this set of codes?

Steve Swinsburg (Mar 27 2017 at 06:26):

For the extension name that is.

Dion McMurtrie (Mar 30 2017 at 04:28):

I think medication-type is a good enough name.

In terms of the acronyms I disagree - the AMT acronyms while meaning something to the initiated don't mean much outside that circle. I also don't think FHIR should adopt and align to any of the medicines terminologies in particular, but be a generic point that each of the terminologies can map to. On top of that I think the list we come up with in FHIR should be the superset of levels of representation that the individual medicines terminologies have - it is a pretty finite list but that approach doesn't favour or disadvantage any of the terminologies.

Brett Esler (Dec 07 2017 at 11:48):

I would like to run with this idea and create a AU valueset and extension of Coding

• unbranded product with no strengths or form
• unbranded product with form but no strengths - AMT doesn't have this one, but I believe this is planned for the SNOMED CT drug content, not sure of the exact use case/s
• unbranded product with strengths and form
• unbranded package with no container
• branded product with strengths and form
• branded package with no container
• branded package with container

@Dion McMurtrie codes already thought up?

Brett Esler (Dec 11 2017 at 01:42):

also would like to add a

• branded product with no strengths or form

Brett Esler (Dec 11 2017 at 01:45):

@Dion McMurtrie using your example service and instances - maybe something like this?

• UPD unbranded product with no strengths or form
• UPDF (?? maybe) unbranded product with form but no strengths - AMT doesn't have this one, but I believe this is planned for the SNOMED CT drug content, not sure of the exact use case/s
• UPDSF unbranded product with strengths and form
• UPG unbranded package with no container
• BPDSF branded product with strengths and form
• BPG branded package with no container
• BPGC branded package with container
• BPD (?? maybe) branded product with no strengths or form
• BPDF (?? maybe) branded product with form but no strengths

Grahame Grieve (Dec 11 2017 at 03:51):

extension of Coding? or CodeSystem?

Brett Esler (Dec 11 2017 at 04:13):

Coding - so can label the coding e.g. for AMT TPP and MPP levels

Dion McMurtrie (Dec 11 2017 at 04:19):

Yes I've used those suggested above to label Medication resources which represent AMT concepts...but we discussed at the connectathon last week moving that to Coding. I was going to work up some examples changing from extension on Medication to Coding, but I've not done that yet. I'll do that one night this week, hopefully tonight.
The other change I was going to make is include the AMT code and the generic codes above for each of the levels - so you can refer to the level by the drug terminology specific code if you know it, or the generic code if your code works across multiple drug terminologies.

Dion McMurtrie (Dec 11 2017 at 04:20):

the ones I'm working with now are
UnbrandedProduct("UPD", "Unbranded product with no strengths or form"),
UnbrandedProductStrength("UPDS", "Unbranded product with strengths but no form"),
UnbrandedProductForm("UPDF", "Unbranded product with form but no strength"),
UnbrandedProductStrengthForm("UPDSF", "Unbranded product with strengths and form"),
UnbrandedPackage("UPG", "Unbranded package with no container"),
BrandedProduct("BPD", "Branded product without strengths or form"),
BrandedProductStrength("BPDS", "Branded product with strengths but no form"),
BrandedProductForm("BPDF", "Branded product with form but no strengths"),
BrandedProductStrengthForm("BPSF", "Branded product with strengths and form"),
BrandedPackage("BPG", "Branded package with no container"),
BrandedPackgeContainer("BPGC", "Branded package with container");

Dion McMurtrie (Dec 11 2017 at 04:21):

BTW there is now a browser at https://medserve.online - the direct link is https://browse.medserve.online

Brett Esler (Dec 11 2017 at 04:21):

cool

Brett Esler (Dec 11 2017 at 04:33):

I have a draft in AU base IG - have a preferred CodeSystem url for these?

Dion McMurtrie (Dec 11 2017 at 04:35):

No, I made a dodgy CodeSystem resource a while back now and in the meantime I've been using http://hl7.org/fhir/medication_type but I'm not wedded to any of that.

There's an example use at https://medserve.online/fhir/Medication/66681000036100

Dion McMurtrie (Dec 11 2017 at 04:36):

I'd love to formalise it though, and have a real CodeSystem resource and ValueSet to point at

Brett Esler (Dec 11 2017 at 04:43):

how about http://hl7.org.au/fhir/CodeSystem/medication-type and http://hl7.org.au/fhir/ValueSet/medication-type for now?

Dion McMurtrie (Dec 11 2017 at 04:56):

No problem. Do you want me to make the resources? Do we have somewhere to put them?

Brett Esler (Dec 11 2017 at 04:57):

i am just about done - I can publish in AU base IG.... a review would be good; just getting my build to work....

Last updated: Apr 12 2022 at 19:14 UTC