FHIR Chat · IDMP product levels · BRR - Pharmacy model

Stream: BRR - Pharmacy model

Topic: IDMP product levels

Jose Costa Teixeira (Sep 15 2020 at 07:35):

Looking at the resource scopes, I understand that IDMP product levels are:
Pharmaceutical Products - AdministrableProductDef? (or MedicinalProductDef? )
Medicinal Products - MedicinalProductDef
Packaged Products - PackagedProductDefinition?(or MedicinalProductDef? )

Rik Smithies (Sep 15 2020 at 07:42):

Yes. Not the ones in your brackets.

Jose Costa Teixeira (Sep 15 2020 at 07:49):

Thanks. For other definitions, like national concepts that do not map 1:1 to an IDMP level (e.g. paracetamol tablets 500 mg pack of 20, but no brand), are these supposed to support it? I think MedKowledge covers those.

Rik Smithies (Sep 15 2020 at 07:55):

To represent any product you use MedicinalProductDefinition, but the package specific info goes in PackagedProductDefinition

Rik Smithies (Sep 15 2020 at 07:55):

It's a multi level model

Jose Costa Teixeira (Sep 15 2020 at 07:58):

I expected that answer. What is the boundary with MedKnowledge? Why not use that, which is also a definition?

Jose Costa Teixeira (Sep 15 2020 at 08:39):

@Rik Smithies @Jean Duteau is that boundary defined? I need to convey a definition of a product that does not match one of IDMP levels. The way that resources are structured, I find MedKnowledge much more convenient, because BRR resources require some collage (contained? as a bundle?)

Jose Costa Teixeira (Sep 15 2020 at 08:46):

(This is not a new requirement)

Rik Smithies (Sep 15 2020 at 08:54):

If you need multiple resources in FHIR you can use a bundle, or contained, or you can just put all the resources on the server and let the references show the links.

Rik Smithies (Sep 15 2020 at 08:58):

All products can be mapped to IDMP, or at least that is the theory, and it is thought that all EU and US medications do fit. But if you have one that does not, then let us know and we can take a look. The FHIR product model is split over several resources as we have seen. For different aspects you may need to use multiple resources, or you may not - it depends what data you want to carry. A basic product definition with names, identifiers, indications, legal status, classification, manufacturer can be represented just using MPD for instance.

Jose Costa Teixeira (Sep 15 2020 at 09:00):

this example I gave is a well known example on the clinical and regulatory space. At some point we even wondered if we needed to change IDMP for that (forthunately we didn't).

Jose Costa Teixeira (Sep 15 2020 at 09:01):

my question was whether the boundary is clear. I don't want to promote MedKnowledge if we have the other resources. and if we have those, we should have this as initial guidance.

Rik Smithies (Sep 15 2020 at 09:02):

ok. you are welcome to tell us what it is like if you want some assistance with it.

Jose Costa Teixeira (Sep 15 2020 at 09:02):

again, I don't understand.

Jose Costa Teixeira (Sep 15 2020 at 09:02):

from what you are stating @Rik Smithies , I don't need a MedKnowledge for that example - so what is the rule?

Rik Smithies (Sep 15 2020 at 09:03):

For a full definition, use MP. It is true that some level of detail can be represented in MK, and even in basic Medication. But they don't scale, so its not a full solution.

Rik Smithies (Sep 15 2020 at 09:04):

If your use case can be fulfilled by the Medication resource, then you can use that.

Jose Costa Teixeira (Sep 15 2020 at 09:04):

@Jean Duteau is that also your understanding? In a medication catalog, I use the IDMP/Regulatory resources?

Rik Smithies (Sep 15 2020 at 09:06):

We call those resources "Medication Definition", since they are neither limited to IDMP or regulatory.

Jose Costa Teixeira (Sep 15 2020 at 09:07):

(yes, you got the point, forgive me my abuse of language)
My example is such a simple one, and is transversal from regulatory to drug dictionaries...

Jose Costa Teixeira (Sep 15 2020 at 09:08):

I don't know if there is guidance, but every discussion seems very complicated.
I was expecting some more smoothness in these resources, given the assertivity in these discussions.

Rik Smithies (Sep 15 2020 at 09:10):

some of the guidance you are looking for is not yet written down. But you can help us create it. Also if you want help with mapping an example, let us know what it is.

Rik Smithies (Sep 15 2020 at 09:21):

btw the way I have it is that MPD is the medication (definition) and MK is about the medication (context and usage).
Some aspects overlap, and in those cases this is solved by using a common structure (e.g. ClinicalUseIssue). So there is overlap between all the resources used by MK and all the resources used by MPD. But should not be much direct overlap. But they will both have some fundamentals in common, same as with Medication.

Rik Smithies (Sep 15 2020 at 09:23):

Also note that an MK can reference an MPD as its definition

Jose Costa Teixeira (Sep 15 2020 at 09:36):

If we want to implement Product Dictionaries (à la ISO 19256) this boundary should be clear. Perhaps an end-to-end example, from regulatory to clinical, to see the transition?

Jose Costa Teixeira (Sep 15 2020 at 09:55):

I understand you can use 2 Medication definition resources. I also think you can use a MedicationKnowledge. This same example (we want to define a product which is Paracetamol 500 mg tablets box of 20, no brand" can be done at national regulators, or inside a hospital.

Rik Smithies (Sep 15 2020 at 09:57):

re the ISO 19256 issue, that would be a good thing to have, yes

Jose Costa Teixeira (Sep 15 2020 at 10:01):

I did request that in the past, I got this as a response:
Jean Duteau said:

Pharma company creates a new medication product. They need to submit their product reference information to a registrar such as the EMA or the FDA. They use MedicinalProductDefinition as their resource as this contains all of the reference information that a registrar needs to evaluate, register, and authorize medication products.

The product is now on the market and a drug knowledgebase such as Medi-Span or First Data Bank includes it in their product. Regional health authorities and drug insurance companies list the product in their formulary. They all use the MedicationKnowledge resource to convey their knowledge information.

I think this should be documented

Rik Smithies (Sep 15 2020 at 10:04):

I agree

Jose Costa Teixeira (Sep 15 2020 at 10:12):

(i think this says that i should use MedKnowledge for my example)

Rik Smithies (Sep 15 2020 at 10:26):

When I mapped a UK drug dictionary to FHIR, which has a distinct products and packs structure defined, I found I needed to use the Medication Definition resources. However I did also use MK for some of the more context specific items, such as pricing.

Peter Jordan (Sep 15 2020 at 22:46):

@Rik Smithies - that's one way to do it. Another approach is to map to terminology resources - namely CodeSystem and ValueSet. I believe that @Dion McMurtrie from CSIRO in Australia has tried both approaches. To some extent it boils down to whether one prefers to create Code System properties or extensions on the Medication Resources.

Dion McMurtrie (Sep 16 2020 at 06:37):

Yes I used STU3 Medication some time back for an AMT experiment, I've been meaning to refresh that to R4 MK. It is still up at https://medserve.online/

Certainly there's quite a bit of overlap now between the Medication Definition resources, Medication and MedicationKnowledge. I'm not sure I still follow the distinction between these and how to determine which use case is fulfilled by which resource.

Is there some sort of guidance on this, particularly the future direction of these resources?

Rik Smithies (Sep 16 2020 at 08:11):

@Peter Jordan Codes can only get you so far. The full data has numeric values and textual descriptions. You cannot code integers or text.

There is a reason that we use Observation and Condition FHIR structures for moderately complex data and don't just have a bunch of codes. We do need information models. UK dm+d has been mapped to SCT for years (and so could be put into CodeSystem), and it does cover the gross structure, virtual to actual packs and so on, but it's a necessarily incomplete mapping.

Medication Definition is more than just a bunch of codes. Day-to-day prescribing may need just the codes it is true, and the very small Medication resource (often just a code and a coded form in there). For that you can just use SCT or NDC etc and it's fine. Maybe a CodeSystem full of codes is all you need to support that.

But that is not the same use case as the Medication Definition resources, where you are giving the entire product data such as the strengths of the ingredients.

@Dion McMurtrie There is overlap between Medication and the Medication Definition set of resources it is true, but they are a world apart. Medication is for the day-to-day prescribing cycle, the key basics. MedicationKnowledge is for data about medications - usage, context, guidelines, pricing etc. The Medication Definition set (so that is MedicinalProductDefinition, PackagedProductDefinition etc, here http://build.fhir.org/medication-definition-module.html) are for the fundamental definitions of the medication items themselves - the intrinsics. And overlap does exist, but is managed by using the same structures in both. Both use the Ingredient resource for instance and both use ClinicalUseIssue for the indications. The MedicationKnowledge resource has an "associatedDefinition" link to a MedicinalProductDefinition resource that lets you hold the full data if you need to.
It should also be possible to point a Medication at a MedicinalProductDefinition, if you choose to host your medication definitions in a structured FHIR format and want to use a reference (and not an indirect code lookup). And that will also show that there is prescribing of medication and there is definition of medication and they stand separate but connected. You cannot directly prescribe a MedicinalProductDefinition, you only prescribe a Medication that "has-a" MedicinalProductDefinition (just like it "has-a" SCT code often).

Peter Jordan (Sep 16 2020 at 08:54):

@Rik Smithies Agree that Codes (which are simply concept identifiers) themselves are limited. However, you seem to suggest that medicine terminologies - which do contain text and numeric properties - cannot be directly implemented as Code Systems, which I would disagree with. NZMT, for example, has a whole host of these, including the strength of individual ingredients for example and it's not certain if we'll ever map that to SCT or, indeed, whether we need to.

I'm also not ignoring the role of information models - it's just a case of which one best suits a particular use case. There are two generic sets of these that I encounter in my day job that may be served by the Medication Definition Set - one is to support the NZ Formulary and the other relates to pricing and stock control.

Rik Smithies (Sep 16 2020 at 09:50):

hi Peter, yes anything is possible if you try hard enough :-)
I have never thought of a code system as a place to put numbers and dates and text though.
Your example is nice but it uses a flat list of key value pairs, and strings for the numerics.
I would say that is a limited solution that may be fine for a small-ish information model ("drug codes plus") but is unlikely to scale to bigger richer models that are needed for other uses.
But if its good enough for what you need then that is great.
I don't think we will be eliminating creative use of code systems any time soon.

Jose Costa Teixeira (Sep 16 2020 at 10:11):

Stock control is stock control, not medication definition. What scope you have in mind @Peter Jordan ?

Jose Costa Teixeira (Sep 16 2020 at 10:12):

we are looking at an Inventory Report resource (how many items we have, where items=any product),

Peter Jordan (Sep 16 2020 at 21:46):

@Rik Smithies - agreed, and you may be interested (or not) in the introduction of concrete domain values to SCT.
@Jose Costa Teixeira - I should have been more explicit. Not full-blown stock control, but certain stock-related properties - e.g. stock in hand, prices. We're receiving requests to add these as extensions to the Medication Resource, but are wondering if they belong elsewhere.

Jose Costa Teixeira (Sep 16 2020 at 21:47):

I think had something like this in a project - the medication "catalog" contained something like "in stock" or "in emergency stock".

Jose Costa Teixeira (Sep 16 2020 at 21:50):

in the current picture, I would put those summary info bits as extension to the medicationKnowledge resource.
It will overlap with "proper" stock management, but I think that is ok - and that is what implementers do anyway (judging from my limited experience)

Rik Smithies (Sep 16 2020 at 21:58):

Peter - that is interesting indeed. A surprising move, but I can see the usefulness. Next would be to add a REST interface for writing new data :-)
Can our FHIR resources represent code systems that have numerics in them?

Peter Jordan (Sep 16 2020 at 22:18):

Good question, Rick. At present these values are SCT concepts and, as such, their descriptions are rendered in strings. AFAIU, the replacements will be attribute values and will also be rendered as strings (with a # prefix) in the RF2 distribution format...further information

Dion McMurtrie (Sep 17 2020 at 09:59):

@Rik Smithies I agree that there needs to be a balance between what goes in terminology/coding systems and an information model - too much skew towards overloading one or the other creates problems. That's obvious at the extremes, but can sometimes be hard to find the sensible hard line in the large grey zone. I guess that's why we need to leave wriggle room in each for people to choose their own adventure (or poison) and still achieve sufficient interoperability.

But @Peter Jordan makes a good point regarding representing attributes that have numeric, date or string values. Code systems with formal semantics (like SNOMED CT) can use DL features like Concrete Domains (aka Datatype properties) for those properties to be part of a complex definition of a concept and therefore queried and reasoned with. AMT (Australia's SNOMED CT drug extension) does exactly this, and has since 2014, and SNOMED International has recently adopted this feature.

So while it is true that dm+d's drug extension doesn't formally represent these attributes in its model and is therefore semantically incomplete, it doesn't mean it isn't possible, or in fact valuable for organising, reasoning with and analysing data using a drug terminology.

Dion McMurtrie (Sep 17 2020 at 10:36):

I'll try to elaborate on my original question and confusion. Don't take any of this the wrong way, I'm just trying to get my head around it so I know what bits to use for what, and why things are there.

I get the use case for the Medication resource as it is. Perhaps it is a little over simplified, but it is a resource that provides simple yet sufficient identification and definition of a medication for clinical use cases (like prescribing, dispensing, recording...etc). Could just be a wrapper around a code which provides all the definition, or it might define the medication in the case of a compounded medication or extemporaneous preparation. Makes sense.

MedicationKnowledge confuses me a bit, because it has some information like costs, monitoring programs, guidelines etc (which make sense), but it also has amount, dose form, ingredients, strengths which seem highly overlapping with Medication and/or MedicinalProductDefinition it references. To me that seems like redundant information that I'm not sure when to/not populate, and what to do if it disagrees.

The Medication Definition resources seem to be for regulators and manufactures rather than clinical use cases? It seems to mirror IDMP which is very much in this space. I guess one of my questions is if IDMP exists, what is the benefit of replicating it in FHIR? Wouldn't the regulators/manufacturers just use IDMP because that's what it is for? It would be different if IDMP didn't exist and something was needed in that space, but IDMP does exist and seems to be progressing and have traction. So unless there are real deficiencies with IDMP doesn't FHIR just need a way to reference IDMP things, rather than redefine a rendering for them in FHIR? Perhaps I'm just missing a whole bunch of context and use cases. I'm far from an IDMP expert.

However that aside, if FHIR does take on that use case, it feels like we have MedicationKnowledge, Medication and MedicinalProductDefinition (et. al.) considerably overlapping. Both Medication and MedicinalProductDefinition "identify and define" medications, and MedicationKnowledge doesn't set out to do that but has enough elements to put it in that space and be problematically overlapping.

It feels to me that there is a single thing - medication - that we are trying to identify and define, and then possibly attach some other non-defining information to for different use cases. I think those things - the identification/definition and the non-defining information - should be kept separate. I'd really like one way to identify and define things, and then structures that can attach information to that thing without overlapping.

So I guess my questions are

• isn't Medication (identification and definition) really just a chopped down profile of MedicinalProductDefinition cleaving away the detail that is unnecessary to meet the clinical use cases?
• shouldn't the MedicationKnowledge (non-defining information) reference and add information to, but not attempt to redefine the defining parts of the identifying/defining resource it is referencing (whether that is Medication or MedicinalProductDefinition)?
• why are we replicating/rendering IDMP in FHIR rather than referencing it?

It may well be that I'm missing a heap of context that makes sense of this and I've really got it all wrong - I'm more than happy with that! If anyone can correct my logic above and help me understand it I'd really appreciate it!

Jose Costa Teixeira (Sep 17 2020 at 11:22):

@Dion McMurtrie Agree with your remarks - I do take other conclusions (i would just start with less resouurces as I mentioned before) but I believe we'll get there.

Jose Costa Teixeira (Sep 17 2020 at 11:22):

On IDMP vs FHIR: IDMP is not a technical standard. IDMP defines something in the space of a logical model, but is not a technical implementable standard. So it needs to be implemented. Initially IDMP said "systems implementing this model shall use SPL for exchanging this information" but we removed it and it became thus open to use FHIR as well.

Rik Smithies (Sep 17 2020 at 11:23):

hi Dion

The IDMP question is easy. IDMP is a logical model and has no physical expression. So the Medication Definition resources cover that scope (but are not limited to it), and allow you to actually use IDMP. If you want to send IDMP using CSV files or in your own made up XML, you can. But people want to use FHIR.

Medication is in effect a chopped down profile of the MedicinalProductDefinition resource plus the other Medication Definition resources, yes.
It could have been physically a profile of that resource it is true and this was seriously considered as a design choice and discussed at some length by the committees. This approach was rejected because it would mean that Medication, a very key resource in FHIR would be appear much more complicated, for those new to FHIR. It would be a profile - and no core "resources" are profiles - and of something that seems very alien to a pharmacy person. The stuff in MPD resource is not that familiar to prescribers (we hear) and they don't need to have it up front. So this was simply a deliberate design choice to make FHIR easier to understand overall. Not a technical choice, a practical ease of use one. Yes it comes with some downsides.

MedicationKnowledge does reference and not redefine some things such as Ingredient and ClinicalUseIssue (for indications etc). I would like to see more of that and there is ongoing work there. For instance the PackagedProductDefinition resource is being considered for the packaging parts, I understand. I think MK could evolve so the definitional parts are less to be honest, and it becomes more clearly about context. But that is just one opinion and this is all a process of discovering what works best for the people that actually want to use these things. Sometimes a small amount of duplication is better than having to use a huge other structure (you don't want to reference a whole other resource to have "form" (a code)). And sometimes it's not.

Jose Costa Teixeira (Sep 17 2020 at 11:23):

so there was a need to promote a technical standard around regulatory definition of medicines, hence this initiative.

Rik Smithies (Sep 17 2020 at 12:09):

@Dion McMurtrie on the issue of terminology vs information model, there will probably always be a grey area in the middle yes. I see no problem with codes systems evolving to have more of the properties of information models, such as concrete data. And for fairly static things that is ok. Nether information nor terminology is perfect for all use cases and both will continue to co-exist I am sure. There does come a point when a model like FHIR is just easier to use than the SNOMED model though, imho.

But the real difference is when you have dynamic data. When you are exchanging data about an evolving product, around different parties, who are updating different pieces (over months or years), you need an update-able model rather than one that is mostly intended to be read only distribution format. Then once you have that need, you have those definitional resources even if you don't intend to update them often. And people may want to use the same structures for both circumstances.

Melva Peters (Sep 17 2020 at 12:46):

We started out this work thinking that there would be a single resource with multiple profiles, but that idea was turned down. That's why we ended up where we are. We did work on a common model so that the resources are harmonized where there is overlap.

Rik Smithies (Sep 17 2020 at 12:49):

hi Melva, it was turned down in that we didn't want Medication to be a profile of all the Medication Definition resources, but I don't think that decision had any relationship to MedicationKnowledge being a profile.

Melva Peters (Sep 17 2020 at 12:57):

No, the original discussion was to have one single resource and then multiple profiles

Jose Costa Teixeira (Sep 17 2020 at 13:06):

Melva Peters said:

No, the original discussion was to have one single resource and then multiple profiles

that should have been our starting point indeed. Long before we had Medication Definition resources I recall some valid opinions (besides mine) in that sense. I missed that turning point.

Melva Peters (Sep 17 2020 at 14:03):

@Jose Costa Teixeira and it was, but it was turned down early on - if I remember correctly it was at the September WGM in San Diego

Rik Smithies (Sep 17 2020 at 14:18):

The reasons it was rejected are still valid today

Jose Costa Teixeira (Sep 17 2020 at 14:31):

I personally don't know those reasons.
But I also expect that there are opposite reasons as well, especially looking back and seeing how clear, lean and clean are our resources..

Jose Costa Teixeira (Sep 17 2020 at 14:33):

I.e. I'm sure we had valid reasons, but looking at what we have today, that seems far from a final decision. We took the best decision possible with the information we had, but today we have more info

Rik Smithies (Sep 17 2020 at 14:40):

Some of the reasons were mentioned just above. One of them was this:
"This approach was rejected because it would mean that Medication, a very key resource in FHIR would be appear much more complicated"
You can read the rest of the text around it above. You may disagree with it, but there reasons are there to know. That was true then and it is true now.

Jose Costa Teixeira (Sep 17 2020 at 15:06):

I did not know where to find those, sometimes I miss things in Zulip. And I don't disagree with one argument.

Jose Costa Teixeira (Sep 17 2020 at 15:06):

We took the best decision possible with the information we had, but today we have more info

Rik Smithies (Sep 17 2020 at 15:18):

Just so we can be sure we are all on the same page, here are two more reasons why there isn't one big resource. These applied at the time the consensus decision was made and seem to still be valid:

Products and tablets and packages and ingredients, although all "medicinal product things" are significantly different entities, that have different properties and have different roles.

You need individually addressable items of each, to cope with the known use cases.

You can have one huge model that has all of them in and then profile them down into useable chunks.
But there is no need to make an actual huge FHIR resource with hundreds of classes in it, purely to then profile it and never use it. We just "profiled" the logical superset model to make resources.

Whether we chose the exact correct set of resources and boundaries is a different issue.
(One resource too many may result in a little extra fluff, or an relatively unused resource, but if you have two entities combined that need to be addressed separately, there is no easy way out of that.)

We gave it our best effort and we are now implementing to see if it works (as is the FHIR way).

Another approach would be to have one overarching model that was somewhat smaller but very generic.
You could model products and tablets and as one thing "MedicinalProductEntity", having attributes called "property".
But that thing would be so generic as to be unusable, other than as a meta model.
FHIR is not like that (it's deliberately not the RIM), and doesn't have resources like that.

If you want a higher level logical model then you can, but in the end you need resources.

Jose Costa Teixeira (Sep 17 2020 at 15:28):

Rik Smithies said:

Products and tablets and packages and ingredients, although all "medicinal product things" are significantly different entities, that have different properties and have different roles.
You need individually addressable items of each, to cope with the known use cases.

OTOH, there are many other medicinal product things, with a different mix of properties. Sticking to one resource makes those cases more complicated - and those cases will be the norm before and after IDMP. The need for individually addressable items is also covered by one resource with N profiles.

This is one valid reason (I don't think anyone is arguing that), just that there are more use cases and therefore other reasons. What is the second reason?

Rik Smithies (Sep 17 2020 at 15:41):

One resource with N profiles ends up unusable if the N things are categorically different and yet need to be used in close associations.

The individually addressable things need to have usable names.

If I want to represent a product with packaging and tablets in it, it's not easy if they are all called product and they have a product inside with products inside that which are made out of products.

That is exactly why V3 failed. No one thinks that way.

We know there are more use cases, and I can repeat: we are not done yet. We await your, and everyone's, other use cases. But we need to make some progress while we are waiting :-)

(btw the two reasons I stated were:
one huge model doesn't work
and
one super generic model doesn't work.
But it you want to model it as one generic answer with two profiles, that is up to you :-)

Jose Costa Teixeira (Sep 17 2020 at 17:28):

I don't understand "up to you" - We are trying to give feedback to reach a joint approach.

Jose Costa Teixeira (Sep 17 2020 at 17:29):

IDMP was supposed to be based on SPL (one super generic model IMO).

Rik Smithies (Sep 17 2020 at 17:30):

that was just a little joke Jose

Jose Costa Teixeira (Sep 17 2020 at 17:30):

anyway, it's not that we have yet any feedback from implementers - we do know how drug DBs work; we know how prescription and supply systems work; devices too. What we do not have is great experience in regulatory models post-idmp.

Rik Smithies (Sep 17 2020 at 17:38):

re SPL, yes and it was a terrible idea.

The idea to do IDMP on SPL was because SPL was the only thing around, 10 years ago. Indeed a super generic model (at least CPM that it is based on) and deeply flawed because of it. As soon as FHIR came along it was realised that it was far easier than SPL and V3 in general, so we moved along. We don't do super generic now and are better for it.

It was only the implementation guide for IDMP that was about SPL anyway, the actual standard itself was not.

Jose Costa Teixeira (Sep 17 2020 at 17:57):

It was only the implementation guide for IDMP that was about SPL anyway, the actual standard itself was not.

I'll check that later. I remember suggesting a change, and I think it was to one of the 1161x standards

Rik Smithies (Sep 17 2020 at 17:59):

It's history

Jean Duteau (Sep 17 2020 at 18:24):

I hesitate to wade in here but I'll hopefully end up unscathed. @Rik Smithies you can correct my words about MedicinalProduct if I say anything incorrect.

RESOURCE USE CASES
1) Medication - used for the simple specifying of products for prescribing, dispensing, administration, and other uses. Allows for the specification of a code for coded products or a simple recipe of ingredients for compounds/extemporaneous products.
2) MedicinalProduct (and its associated resources) - used for the complete specification of a medication. Primarily used for the regulatory registration of medicinal products. It has some affinity to IDMP but is NOT IDMP-on-FHIR.
3) MedicationKnowledge - used for the representation of medications in drug knowledge bases and formularies. Has more definitional information than Medication but less than MedicinalProduct. It also includes information about the medication that is non-definitional (costs, classifications, guidelines, etc.)

In terms of maturity (ignoring the FMM levels for now and purely from my perspective), I would say that Medication and MedicinalProduct are further along in their ability to progress than MedicationKnowledge. I know that there are a number of projects/groups working to advance the MedicinalProduct space. Unfortunately, although Pharmacy has had initial conversations with knowledge base vendors and formulary creators, we have not had the uptake we desired, so a lot of our data elements are speculatory in that we've looked at existing formularies and knowledge base products and tried to model those as best we can.

Rik Smithies (Sep 17 2020 at 18:30):

sounds about right to me. The grey area is probably "drug dictionaries", which I think are distinct from knowledge bases (discuss). I think they need more than what is in MK.

Jose Costa Teixeira (Sep 17 2020 at 20:32):

there is overlap between those 3 use cases. We can keep trying to define boundaries by convention - it will always be fuzzy.

Jose Costa Teixeira (Sep 17 2020 at 20:34):

and we can try to arbitrate a boundary between drug dictionaries and knowledge bases, (and drug databases ?)... (why?)

Jose Costa Teixeira (Sep 17 2020 at 20:35):

BTW, medicinal product and administrable product - i suggested a merge between those. The separation is clear in IDMP, but other than that, I think it will just be messy in practice.

Rik Smithies (Sep 17 2020 at 20:48):

yes we did discuss MedicinalProductDefinition and AdminstrableProductDefinition merge the other day. The issue is that one product can have several administrable forms, from several other manufactured items.
There is no clear way to represent that without using different resources.

Jose Costa Teixeira (Sep 17 2020 at 20:49):

different resource instances, not different resource types

Rik Smithies (Sep 17 2020 at 20:49):

that is a different issue that we discussed earlier

Jose Costa Teixeira (Sep 17 2020 at 21:00):

Rik Smithies said:

The issue is that one product can have several administrable forms, from several other manufactured items.
There is no clear way to represent that without using different resources.

you can have different resource instances, you don't need two types.

Rik Smithies (Sep 17 2020 at 21:07):

yes, that is what we discussed earlier

John Moehrke (Sep 17 2020 at 22:55):

the sizing of resource definition was a few messages ago, but... I would also recommend thinking about the content of each resource type relative to the intended uses of that data. It is far easier to constrain the access control at the resource level, than it is to have data within a larger resource that is useful for different audiences. For example the system that is responsible for watching stock numbers, and trigger restocking, doesn't really need to know the medicine chemical makeup. I don't claim that use-case is useful, but it seemed to appear earlier to day on this thread.

Jose Costa Teixeira (Sep 18 2020 at 07:28):

inventory management is a different set of use cases and is a rather different set of resources. Let me try to explain the point here:

Jose Costa Teixeira (Sep 18 2020 at 07:40):

for regulatory submission (manufacturer to regulator), the regulators have a new standard - IDMP - which defines different concepts:

• the substance (defining a substance)
• the formulation / presentation of a product (in generic terms), containing attributes like substance, strength, form, -e.g. acetaminophen 500 mg in tablets
• the manufactured item, which links to the previous and contains attributes like manufacturer, brand name, authorization number, etc. - (e.g. ACME tylenol for kids rainbow colors, authorization B20839483)
• the package, which links to previous and contains other attributes like package type, qty per pack.. e.g. the colored box with 21 tablets in 3 x 7-colored blisters

Jose Costa Teixeira (Sep 18 2020 at 09:55):

For them, it's fine to have these as very distinct resource types. Because these are things that (mostly) have different lifecyles, and the attributes are clearly distinguished in IDMP. And they can enforce that, because they are the receivers.

Jose Costa Teixeira (Sep 18 2020 at 10:00):

National regulators, however, will have it more fuzzy - they will have different kinds of concepts, with a different mix of these same attributes. For example the "national prescribable product" in some countries is "acetaminophen 500 mg tablets, box of 20, independent of brand name".
These concepts have their own lifecycle (a national lifecycle). And we do not want to create specific resource types for each concept in each country.
Overall, the need to exchange these is today more common than the need for IDMP-like regulatory submission.

Jose Costa Teixeira (Sep 18 2020 at 10:03):

And the drug database / drug knowledge / drug dictionary publishers, they must handle all these concepts. They need to add several types of elements - things like "official prices", "existing literature", "history of recalls", interactions..... And they need to do this on any level, not just the official IDMP levels.

Jose Costa Teixeira (Sep 18 2020 at 10:32):

that boundary is already fuzzy enough, but even when prescribing, in some cases you need to tell more about the medication - for example in cross-border prescription you need to say

I prescribed "Italian prescribable code 12345" - but I can also tell you this is acetaminophen 500 mg tablets box of 20.

This wil make sure that the receiver side can understand what was prescribed even if they don't know the code

Jose Costa Teixeira (Sep 18 2020 at 10:35):

these cases are all in the "prioduct definition / specification" and a flatter model, with one resource type, that can be profiled in the different concepts, works, and works better.

Rik Smithies (Sep 18 2020 at 10:36):

Thanks for the example Jose, that is really useful. That would be like this:

<MedicinalProductDefinition xmlns="http://hl7.org/fhir">
   <id value="Acetamin-500-20-generic"/>
   <contained>
      <PackagedProductDefinition>
         <id value="Acetamin-pack-20"/>
         <package>
            <type>
               <coding>
                  <code value="cardboard box"/>
               </coding>
            </type>
            <containedItem>
               <item>
                  <reference value="#Acetamin-tab-500"/>
               </item>
               <amountInteger value="20"/>
            </containedItem>
         </package>
      </PackagedProductDefinition>
   </contained>
   <contained>
      <ManufacturedItemDefinition>
         <id value="Acetamin-tab-500"/>
         <manufacturedDoseForm>
            <coding>
               <code value="tablet"/>
            </coding>
         </manufacturedDoseForm>
         <ingredient>
            <reference value="#Acetamin-ing-50"/>
         </ingredient>
      </ManufacturedItemDefinition>
   </contained>
   <contained>
      <Ingredient>
         <id value="Acetamin-ing-500"/>
         <role>
            <coding>
               <code value="active"/>
            </coding>
         </role>
         <substance>
            <codeCodeableConcept>
               <coding>
                  <code value="{acetaminophen}"/>
               </coding>
            </codeCodeableConcept>
            <strength>
               <presentation>
                  <numerator>
                     <value value="500"/>
                     <unit value="mg"/>
                  </numerator>
                  <denominator>
                     <value value="1"/>
                     <unit value="tablet"/>
                  </denominator>
               </presentation>
            </strength>
         </substance>
      </Ingredient>
   </contained>
   <identifier>
      <system value="http://example.nation.org/drugs"/>
      <value value="12345"/>
   </identifier>
   <packagedMedicinalProduct>
      <reference value="#Acetamin-pack-20"/>
   </packagedMedicinalProduct>
   <name>
      <productName value="Acetaminophen 500 mg tablets [generic]"/>
   </name>
</MedicinalProductDefinition>

Jose Costa Teixeira (Sep 18 2020 at 10:38):

@Rik yes, the current model requires you to contain different resource types for something that should be flatter. That is the point

Jose Costa Teixeira (Sep 18 2020 at 10:39):

This would be a single (?) MedicationKnowledge resource. And in a prescription would be a Medication resource.

Rik Smithies (Sep 18 2020 at 10:40):

in a Medication resource it would be a single code, yes

Jose Costa Teixeira (Sep 18 2020 at 10:40):

no, a medication with extra attributes

Jose Costa Teixeira (Sep 18 2020 at 10:41):

in practice, implementers are free just say "I don't care about understanding these IDMP concepts, I just need 4 attributes, so I'll just make extensions to Medication resource".

Rik Smithies (Sep 18 2020 at 12:20):

I would not recommend ad hoc extension attributes to Medication.

Also to be fair, if you don't want to implement multiple resources, or don't even know they exist as separate entities, the XML above is effectively just one resource.

It can be created as one, and sent/stored as one. It just has the extra word "contained" in it a few times. Even better in json, it's only there once :-). So the downside is one or two extra lines - I doubt that would phase anyone (and in fact the above XML is actually flatter - less nested - than the one big resource version, where it would go down and down).

And with this you then do have the possibility of fine grained updates, reusing ingredients across products or packs, in manufacturing plans and so on, which you don't have otherwise - and which is needed. So the multi-resource approach has benefits.

If we find during testing and implementation that no one uses the levels and it's always contained, then we can look at that.

Jose Costa Teixeira (Sep 18 2020 at 13:42):

There seems to be a confusion here between different resources and different resource types
the above example contains different resource types. Yes, it's one resource, implementers will know what contained means.

Jose Costa Teixeira (Sep 18 2020 at 13:43):

I am not interested in one resource. I am interested in less resource types, that can be instanciated more freely.

Jose Costa Teixeira (Sep 18 2020 at 13:44):

And with this you then do have the possibility of fine grained updates, reusing ingredients across products or packs, in manufacturing plans and so on, which you don't have otherwise - and which is needed. So the multi-resource approach has benefits.

Yes, you do have it otherwise.

Jose Costa Teixeira (Sep 18 2020 at 13:45):

in the XML above, just replace ManufacturedItemDefinition and PackagedProductDefinition by MedicinalProductDefinition- that will give a sense of the alternative I push towards

Jose Costa Teixeira (Sep 18 2020 at 13:48):

this seems to be a cause for debate , so I repeat:
It's not about "less resources". It's about "less resource types". Because implementers don't see the boundary between these different resource types. And because that boudnary is only clear in some limited scope

Rik Smithies (Sep 18 2020 at 14:15):

Jose - yes I guess we all understand your view.

The counter view is that a recursive "thing" structure that loops back on itself multiple times, with a collection of generic attributes, is very hard for implementers to understand (see V3 CPM).

Imho that is far worse than the fact there there will be some imperfect boundary conditions, in a complex set of resources. Some areas are not complete, some boundaries need more exploring and documenting, but that doesn't mean it is impossible to complete them to a practically useful level.

I do believe however that it is impossible to make a super generic recursive structure - supporting at least 4 levels - easy for implementers to use. I know you disagree and that this will likely not change your mind. Nor should it.

I think the best thing to do is what FHIR does once a committee decision has been reached (which it was a while ago): implement and test. Then gather more requirements, and implement and test again. Would you agree that is a good way forward?

Lloyd McKenzie (Sep 18 2020 at 14:35):

A recursive structure that's profiled differently for each layer should largely be indistinguishable for implementers from distinct resources I would think...

Rik Smithies (Sep 18 2020 at 14:39):

but when you look at the XML... none of these things will have the right names or the right attribute names

Jose Costa Teixeira (Sep 18 2020 at 14:39):

I did not ask for a super generic structure à la SPL - I think we should have one structure (or, say a couple), that combine the specific attributes across 2 or 3 of the IDMP levels.

Jose Costa Teixeira (Sep 18 2020 at 14:40):

so in the regulatory space you can have your file with contained resources. in a drug dictionary, you can have those attributes in a flatter xml. There are options there, and I think both options would work better than this forced separation into IDMP attributes.

Rik Smithies (Sep 18 2020 at 14:41):

profiling is not GreenCDA. it doesn't make an ugly model beautiful

Lloyd McKenzie (Sep 18 2020 at 14:41):

Observation is a single resource, yet implementers manage to handle complex panels with a couple of levels to them. The 'name' in their heads comes from the Observation.code. So long as there's a way to tell what you're looking at, implementers can generally handle it, even though Observation.value means different things.

Rik Smithies (Sep 18 2020 at 14:41):

but we don't use Observation for Condition and for Procedure.

Lloyd McKenzie (Sep 18 2020 at 14:41):

Also, presumably the attributes would generally mean the same thing across levels - it would primarily be a question of what attributes are permitted.

Jose Costa Teixeira (Sep 18 2020 at 14:42):

Why not profiling? MedicinalProductDefinition.identifier could be a PhPID, or a National ID, or a PCID, or ...

Lloyd McKenzie (Sep 18 2020 at 14:42):

True. But Jose's assertion is that the different levels of drug representation are more akin to different levels of Observation

Rik Smithies (Sep 18 2020 at 14:42):

but that premise is false. An ingredient and a tablet and a package - all very different with different properties.

Jose Costa Teixeira (Sep 18 2020 at 14:43):

Rik Smithies said:

but that premise is false. An ingredient and a tablet and a package - all very different with different properties.

they are all product specifications.

Lloyd McKenzie (Sep 18 2020 at 14:43):

An ingredient and a tablet aren't so different. You can have a drug that's a powder or a liquid and you can have an ingredient that's a powder or a liquid

Rik Smithies (Sep 18 2020 at 14:44):

they are also all entities, but that is not really the point. A tablet is not like a package, even if they are both in the same domain

Lloyd McKenzie (Sep 18 2020 at 14:44):

Tablet and package I will grant are distinct

Jose Costa Teixeira (Sep 18 2020 at 14:44):

the boundary is fluid - in my example I show something that is between the concepts of MedicinalProduct and administrable product and package.

Rik Smithies (Sep 18 2020 at 14:44):

they are both made of atoms too. but that is also not really of interest.

Lloyd McKenzie (Sep 18 2020 at 14:45):

But tablet & ingredient, not so much. And manufactured tablet with strength vs. not with strength, etc. are not really different things, just different levels of abstraction of the same thing

Rik Smithies (Sep 18 2020 at 14:46):

different roles Lloyd. Is a patient a practitioner? they both are both humans - so they are the same, right?

Lloyd McKenzie (Sep 18 2020 at 14:46):

Different participations, I think more than roles. And participations are handled in FHIR using relationships

Jose Costa Teixeira (Sep 18 2020 at 14:47):

@Rik Smithies yes, they are both humans. But when you exchange information about them, their role is clear. and there is hardly a mid-term. That does not happen in this domain

Lloyd McKenzie (Sep 18 2020 at 14:47):

The fundamental roles - "prescribable entity" and "administrable entity" often point ambiguiously to codes that come from any of the levels in real systems.

Rik Smithies (Sep 18 2020 at 14:48):

But we don;t have the RIM and mandatory profiles. We have resources. Which are easy to connect to each other with specific properties and specific relationships to each other.

Jose Costa Teixeira (Sep 18 2020 at 14:49):

As an example - I was against the addition of yet another level in IDMP for the concept of "acetaminophen 500 mg tablet box of 20". Because these are already possible combinations of IDMP concepts.

If I did not have the same perspective as I have here now, you could have not 4 but 5 resources because a group of people in Europe suggested a new IDMP concept. And who knows, we would still be adding to the list of IDMP concepts (thus adding more resources?).
That is what I am trying to expose.

Lloyd McKenzie (Sep 18 2020 at 14:50):

The boundaries of the resources are generally crafted to keep counts down and to avoid making differentiations that aren't consistently represented across pretty much all systems and all use-cases. And Jose's asserting that, in this case, the granularities currently proposed aren't sufficiently universal and are too tied to a single use-case.

Lloyd McKenzie (Sep 18 2020 at 14:51):

I'm not pushing for one outcome vs. another because I don't have a strong sense of what's universal in this space, I'm just saying that Jose's arguments may have merit.

Rik Smithies (Sep 18 2020 at 14:51):

yes he is asserting that. Assertions are just that.

Lloyd McKenzie (Sep 18 2020 at 14:52):

Is the group confident that there will never be other levels?

Jose Costa Teixeira (Sep 18 2020 at 14:52):

Lloyd McKenzie said:

The boundaries of the resources are generally crafted to keep counts down and to avoid making differentiations that aren't consistently represented across pretty much all systems and all use-cases. And Jose's asserting that, in this case, the granularities currently proposed aren't sufficiently universal and are too tied to a single use-case.

The granularities are defined in IDMP, but the many other product dictionaries and national product granularities will differ.

Rik Smithies (Sep 18 2020 at 14:52):

what we need is to take the use cases and try them out. If there are things that don't work, we can fix that.

Jose Costa Teixeira (Sep 18 2020 at 14:52):

Lloyd McKenzie said:

Is the group confident that there will never be other levels?

the group should be confident that there ARE many other levels.

Rik Smithies (Sep 18 2020 at 14:54):

BR&R have no intention of creating any other levels. If there is opportunity to remove a level, as evidenced by implementation, we will take it.

Rik Smithies (Sep 18 2020 at 14:59):

Jose - we don't call everything a "level". There are various permutations of data, and a set of resources that can deal with that. It's not perfect, or finished. But unless it can be shown not to work - please show us the gaps rather than just alluding to them - we should continue on our path to implement, test, gather requirements and make progress.

Jose Costa Teixeira (Sep 18 2020 at 15:01):

I got lost. There are 4.x levels in IDMP, so we have 4 main resource types. my suggestion is to reduce the number of resource types (and harmonize with the clinical ones) so that we can support more flexibility in the number of concepts/levels that we have out there (which are not 4 or 5)

Jose Costa Teixeira (Sep 18 2020 at 15:02):

Rik Smithies said:

There are various permutations of data, and a set of resources that can deal with that.

Suggestion is to make that set of resource types smaller thus supporting more concepts with a reduced complexity.

Jose Costa Teixeira (Sep 18 2020 at 15:03):

The problem is not whether it will work - the problem is the ambiguity.

Rik Smithies (Sep 18 2020 at 15:03):

But "make them smaller" is not a test case or a requirement. We understand your position . We have a set of candidate resources and want to test them out. Until we do that, or have strong evidence that there is sometime that needs to change, we will continue to develop and test.

Jose Costa Teixeira (Sep 18 2020 at 15:05):

I do not know how else to show the gaps. I gave an example that is common and requires a complicated structure. The requirement is "keep in mind that other concepts will exist and people do not know IDMP". Also "keep in mind that IDMP is the least mature part of this chain, look at the full lifecycle for ideas".

Rik Smithies (Sep 18 2020 at 15:05):

Also "support more flexibility" is not a actionable thing. Please give specifics that we need to support that we don't cover. And we can look at those.

Rik Smithies (Sep 18 2020 at 15:09):

We cannot action: "be less complicated" or "keep in mind that other concepts will exist...".

Those are not requirements. We can however gather actual requirements, keeping those things in mind as we do. When we have requirements, we can look at them.

Jose Costa Teixeira (Sep 18 2020 at 15:09):

take the example above, the one you showed. 4 attributes for a medication, 3 different resource types. If you think that is solid, I can't argue.

Rik Smithies (Sep 18 2020 at 15:11):

It works, and also work for other use cases that need the individual resources. The XML is really not that bad and the JSON is better :-) It's FHIR. Please show us a gap.

Jose Costa Teixeira (Sep 18 2020 at 15:11):

I got the point. I don't know if any requirement we present will meets the intake criteria. If everything is working fine, and if implementers "just" need to understand these resources when implementing a national drug repository,

Jose Costa Teixeira (Sep 18 2020 at 15:12):

then everything is fine, why are we bothering?

Jose Costa Teixeira (Sep 18 2020 at 15:13):

Seems like one regulator a few years ago: "we should use IDMP for everything, and nobody can prove to us it won't work".

Jean Duteau (Sep 18 2020 at 15:14):

Jose Costa Teixeira said:

take the example above, the one you showed. 4 attributes for a medication, 3 different resource types. If you think that is solid, I can't argue.

I hate to interrupt, but is the example "acetaminophen 500 mg tablets box of 20"? That doesn't seem to be something you'd be using the MedicinalProduct resources for. What context are you trying to send "acetaminophen 500 mg tablets box of 20"?

Jose Costa Teixeira (Sep 18 2020 at 15:15):

in several countries, this is one of the official concepts of medication that can be prescribed.

Jean Duteau (Sep 18 2020 at 15:16):

Jose Costa Teixeira said:

in several countries, this is one of the official concepts of medication that can be prescribed.

right, but you don't use MedicinalProduct resources for what you are prescribing but to define the product. I'm not sure you'd send MedicinalProduct instances to say I'm prescribing this.

Jose Costa Teixeira (Sep 18 2020 at 15:17):

not in a prescription. This is part of the national drug catalog

Jean Duteau (Sep 18 2020 at 15:17):

again, i'm not sure that MedicinalProduct instances are used in a national drug catalog either.

Rik Smithies (Sep 18 2020 at 15:18):

they are in Norway

Jose Costa Teixeira (Sep 18 2020 at 15:18):

I think the MedKnowledge (which is a super generic structure..) is a much better fit for that. But Rik just showed it works with the current resources.

Jean Duteau (Sep 18 2020 at 15:19):

ah, okay. this is where I check out of the conversation and go back to lurking :)

Jose Costa Teixeira (Sep 18 2020 at 15:19):

no you stay here! :)

Rik Smithies (Sep 18 2020 at 15:20):

I vote that we agree to disagree and go on to test our resources with real data and requirements

Jose Costa Teixeira (Sep 18 2020 at 15:20):

I think this is exhausted. It always gets to the same point: a redesign is not necessary because our initial decision still works. And any requirement is a matter of preference.

Jean Duteau (Sep 18 2020 at 15:22):

no, the point is "bring us a set of use cases and show us where we can improve". the one example you brought forward appears to be handled with the existing structure.

Rik Smithies (Sep 18 2020 at 15:22):

Indeed. We work in requirements first. Preferences are not so easy to implement. If the requirements lead to a redesign being needed, then redesign it is.

Jose Costa Teixeira (Sep 18 2020 at 15:22):

yes, I understand. It works and I cannot say this is messy because, well it works.

Rik Smithies (Sep 18 2020 at 15:23):

we exist to create working software

Jose Costa Teixeira (Sep 18 2020 at 15:24):

I can't imagine what requirement will be needed to make reconsider a more generic resource that gets profiled, instead of this variety.
Is that even conceivable, a requirement that will brig us to the drawing board?

Jean Duteau (Sep 18 2020 at 15:25):

yes, I have some requirements that I am working through to represent some SPL-like submissions and I have some questions/concerns about the current set of resources. Once I have determined whether the structures will or will not work, I'll be bringing those forward.

Rik Smithies (Sep 18 2020 at 15:25):

An actual requirement yes. "Have a generic resource" is not a requirement.

Jose Costa Teixeira (Sep 18 2020 at 15:27):

Jean Duteau said:

no, the point is "bring us a set of use cases and show us where we can improve". the one example you brought forward appears to be handled with the existing structure.

"
National regulators, however, will have it more fuzzy - they will have different kinds of concepts, with a different mix of these same attributes. For example the "national prescribable product" in some countries is "acetaminophen 500 mg tablets, box of 20, independent of brand name".
These concepts have their own lifecycle (a national lifecycle). And we do not want to create specific resource types for each concept in each country.
Overall, the need to exchange these is today more common than the need for IDMP-like regulatory submission.
And the drug database / drug knowledge / drug dictionary publishers, they must handle all these concepts. They need to add several types of elements - things like "official prices", "existing literature", "history of recalls", interactions..... And they need to do this on any level, not just the official IDMP levels.
That boundary is already fuzzy enough, but even when prescribing, in some cases you need to tell more about the medication - for example in cross-border prescription you need to say

I prescribed "Italian prescribable code 12345" - but I can also tell you this is acetaminophen 500 mg tablets box of 20.

This wil make sure that the receiver side can understand what was prescribed even if they don't know the code.
these cases are all in the "priouct definition / specification" and a flatter model, with one resource type, that can be profiled in the different concepts, works, and works better.
"

Jean Duteau (Sep 18 2020 at 15:27):

but I'll have concrete questions, as an example, one I had in the past "I have one route for my medication and it seems a bit obtuse to have these extra contained resources just to express the route".

Jose Costa Teixeira (Sep 18 2020 at 15:28):

Seems a bit obtuse to have 3 resource types to convey 4 attributes.

Rik Smithies (Sep 18 2020 at 15:33):

btw the XML has more than 4 attributes:
name, form, strength (fully structured), packaging, inner contents, quantity and identifiers
and was deliberately constructed to show the levels, not using much of each one.
If each was fully populated it would be dozens of attributes in 4 resources.

Jean Duteau (Sep 18 2020 at 15:35):

Jose Costa Teixeira said:

Seems a bit obtuse to have 3 resource types to convey 4 attributes.

Sure, but that is why I'm questioning whether your desire to use these resources for your use case is correct. I suspect that you would need to convey way more than 4 attributes for your specific use case - a national dictionary of drug definitions.

Rik Smithies (Sep 18 2020 at 15:37):

I was assuming there was more unmentioned, otherwise it would just be a code.

Rik Smithies (Sep 18 2020 at 15:43):

for a full set of drug definitions, with a 100 or so data items, virtual and actual products and packages instantiating them, its good to use a structure that lends itself to that. You could use Medication resource on its own, with Jose's 4 (or 40) extensions and a reference back to itself for 3 or 4 different linkage types. But I doubt that would cover it and be understandable.

Rik Smithies (Sep 18 2020 at 15:45):

Being able to differentiate products and packs is a key thing these models have (and IDMP too). It's good to have at least that structure I think.

Jose Costa Teixeira (Sep 18 2020 at 17:34):

Being able to differentiate "administrable products" and "medicinal products" is not a 80% thing, is it?

Jose Costa Teixeira (Sep 18 2020 at 17:35):

Jean Duteau said:

Jose Costa Teixeira said:

Seems a bit obtuse to have 3 resource types to convey 4 attributes.

Sure, but that is why I'm questioning whether your desire to use these resources for your use case is correct. I suspect that you would need to convey way more than 4 attributes for your specific use case - a national dictionary of drug definitions.

yes, the obtuse part is that the moment you need a new attribute, you must get a new resource type.

Jose Costa Teixeira (Sep 18 2020 at 17:36):

(btw, in my language obtuse is rather harsh, but I take your lead that it's a proper decent word :-) )

Rik Smithies (Sep 18 2020 at 18:15):

Drug route is key and is tracked by well over 80% of drug systems I would say. That is a feature of the administrable product.
If it turns out that it doesn't get used in a way that makes it need a standalone resource, we can get rid of it.
That is for us to find out.

Rik Smithies (Sep 18 2020 at 18:16):

I think there may be other attributes that get dropped when we get to ballot.

Rik Smithies (Sep 18 2020 at 18:19):

All drug products in the EU will be registered and tracked in a way that describes the administrable product though.

Rik Smithies (Sep 18 2020 at 18:20):

And when I say will, they are at the moment and will be soon in FHIR.

Jose Costa Teixeira (Sep 18 2020 at 22:08):

Rik Smithies said:

Drug route is key and is tracked by well over 80% of drug systems I would say.

I would say that too if anyone were discussing that.

That is a feature of the administrable product.

It is a feature of a medicinal product. Making it part of a dedicated resource called "administrable product" seems a convention (a design option).

If it turns out that it doesn't get used in a way that makes it need a standalone resource, we can get rid of it.

By "get rid of it" I assume you mean "get rid of the resource type" - that will be a good step.
My bet: If you ask regulators/MAHs, they are bound to IDMP, they will love a standard really matching their roadmap. If you ask MPDs providers, I don't think you will have a clear answer.

All I am asking is to entertain the alternative and support the variety we have out there - because that is much more known and certain that IDMP right now. For me the current approach is a misstep - which is arguable, and given the extensive work so far, I think it is best to move forward (I don't want to stop the train). But we should be aware it is one option, not the only thing that works.

Jose Costa Teixeira (Sep 20 2020 at 16:09):

Created J#28581: Reduce number of resource types for defining a product.
I think the example above is a perfect illustration of the unnecessary complication. We want to promote IDMP adoption, please consider this feedback.

Jose Costa Teixeira (Sep 24 2020 at 05:20):

@Hugh Glover @Rik Smithies every attempt triggers a lot of writing and negation, and I haven't received a suggestion to talk about it. My suggestion was not understood as I meant it. This is inefficient. And demotivating. Any suggestion? I'm sure we can converge, but it takes two to tango, and a room with music. What is your preference? Can we discuss feedback?

Rik Smithies (Sep 24 2020 at 07:29):

Hi Jose, we were having a very long discussion here, which was your chosen forum.
Now there is feedback about your Jira, on Jira. You can respond there, or here. I'm not sure what you are looking for?
You can call for BR&R call agenda time of course, if you have an item you wish to raise.

Jose Costa Teixeira (Sep 24 2020 at 07:44):

Let's try to keep this positive. What is the time slot we can have to discuss a few changes? I'm not sure Pharmacy has brought some feedback, but I have at least 2 Jira tickets to discuss.

Jose Costa Teixeira (Sep 24 2020 at 07:47):

@Hugh Glover

Jose Costa Teixeira (Oct 08 2020 at 11:58):

when is a good BRR call to continue the previous discussion? I think we had good steps and I don't want to lose that convergence. My proposals are not complicated nor inflexible, but information in writing is somewhat lost. It would be good to converge soon

Rik Smithies (Oct 08 2020 at 12:26):

hi Jose - you may want to have a look at recent evolution of the models. The need for multiple levels, for the simpler cases, has been largely resolved I believe. This may affect the applicability of your outstanding Jira. You use a single MedicinalProductDefinition resource for: identifiers, names, form, routes, legal status, classifications, ingredients, package type, cross references, manufacturer, description and other characteristics. I expect that will cover most of the simpler use cases, and it is also of course still possible to use the richer structures when required.

Jose Costa Teixeira (Oct 19 2020 at 11:22):

So when is a good time to join a call?

Last updated: Apr 12 2022 at 19:14 UTC