FHIR Chat · concept type? · implementers

Stream: implementers

Topic: concept type?

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

When referring to a concept as an MPUU/MPP etc, do you use 'concept type' or something else? I have been using concept type for years. I note the nehta guide mentions 'product class' however if dealing with something like an MPP, it's a Pack, and FHIR models Product and Package differently, so I don't want to confuse the two notions. WDYT?

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

This is about putting codes in the Medication resource?

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

We are looking for a suitable extension name in medication to signal, MP, MPUU, MPP, TPUU etc

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

@Dion McMurtrie what did you do nbout this?

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

if one exists already then i will definitley use that.

Peter Jordan (Mar 02 2017 at 04:54):

FWIW, I've implemented NZMT (which has the same '7 boxes' structure as AMT) as a Code System so it's possible to get that information, and other properties, by doing a lookup operation on the code itself.

Steve Swinsburg (Mar 02 2017 at 04:54):

@Peter Jordan can you post an example?

Peter Jordan (Mar 02 2017 at 05:02):

http://its.patientsfirst.org.nz/RestService.svc/Terminz/CodeSystem/$lookup?system=http://nzmt.org.nz&code=10348841000116107&property=substance
Still WIP and I need to refine property names and return values when I next visit the NZMT/NZULM Team.

Dion McMurtrie (Mar 02 2017 at 06:45):

So I'm not sure I entirely understand the question...what is the context for referring to the MPUU/MPP?

BTW...I'm not sure how relevant this is but...

I have done work creating a FHIR Medication resource rendering of AMT concepts. Some of these are Product (MP, MPUU, TPUU) and some are Package (MPP, TPP, CTPP) Medication resources. I'll post an example if anyone is interested, the idea was that we could expose AMT/PBS/TGA data all merged into a set of Medication resources which are searchable and easier to dig out the attributes (easier than RF2) of each concept such as ingredients and strengths. As part of doing this I was asked to create links between the resources so that if you had a CTPP Medication resource you could find its TPP medication resource for example.

Dion McMurtrie (Mar 02 2017 at 06:52):

Here's an example of Panadeine Caplet (CTPP)

Panadeine-Caplet-tablet-film-coated-12-blister-pack_61176011000036107

Dion McMurtrie (Mar 02 2017 at 06:55):

This is corresponding TPUU...ignore the leading extension part which is experimenting with providing those links within the AMT "7 boxes". The extension that is interesting is the BoSS, which I've created a tracker item about. This is all a bit of a thought experiment at present.

Panadeine-Caplet-tablet-film-coated_54205011000036101

Peter Jordan (Mar 02 2017 at 08:33):

That's a really interesting approach, which was mooted during last year's Snappathon at the SCT Expo in Wellington. At the persistence layer, there's not doubt that shoehorning AMT/NZMT into the RF2 format is problematic, so I'll continue to place NZMT in a relational schema. At the HIE layer, it's a question of whether it's easier to obtain the attributes and relationships from a Medication Resource or by querying the properties of a Code System. I suspect the former might be more efficient if you don't have to do anything too nasty to create those links.

Grahame Grieve (Mar 02 2017 at 09:17):

the serious terminologies - loinc, sct, rxnorm, amt etc - are all a combination of an information model, a dictionary, a grammar, and a set of terminologies

Grahame Grieve (Mar 02 2017 at 09:17):

they should expect to manifest in FHIR in multiple different ways

Jose Costa Teixeira (Mar 02 2017 at 09:20):

IDMP defines a model with Pharmaceutical Product, Medicinal Product, and Packaged Product.

Jose Costa Teixeira (Mar 02 2017 at 09:21):

We know that there are many notions, and we just finished a project to analyze how these global concepts can align with the existing codes.

Jose Costa Teixeira (Mar 02 2017 at 09:26):

for FHIR this comes down to 2 things IMO:
1. Align the Medication definitional resource with IDMP and supporting other product concepts
2. in the Catalog discussions, implement the relations between the several concepts. i.e. allow explaining that this package is related to this product

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

@Dion McMurtrie "what is the context for referring to the MPUU/MPP?" We have a Medication that contains the data and we need to include the 'concept type', ie MPP, MPUU etc, so that our systems know how to handle them and trying to settle on a name for the extension.

Grahame Grieve (Mar 02 2017 at 23:34):

I think that both Dion and Peter have argued that you don't need to include the concept type since it's inherent in the definition of the code

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

I don't follow. There is not enough data in Medication to differentiate the types.

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

Especially if some terminologies are missing data (they are). I mean, you could check for a combination of data (isBrand, product.form) etc to infer this, but if any of that data is missing then you can't tell between MP and MPUU for example.

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

Our systems behave differently based on the concept type so it would be far simpler to add this since we already have it, rather than rely on inference based on other fields that may or may not be populated.

Grahame Grieve (Mar 03 2017 at 00:05):

the AMT code itself tells you whether it's a MP MPUU etc. But I think that's not the answer you want?

Dion McMurtrie (Mar 03 2017 at 00:46):

So @Steve Swinsburg I guess you're saying that you have a Medication resource that has an AMT code, and the Medication resource may or may not be populated with the defining attributes of the AMT code like the examples I provided. So if you can't rely on the Medication resource's data to determine the type of the AMT code because it may not be populated sufficiently to tell. Did I get that right?

In that case I think you've only got two options. You can do as you are suggesting and expect a baked in tag (extension) in the resource that tells you which one of the 7 boxes it is. But doesn't that only work when you are receiving Medication resources that someone has put that tag in? What do you do if you get a Medication resource that doesn't have your extension?

The alternative is to ask a terminology server. You can determine if a concept is an MP by doing a validate code operation on the MP implicit value set. For example
http://ontoserver.csiro.au/stu3/ValueSet/%24validate-code?system=http://snomed.info/sct&code=21433011000036107&identifier=http%3A%2F%2Fsnomed.info%2Fsct%2F32506021000036107%3Ffhir_vs%3Drefset%2F929360061000036106

You could issue a batch that did a validate code on each of the 7 box implicit value sets and then inspect which one returned true.

That's what you'd have to do if you received an AMT coded Medication resource that didn't have any indicators/extensions on it which you'd probably have to account for? If you have to write that logic as a fall back for that case, then why not dispense with the indicator extension and simply use the terminology server all the time?

Dion McMurtrie (Mar 03 2017 at 00:58):

@Jose Costa Teixeira, what/where are the Catalog discussions? What is being proposed?

I think there are still issues with Medication package/product. I've tried to explain them in http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12396&start=0 but essentially the Medication resource has a bit of a split personality with respect to product/package.

Because a Medication can still have ingredients, strengths etc AND a package element which references a code or Medication there's room for inconsistency. What does it mean if I populate a Medication resource's ingredient and strengths and also populate the package element and reference a Medication with another set of ingredients?

I think the definition of Medication needs to be tightened so it can represent a thing with ingredients and strengths OR a package of things that in turn have ingredients. But as currently defined it is possible to create a Medication resource that attempts to be both at the same time.

Steve Swinsburg (Mar 03 2017 at 00:58):

So the use case here is showing a list of medications that match a number of types (ie give me all of the MPP, MPUU, TPP and TPUU). Suppose that returns 100. I wouldnt want to individually lookup each code to get the type - I already know it as it is in our Global Drug Model and came from the terminolgoy itself.

Steve Swinsburg (Mar 03 2017 at 00:58):

I am not too concerned with write operations at the moment

Steve Swinsburg (Mar 03 2017 at 01:00):

What I am really after is concesus on the naming of that extension. I might be able to skip it altogether but I'd prefer to add it in since we know the data.

Grahame Grieve (Mar 03 2017 at 01:51):

so, the way this is intended to work is

Grahame Grieve (Mar 03 2017 at 01:51):

1. you define the value set of AMT codes you are interested in.

Grahame Grieve (Mar 03 2017 at 01:51):

in your case, import from snomed-ct all codes that is-a with [MPP], [MPUU], [TPP], [TPUU]

Grahame Grieve (Mar 03 2017 at 01:51):

then, search for all medications in the value set

Grahame Grieve (Mar 03 2017 at 01:52):

GET [base]/Medication?code:in=[valueset-id]

Grahame Grieve (Mar 03 2017 at 01:52):

that assumes that your terminology server is hooked up to your search engine.

Grahame Grieve (Mar 03 2017 at 01:52):

if it's not, then denormalising with an extension is the way to go.

Grahame Grieve (Mar 03 2017 at 01:53):

we haven't defined an extension for this purpose. I guess you would take this request to the 'australia' channel and ask @Brett Esler & co for one

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

Yeah we don't have a terminology server yet. So I think denormalising with the extension is what we need for now

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

This is global though, not necessarily Australia. Other terminologies have similar concept types

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

But will get into the Au channel

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

however the overall concerns are different for each terminology

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

Well it is kind of the same. DM+D has VMP == MPUU. RxNorm has SCD == MPUU also. Other terminologoies have the same sorts of modelling which we map into our model.

Peter Jordan (Mar 03 2017 at 02:56):

Having a Terminology Server, I took the approach as per Grahame's intention and created a value set for each of the '7 boxes' in NZMT (plus a few others for prescribing terms - generic, trade and all); then facilitated lookups, with various properties, and code validation from NZMT as a whole. In practical terms, I do see some challenges in implementing medication lookup functionality without a Terminology Service - given the frequency of NZMT/AMT updates. Exchanging and persisting details of medications that have been prescribed/dispensed/administered is, of course, another matter.

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

We have an internal system that we import the monthly updates into (weekly for DM+D). It isn't a true terminology service, but it serves the drug data for our medication and problem list products. Now adding FHIR on top. So we have solved that problem for drug data, just need to get the data out in a sensible way in FHIR.

Peter Jordan (Mar 03 2017 at 03:03):

I'd love to have that problem - try using CDA! For several years, I've been the custodian of the NZePS Data Model and CDA specifications and long for the day when I can upgrade to the medication resource models in FHIR.

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

Just a comment on what @Grahame Grieve said with the value sets - if you rely on is-a relationships for the implicit value sets you'll get some (maybe) unexpected results. So "Panadeine tablet (TPUU)" is a subtype of MP, and if you use the "is-a MP" implicit value set you'll get that behaviour.

If you want to get a value set that is all of the MPs but not including MPUUs or TPUUs you need to use the implicit value set based on the AMT published reference set for MP. Each of the 7 boxes has such a reference set, and my earlier validate-code example used one of those.

Grahame Grieve (Mar 06 2017 at 05:14):

or you can use exclude in the value set definition.

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

true, but the definitions are a bit more complicated

MP = MP - MPUU - TPUU
MPUU = MPUU - TPUU
MPP = MPP - TPP - CTPP
TPP = TPP - CTPP
CTPP = CTPP

Or you can just use the reference sets published for each of these which already apply that logic and filter to active content. Probably also less work for the terminology server.

Grahame Grieve (Mar 06 2017 at 05:29):

it's certainly simpler.

David Teirney (Mar 07 2017 at 03:22):

What is the "well-known phrasing" used to describe the 7 boxes? AMT documentation used the phrase "Product Class." Is that accurate?

Andrew Patterson (Mar 07 2017 at 05:35):

I'd be worried "product class" could be misinterpreted to mean a class of pharmaceuticals like "antibiotics".. but sorry, don't have any better suggestions either!

Andrew Patterson (Mar 07 2017 at 05:36):

The dm+d documents refer to their boxes as "components"

Andrew Patterson (Mar 07 2017 at 05:36):

quoting "Each component (represented as a box in the diagram below) describes a product at different levels of granularity to support various use cases. "

Jose Costa Teixeira (Mar 07 2017 at 11:29):

Hi. Cathing up: the definitions above make sense, and of course they are not universal.
There was no standard termiology, until IDMP. IDMP provides a reference model: A very clear definition of Pharmaceutical Product, Medicinal Product, and Packaged Product, and which data elements belong to each.

Jose Costa Teixeira (Mar 07 2017 at 11:30):

Each country will of course implement their own concept.

Jose Costa Teixeira (Mar 07 2017 at 11:32):

@Dion McMurtrie : for Catalogs, the current idea is that we'd have an entry, that is has: a) characteristics, and b) relation to other entries.

Jose Costa Teixeira (Mar 07 2017 at 11:34):

All these "classes" are not something that we should fix. The only anchors I'd use is the IDMP concepts.

Jose Costa Teixeira (Mar 07 2017 at 11:35):

and I agree that we should look at the medication resource to see how it covers (and whether changes are needed) these aspects. For example the "isBrand" may not be sufficient with several implementations.

Jose Costa Teixeira (Mar 07 2017 at 11:37):

Bottom line: IMO, these things are not flat, and perhaps not hierarchical but polyhierarchical. I see it as a graph.
One substance is produced as two medicinal products, but one medicinal product may contain two substances.

Jose Costa Teixeira (Mar 07 2017 at 11:39):

I think that if we have to convey an MP and a PhP (Pharmaceutical Product), we would have two resources, even if they have the same type.
We can then update one or the other independently.

Jose Costa Teixeira (Mar 07 2017 at 11:42):

Catalog discussions are on wednesdays at 19:00 CET

Dion McMurtrie (Mar 07 2017 at 22:10):

Thanks @Jose Costa Teixeira I'll dial in to those meetings to get my head around it. Do you mean adding a Catalog element to the Medication resource with this information?

Dion McMurtrie (Mar 07 2017 at 22:11):

There's also a related discussion at https://chat.fhir.org/#narrow/stream/australia/subject/concept.20type.20extension

Dion McMurtrie (Mar 07 2017 at 22:14):

Specifically a comment I made which is sort of relevant. I'm not claiming this a perfect answer, but it illustrates the issue.

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.

Jose Costa Teixeira (Mar 07 2017 at 22:30):

@Dion McMurtrie The idea is more that any medication with its characteristics can be in a "catalog entry", with the Catalog being a composition of these catalog entries

Jose Costa Teixeira (Mar 07 2017 at 22:33):

like "here is a catalog which contains:
1)Paracetamol 500 mg tabs,
2) Paracetamol 500 mg caps,
3) medicationX, containing 1), brand A,...
4) medicationY, containing 1), brand B,..
5) medicationZ, containing 2, brand C,...

Jose Costa Teixeira (Mar 07 2017 at 22:35):

where "containing" is:
this entry has a relation "contains" (or "packaged as", or "groups" or whatever) with the other entry in this catalog.

Jose Costa Teixeira (Mar 07 2017 at 22:35):

each entry can indicate a related entry and the type of relation

Dion McMurtrie (Mar 07 2017 at 22:37):

Right, so do you mean that Catalog would be a new resource that references Medication resources? Sorry, I'm just trying to understand where this information would be held - i.e. existing resources, new resources or a bundle like composition thing.

Jose Costa Teixeira (Mar 07 2017 at 22:52):

Catalog would actually a Catalog entry, but yes, that is the idea

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

If I was to take a stab at summarising the initial problem that the Orion health guys have (@Steve Swinsburg/ @David Teirney correct me if wrong):

--
The are wrapping an existing system with a FHIR API that allows access to Medication resources - the existing system knows that each Medication is either a product or a package or generic or branded via whatever terminology source they have. However, the downstream consumers of these Medication resources don't have access to terminology services and therefore they'd like some attributes/extensions they can put into a Medication resource to help the downstream system out in determining if something was a branded package or a unbranded unit of use etc (ala isBrand but more comprehensive). Very specifically, they are happy to put an extension in but literally don't know what the call the extension or values in a way that is globally understood and is not specific to one terminology instance (perhaps IDMP helps here?).
--

@Jose Costa Teixeira I get that IDMP seems like some international effort to standardise naming/models etc (which sounds good) - but having some sort of Catalog grouping of Medication resources doesn't seem like it solves their issues - if their end system can't make terminology service calls, then presumably they also can't make calls to fetch Catalogs either. It just seems like inventing a terminology service but calling it something else.

Unless you mean as @Dion McMurtrie says, that the Medication resource itself holds a 'Catalog' back pointer - effectively that Medication "paracetamol 500 mg tab" would have attributes saying it belongs to the catalog "AMT MPUU", or catalog "non-branded"(??) or catalog "IDMP class named XXX".

Dion McMurtrie (Mar 08 2017 at 02:10):

Yes that's why I suggested the labels

• unbranded product with no strengths or form
• 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

That way you can tell what granularity of thing you have without being AMT specific. Each of these correlate to AMT and would to other meds terminologies, although there may be others like unbranded/branded product with form and no strengths which AMT doesn't have.

So what I was suggesting is for the Orion guys to rather than create something at is "concept type" and the values be AMT specific, create something more general which could be used for other terminologies too. That way the client code that doesn't have the terminology server but can react to these labels would work with dm+d as well as AMT for example.

Andrew Patterson (Mar 08 2017 at 02:45):

Yep, I mostly agree with your suggestions @Dion McMurtrie .. was just summarising for @Jose Costa Teixeira . It's possible that some of the words could better align with IDMP - branded, non-branded etc - I don't know what the preferred wording from an IDMP perspective is (I don't know anything about IDMP to be honest).

Andrew Patterson (Mar 08 2017 at 02:48):

Drilling into your suggestion though @Dion McMurtrie, I'm not 100% convinced by the "package with container" and "package with no container" distinction.. I think we'd find that that distinction is an artifact that is peculiar to AMT? But I like the "no strengths or form" distinctions and the branded v non-branded.

Jose Costa Teixeira (Mar 08 2017 at 08:15):

@Andrew Patterson If i understand well your point:
I think that any medication catalog entry would indeed have something that says whether it is a branded product or a Pharmaceutical Product or an MPUU...
I don't know if that needs to be a pointer (to an entry in a "list of concepts"?) or simply an identifier, or more simply, just a code set identifier..

Jose Costa Teixeira (Mar 08 2017 at 08:17):

@Dion McMurtrie These labels do make sense conceptually, but maybe they are insufficiently clear, or cannot apply to different regions. I am defending that other labels may make sense in different contexts. And we should adhere to IDMP firsthand.

Jose Costa Teixeira (Mar 08 2017 at 08:18):

e.g. What do we do with branded generics?
Or clusters?
Or national product coding systems where there is a code for "Paracetamol 500 mg tabs, 20 per box, regardless of the brands"

Jose Costa Teixeira (Mar 08 2017 at 08:24):

IDMP Concepts:
1. PhP - Pharmaceutical Product, which incorporates a Substance, Route of Administration, Administerable Dose Form, Strength, and medical device associated if any. There are other attributes, but if and only if any of these 5 attributes changes, then we are dealing with another product.
2. MP - Medicinal Product, which points to 1..* PhPs and has a manufacturer, brand name, Pharmaceutical Dose Form, Classification, indication..
3. PC - Packaged Product, which points to 1 MPID and has a package,..

Jose Costa Teixeira (Mar 08 2017 at 08:27):

Check page 9 of this for a list of the attributes
http://www.open-medicine.eu/fileadmin/openmed/deliverables/643796_d2.2_comprehensive_set_of_openmedicine_identifying_and_descriptive_attributes_of_medicinal_products_and_the_available_standards.pdf

Jose Costa Teixeira (Mar 08 2017 at 08:32):

My suggestion would be to
1. Define a strucure of attributes that reflects or at least supports IDMP levels
2. Use the medication resource to convey such attributes,
3. Use a label ConceptType to define, LOCALLY (i.e. no mandatory binding) what is the product concept type (i.e. does this instance define a PhP, or a MPUU, or ...)
4. Use global (IDMP) profiles or local (everything else) to define what attributes should be present for a given concept type

Jose Costa Teixeira (Mar 08 2017 at 09:17):

pinging pharmacy co-chairs @Melva Peters @John Hatem @Scott Robertson @Marla Albitz for a pointer to this discussion

Andrew Patterson (Mar 08 2017 at 10:54):

I was just trying to bring it back to the original source of the discussion - which was that they have a list of FHIR Medication resources but no access to a terminology service - and they want to discriminate the branded packages from the unbranded units (for instance). What I'm thinking you are saying is that you'd propose extensive additions to the FHIR Medication resource so that it has all attributes from the IDMP model (or realign existing FHIR properties to match the IDMP attributes)? Is that right?
And then people could work out whether it was a PhP or whatever because by definition if attribute X,Y and Z are present then that means it must be a PhP, but if attribute W, X are present it must be a MP etc?

Scott Robertson (Mar 08 2017 at 21:42):

Speaking for myself, not HL7 Pharmacy or the other co-chairs. Please, please, please do NOT replicate all, or even a significant portion, of IDMP and other descriptive information into the Medication resource. Granted something like "brand/generic" may be a reasonable addition (once you nail down the definition ... it is not binary), much more than that would break the 80% rule of FHIR - much of IDMP and other similar classification schemes, are not used in the vast majority of ordering, administration, and dispensing.

Scott Robertson (Mar 08 2017 at 21:48):

EHRs are not drug knowledgebases, but EHRs (and other HIT systems need access to such information. Terminology Services would be the better route for that detailed information (or possibly specialize resources?)

Scott Robertson (Mar 08 2017 at 21:51):

Bear in mind, i'm coming in late to this conversation and have not read the entire thread

Jose Costa Teixeira (Mar 09 2017 at 10:22):

@Scott Robertson : the point 2 above is not to convey the full IDMP description in the resource, but to convey "this is an MP", or "This is a PhP" and the already existing characteristics of the medication.

Jose Costa Teixeira (Mar 09 2017 at 10:23):

so indeed we should not force idmp down to the medicatoin resource which intends to be sufficient for clinical use.

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

Sorry for the silence, long weekend here. Yes, accurate summary. Here's a screenshot of our mappings. I am sure we could some up with a set of codes to represent these globally. Internally we use the AMT (+ING) acronyms - seems to make sense across the ones we handle. Ignore the ? symbols. X means not implemented in that terminology.Screen-Shot-2017-03-15-at-12.39.56-PM.png

Jose Costa Teixeira (Mar 18 2017 at 08:03):

Catching up: @Andrew Patterson Yes, that is a good summary, except that we'd not support all the attributes of the IDMP model, but only a small part. The IDMP model is used to describe the medication, whereas in clinical scenarios we typically need to specify it , i.e. give enough information so that everyone can understand what is meant. In an example, the IDMP model describes the substances, salts, all their regulatory relevant properties, and the product names, and the materials of packaging..... where we may live with an ID - substance, a PhP, an MP, a PackageID... or some of the attributes like strength, brand name, Marketing authorization number, package size...

Jose Costa Teixeira (Mar 18 2017 at 08:05):

And you are spot on what we called the Identifying attributes: If attributes Ph1, Ph2, Ph3, Ph4 are present(substance, strength, form), it is a PhP, but if the attributes M1, M2,.. (Brand name, Marketing Authorization holder,...) it is a MP, and if the attributes PC1, PC2 (Package size, ...) then it is a Packaged Product.

Jose Costa Teixeira (Mar 18 2017 at 08:10):

And here is the link from IDMP to the concepts shown in the table from @Steve Swinsburg and to the other national concepts - which we must support, but not crop or limit in any way:
In several countries, Sometimes the "product" is defined as a unique combination of attributes Ph1, Ph2, Ph3 + PC1. Example: there is a code that represents "Paracetamol 500 mg tablets, Box of 20". This is the only code allowed in prescriptions, or it is used for billing and reimbursement,...
So None of the IDMP identifiers are sufficient. But in that country, the "product" can still be represented by a unique identifier that still maps to IDMP identifiers.

Jose Costa Teixeira (Mar 18 2017 at 08:17):

Sorry for the details, but after an extensive analysis, I realized that there is no "single terminology" that will fit all purposes, and things like "is this a brand or generic" do not hold globally. There many moving parts, and one big gear turning all the others: Whatever concept type is used for national authorizations, reimbursement... etc. - that is the concept type that matters. And that varies widely.
So any standard must support different concepts - not sticking to a few, but actually having a flexible mechanism.
Reducing the machine to a couple of gears is going to clash with reality - which would mean that different implementers would have different implementations, which is what we are trying to avoid.

Steve Swinsburg (Mar 20 2017 at 06:28):

@Jose Costa Teixeira do you think it would be reasonable to create a set of concept types based on the set in the table above as a base set? bear in mind this is for an extension.

Jose Costa Teixeira (Mar 20 2017 at 20:49):

As for extensions, I'd not have any insight. My point is that with IDMP there are 4 standardized levels of "products" : Substance, Pharmaceutical Product, Medicinal Product, packaged Product. The identifiers will be assigned/monitored by regulators (EMA / FDA), and they have a very clear meaning, which is intended to be global.
Any local scope can defie thigs like "brand product" or "generic" but that does not hold well across borders.

Jose Costa Teixeira (Mar 20 2017 at 20:50):

so, yes, concept types - as extensions - should be ok, i guess. @Steve Swinsburg How would that look like?

Jose Costa Teixeira (Mar 20 2017 at 20:52):

Note that I'm only looking at concept types. I do not want to look at code sets, nor the hundreds of attributes that can be associated with each concept. As Scott said, that is not relevant. in clinical space, we only need a very small subset of attributes. In openMedicine, we had loooooong discussions on whether a prescription should fully describe a medication, or just point to whatever-code-is-commonly-understood. The latter won :)

Jose Costa Teixeira (Mar 20 2017 at 20:54):

my advice in any case would be to try to list the identifying attributes of each concept type -
e.g.
what distinguishes a TPP from a CTPP is a) the packaging quantity and b) packaging type
we had huge discussions to explain why. so you can try to read the documents if you want to see why we needed this for cross-border prescription.

Steve Swinsburg (Mar 21 2017 at 00:49):

@Jose Costa Teixeira re the extension. Current thinking is that we go with an extension name of medication-type with a set of Codes as MP, MPUU, MPP, TPUU, TPP, CTPP, as per the mapping above.

Steve Swinsburg (Mar 21 2017 at 00:50):

and TP

Jose Costa Teixeira (Mar 21 2017 at 13:12):

@Steve Swinsburg I was thinking that the valueset would suffice. You say "here's a code, and btw, it is a code of type MP". (I think in openMedicine we concluded it'd have be a rather unambiguous code, or have an OID, or a uri. "MP" in itself is not that unambiguous.)

Jose Costa Teixeira (Mar 21 2017 at 13:14):

there is an attribute called "isBrand" but perhaps that is too limited being a boolean.

Jose Costa Teixeira (Mar 21 2017 at 13:15):

If you need that extension, i don't see why not use it. Many countries will define their product concept type. And then we have groups and clusters...

Jose Costa Teixeira (Mar 21 2017 at 13:17):

the only thing I wonder is if those concepts would be global. I would start looking at the global concepts from IDMP.

Jose Costa Teixeira (Mar 21 2017 at 13:17):

every other seems national/regional.

Jose Costa Teixeira (Mar 21 2017 at 13:18):

if you join a catalog discussion, I can ask for a discussion around that. We're looking at things like relations between concepts. Complementing (not replacing) the base resource which is Medication

Jose Costa Teixeira (Mar 21 2017 at 13:19):

or we can discuss in Madrid. Sorry if my description is too spread out there, but I am trying to connect distant dots. and we did have long discussions to reach something that could work.

Jose Costa Teixeira (Mar 21 2017 at 13:25):

I can jump on a call at a decent time for you if you want and think that is helpful. I live in Europe but I spend lots of time in insomnia-land, so surely we can arrange for a slot.

Melva Peters (Mar 21 2017 at 20:16):

I would ask that discussions that are relevant to a medication are discussed on a Pharmacy WG call rather than in the catalog project call. IMHO the types being discussed here are attributes of the medication resource.

Jose Costa Teixeira (Mar 27 2017 at 19:13):

I will describe in today's Pharmacy call. This is related to Medication, Catalog and the IDMP alignment. Perhaps this is a good way to combine the discussion.

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

So sorry I missed all this discussion...I guess what I'm looking for is to provide a way of tagging the way @Steve Swinsburg is suggesting with a level of abstraction matching the underlying terminology for the identity of that medication. I'm not keen on aligning that to IDMP because the medication terminologies don't and they express much more levels than IDMP does.

If we can come up with a superset of the levels expressed by the major medication terminologies (there's not that many and the levels are a pretty finite list with strong overlap between the terminologies) then someone writing code against a medication resource doesn't need to care if it is AMT, RxNorm, NZMT or dm+d if they need to key some logic off that level. So if we declare some codes matching these levels and define the mappings between those codes and the major medication terminologies it gives developers a chance to write code that is agnostic of the particular medicines terminology they are using...a good thing.

That's why I think the codes themselves should not be specific to one of the terminologies in particular - I don't think using a code "MP" is a good idea, but call it something else.

BTW @Jose Costa Teixeira the difference between TPP and CTPP is only that CTPP specifies a container and TPP does not, both specify pack sizes.

@Andrew Patterson I don't think it is a big deal that some of these levels are only specific to one terminology. The coverage of these levels across the terminologies will vary, some will have some levels while others don't. It would be a problem if there were hundreds or even tens of these, but there isn't. I think creating the superset across all the medicines terminologies and mapping them is the way to go, then you will see where they line up and where they don't, and in future they may converge.

Jose Costa Teixeira (Mar 30 2017 at 07:01):

@Dion McMurtrie this being an extension, of course you'd have a superset. What I am saying is that there is no global superset that fits all cases. The minimum set should be IDMP because that is a global, precisely defined set.
And there are quite a few of terminologies and "levels" (they are not always hierarchical, so "level" may not be a good word).

Jose Costa Teixeira (Mar 30 2017 at 07:04):

but this seems to be the discussion that we should not be pushing in HL7 -what are the terms to use. That will always need to be defined locally, so why would we attempt to limit that diversity? Sorry but this seems deja vu from other projects, where we end up discussing for years what is the right set of terminologies and concepts, adn we arrive at the same conslusion: it varies, but thatnks to IDMP, it now varies in a structured way.

Jose Costa Teixeira (Mar 30 2017 at 07:05):

as for the solution (i think): Either make it an extension with "concept type" or even better, use the value set. That seems sufficient

Dion McMurtrie (Mar 30 2017 at 07:11):

I guess my point is that from a global developers perspective, if I can write some code that will work across multiple jurisdictions then that's a good thing.

If we have "levels" (I agree that's not a good word) that can be consistent and useful across multiple jurisdictions which enable that and aren't limited to IDMP, then why not have them?

Ultimately the extension will work...but it seems like there's an opportunity passing by...

Jose Costa Teixeira (Mar 30 2017 at 07:13):

The code will always work the same way. Putting the value set will enforce that if the concept is not understood on the other side, the system will at least know something is wrong

Dion McMurtrie (Mar 30 2017 at 07:15):

Sure, but only if the extension is known about and used, and there aren't other extensions and methods invented to do the same thing creating islands of interoperability...

Jose Costa Teixeira (Mar 30 2017 at 07:16):

thus: medication.code.coding.code=123, medication.code.coding.system=MPP
This is supported at core.

Jose Costa Teixeira (Mar 30 2017 at 07:17):

yes, you point to the right problem, so I pointed to a global solution for that: IDMP as a core set of concepts

Dion McMurtrie (Mar 30 2017 at 07:22):

medication.code.coding.system=MPP isn't right, the system will be the URI appropriate to AMT, RxNorm, dm+d...etc. So that doesn't help determine what "concept type" it is...that's essentially @Steve Swinsburg's problem
regarding IDMP, my understanding is it is driven from regulatory use cases, so that may shed some light on why it has far fewer "levels" that the medicines terminologies which have far broader use cases. In short, I suspect it will be insufficient

Jose Costa Teixeira (Mar 30 2017 at 07:40):

ok for the system vs concept. I'd expect that a terminology would handle different codes for different levels.

Jose Costa Teixeira (Mar 30 2017 at 07:41):

if i read you correctly, code.coding.system=IDMP and you'h have to know from the code whether it is one or another concept type.

Jose Costa Teixeira (Mar 30 2017 at 07:42):

i think my point is that every concept set is going to be insufficient.

Jose Costa Teixeira (Mar 30 2017 at 07:43):

and we've seen that when analyzing this for openMedicine. Conclusion: we cannot set on one or a few concepts in Europe. so, whatever we have has to be a subset, and people will extend

Jose Costa Teixeira (Mar 30 2017 at 07:44):

as for the extension. Medication has a "isBrand" - and that is where I would start addressing it. It is currently boolean, but perhaps that would be the example binding that we need.

Jose Costa Teixeira (Mar 30 2017 at 07:45):

as in "conceptType" and that can be either "IDMP MP, IDMP PhP, IDMP PC, Country1 Hospital code set, Country code cluster code set..."

Last updated: Apr 12 2022 at 19:14 UTC