Scope of IDMP entities (global vs local)

[Censacrof]

My understanding is that some of the entities defined by IDMP have global validity, while others only local. By that I mean that some entities's instances can be created once, and then referenced by others instead of being recreated.

For example:

• We have a global PharmaceuticalProduct for "Amplodipine 25mg capsule"
• We have many local MedicinalProducts, that are valid only in the country in which they were created, that will point to that same PharmaceuticalProduct

Today I had a meeting with @costateixeira in which he told me that this approach is something that needs to be discussed because not everyone is happy with it. If I understood correctly there are countries that would like to redefine their own "Amlodipine 25mg capsule".

From a technical point of view, I think that having global and local entities makes more sense, for a number of reasons:

1. Data is not duplicated
2. Single source of truth
3. It makes it possible to have a distributed database without having to implement a synchronization mechanism between the central node and the other nodes (they only need to reference data in the central one)
4. Authorization policies will be easier to implement
5. It will be easier to search all MedicinalProducts that have the same PharmaceuticalProduct, even in absence of PhPId (we could just use generated Ids)

We used this approach while implementing the T6.1 IDMP database, we need to understand if and which problems could arise because of that.

[rlindstrm]

According to ISO IDMP and EMA's implementation of it, Pharmaceutical Product includes information about excipients as well. In EMAs and NCAs' databases, the Ph Product would not be "Amlodipine 25mg capsule", but "Amlodipine 25mg + n other ingredients capsule". And almost each brand has a slightly different set of excipients, so the chances of a Ph Prod instance being meaningfully global or globally meaningful are very slim. As far as product definition goes, Ph Prod is de facto inseparable from Med Prod.

However, PhPID creation only takes into account the active ingredients. That would really be something that refers to "Amlodipine 25mg capsule".

Therefore, following EMA's implementation guide, you would need to have a lot of different pharmaceutical/administrable products per one PhPID. See the examples of full representation.

I can't say I'm awfully happy with it, but I hope this explains where this individualistic approach comes from.

[Censacrof]

According to ISO IDMP and EMA's implementation of it, Pharmaceutical Product includes information about excipients as well. In EMAs and NCAs' databases, the Ph Product would not be "Amlodipine 25mg capsule", but "Amlodipine 25mg + n other ingredients capsule". And almost each brand has a slightly different set of excipients, so the chances of a Ph Prod instance being meaningfully global or globally meaningful are very slim. As far as product definition goes, Ph Prod is de facto inseparable from Med Prod.

However, PhPID creation only takes into account the active ingredients. That would really be something that refers to "Amlodipine 25mg capsule".

Therefore, following EMA's implementation guide, you would need to have a lot of different pharmaceutical/administrable products per one PhPID. See the examples of full representation.

I can't say I'm awfully happy with it, but I hope this explains where this individualistic approach comes from.

Thank you for the great input. Today @costateixeira also told me that, contrary to the T6.1 data model, PharmaceuticalProduct can have a different set of Ingredients than the union of the ingredients of the ManufacturedItems. Of course we will need to adjust for that. When you say that each country has a different set of excipients, do you mean the excipients of the PharmaceuticalProduct or the ones of the ManufacturedItems? (or both)

[rlindstrm]

Each Medicinal Product probably has a different set of excipients. If the exact medicinal product is shared between countries, the pharmaceutical product would have the same data, too, but sharing the Ph Prod would not give any extra value in such cases as the MPID would already be the same. Also, if these countries have issued their own marketing authorisations, then changes in the product would be handled at different times, so there would always be a need for creating a local pharm prod entity. Different brands would probably always have different excipients, even if the active ingredients and strengths are the same - but this is the use case where you would like to look at the Pharm Prod level to determine if the products are generically the same.

ManufacturedItem and PharmaceuticalProduct can also have different ingredients. This one you can kind of see on the link I gave before (See the examples of full representation. For the tablet, the ingredients (incl strengths) are shared, for the combination product (powder and solvent for solution), there are different manufactured items (powder and solvent), and the pharmaceutical product is the combination of both (solution, combining ingredients from both). As the dose form and unit of presentation changes, the strengths of Ingredients change a little bit.

For this product, the change is not very big, but if you think of a soluble powder or an effervescent tablet, you can easily imagine that the strength cannot be the same for something solid and something liquid. It is not entirely clear if solvents not included in the package, like distilled water, saline or water, should be included in the ingredients or not. I don't think we've done it (quite often there are no clear rules how much water to use for solution anyway), but strictly speaking any solvent would be an ingredient for the pharmaceutical/administrable product.

I don't think I know all the traps in this logic. But it's not at all as clean and clear as you'd logically expect it to be. I believed for a long time that 1 PhPID = 1 Pharmaceutical Product, but looks like real life provides quite a lot of extra noise here. :)

[Censacrof]

@rlindstrm Once again, thank you for this great discussion. I can tell you that I also believed (and we are not the only ones) that 1 PhPID = 1 Pharmaceutical Product. Sorry if I don't answer right away but I'm out of office until wednesday and I need some time to understand everything you said.

Thank you again!

[rlindstrm]

There are other interesting topics that could be titled "Scope of IDMP entities", but they cause problems already within one implementation. For example, the reusability of manufactured item (I will add an issue about that very soon, as this is handled differently in different FHIR versions, and we just had this discussion in WP4), and the reusability of ingredients (when to share it between products, when not to).

[Censacrof]

Oh, I see. I think we really need to find an answer to this kind of issues, they are very important. So far, for the T6.1, we worked with FHIR R5.0.00-snapshot1 and we made so that ManufacturedItems and Ingredients are not reusable.

First of all, we need to focus on IDMP first, and on FHIR second. This is because, at the end of the day, our goal is to store and convey IDMP data. FHIR is just a way of communicating this data, and it's not the only one. We should first ask ourselves: what does IDMP say about the reusability of ManufacturedItems and Ingredients? Whatever the answer, we can accomodate for that in FHIR.

This is the approach that we used so far for the T6.1: we started by creating an IDMP database (not perfect yet), and then, using the HAPI FHIR library, we made a FHIR server capable of fetching data from that database and serving it through FHIR resources (according to the ema IG).

Now we know that the ema IG is flawed and that we made wrong assumptions about how IDMP works. We need to focus on working out these obscure / unclear aspects of IDMP in order to make the IDMP database "perfect", then it will be easy to do the FHIR stuff.

[costateixeira]

Note that IDMP has gaps and inconsistencies itself and there are several aspects where it deliberately does not make any statements. If I am not mistaken, the reusability of certain products is one area where IDMP is silent. This is the kind of discussion and insight that is good for the project and its impact.

It will be great to capture Rutt's expertise on the actual details, rules and exceptions. I would like to see requirements/assumptions in our common specifications (assuming they apply for FHIR and non-FHIR implementations)

On Tue, 1 Nov 2022, 18:49 Francesco Galisi, @.***> wrote:

Oh, I see. I think we really need to find an answer to this kind of issues, they are very important. So far, for the T6.1, we worked with FHIR R5.0.00-snapshot1 and we made so that ManufacturedItems and Ingredients are not reusable.

First of all, we need to focus on IDMP first, and on FHIR second. This is because, at the end of the day, our goal is to store and convey IDMP data. FHIR is just a way of communicating this data, and it's not the only one. We should first ask ourselves: what does IDMP say about the reusability of ManufacturedItems and Ingredients? Whatever the answer, we can accomodate for that in FHIR.

This is the approach that we used so far for the T6.1: we started by creating an IDMP database (not perfect yet), and then, using the HAPI FHIR library, we made a FHIR server capable of fetching data from that database and serving it through FHIR resources (according to the ema IG).

Now we know that the ema IG is flawed and that we made wrong assumptions about how IDMP works. We need to focus on working out these obscure / unclear aspects of IDMP in order to make the IDMP database "perfect", then it will be easy to do the FHIR stuff.

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/27#issuecomment-1298892927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUFFEJHKDZWKTEMVEILWGFJ2JANCNFSM6AAAAAARRDXOPE . You are receiving this because you were mentioned.Message ID: @.***>

[rlindstrm]

Covered in UNICOM IG Known Issues section and in DW deliverable.