FHIR Chat · How to just express the ingredients of a product? · BRR

Stream: BRR - Pharmacy model

Topic: How to just express the ingredients of a product?

Jean Duteau (Sep 06 2019 at 17:21):

I'm trying to use MedicinalProductDefinition to define the marketing, authorization and ingredients of a product. It is a single part product. It appears that I have to specify the following attributes and use the following chain of resources to express this:
MedicinalProductDefinition
-combinedPharmaceuticalDoseForm (put the form here?)
-packagedMedicinalProduct => PackagedProductDefinition

PackagedProductDefinition
-packageItem
--type (mandatory)
--quantity (mandatory) (put 1 because this is a 'top-level' packaging?)
--manufacturedItem => ManufacturedItemDefinition

ManufacturedItemDefinition
-manufacturedDoseForm (mandatory, so put the form here as well?)
-quantity (mandatory)
-ingredient => Ingredient

That seems slightly convoluted, but I can work with that except for the mandatory elements I can default the quantities to 1, but I don't have a packaging type. Maybe we want to reduce the cardinalities of these attributes?

Rik Smithies (Sep 06 2019 at 18:50):

This is really good feedback Jean.

A current idea is to collapse ManufacturedItemDefinition into PackagedProductDefinition, so that will simplify a little. There are cases where the same manufactured item is in different packages, which would no longer be possible, but its a trade off - some redundancy for a simpler model.

Yes the form goes there.

But I wonder if we might want to allow an Ingredient ref direct from Medicinal Product Def, for cases where you don't care about packaging? That might be more convenient for simpler cases.

Jean Duteau (Sep 06 2019 at 18:54):

A current idea is to collapse ManufacturedItemDefinition into PackagedProductDefinition, so that will simplify a little. There are cases where the same manufactured item is in different packages, which would no longer be possible, but its a trade off - some redundancy for a simpler model.

Strangely enough, I just made another tracker item because I had another product where I wanted to express that very same thing - four different package configurations of the same manufactured item.

Rik Smithies (Sep 06 2019 at 19:07):

But you can do that now cant you? They are different resources so different packages can reference the same manufactured item

Jean Duteau (Sep 06 2019 at 19:07):

Yep, you can do that now. But the quantity is in the wrong spot. The quantity on ManufacturedItem should be up in the PackagedItem.

Rik Smithies (Sep 06 2019 at 19:15):

Right. I've always found IDMP a bit strange there. There should be no need for things to count themselves, and no need for 3 different items. But you do need two resources (not collapsed) to represent this I think.

Jean Duteau (Sep 06 2019 at 19:18):

Yes, I got it to work for now by using an extension, i.e. effectively moving the quantity up a level. It looks like this:
MedicinalProductDefinition
PackagedProductDefinition_1
-packageItem
--manufacturedItem
---quantity 100
---ManufacturedItem_1
PackagedProductDefinition_2
-packageItem
--manufacturedItem
---quantity 30
---ManufacturedItem_1
PackagedProductDefinition_3
-packageItem
--manufacturedItem
---quantity 60
---ManufacturedItem_1
ManufacturedItem
-ingredient_1
-ingredient_2
...

Rik Smithies (Sep 06 2019 at 19:19):

The packs will differ more than just in the number of tablets (as your view shows). So you cant just have one pack with several collections of items. Bottles may be physically different, or one pack may be a carton. And you may need an overall product to group them. So this does call for the 3 levels we have now I guess. Also this I'd the other end of the scale from your other use case? (Where you want to skip levels).

Rik Smithies (Sep 06 2019 at 19:22):

Prob needs a backbone element adding to pack, of item reference and item count.

Jean Duteau (Sep 06 2019 at 19:23):

I'm okay with having to include the levels, but it's just we need to be careful about making things mandatory.

Rik Smithies (Sep 06 2019 at 19:33):

lets get our use cases separate - you seem to have 2. #1 is a product with just ingredients. #2 is packs with items

Rik Smithies (Sep 06 2019 at 19:35):

#2 needs the levels. #1 could have the levels for consistency. But some will only have #1, so dont want to worry about levels. That could work by jumping straight to Ingredient. Then we also don't need to make the mandatory pack type optional, we just bypass it.

Jean Duteau (Sep 06 2019 at 19:36):

Sure.

Jean Duteau (Sep 06 2019 at 19:36):

I think you could keep #1 for consistency. After I did #2, I saw how #1 made sense.

Rik Smithies (Sep 06 2019 at 19:40):

are you against providing a short circuit to ingredient for cases when no one cares about packs or items? It's not ideal to have 2 ways, but systems do differ in levels of representation.

Jean Duteau (Sep 06 2019 at 19:42):

i'm not against it. I do like the consistency, but it is a lot of indirection when you don't care about packs or items. Maybe #1 should have been represented with an AdministrableProductDefinition? That has the ingredients without the packs or items.

Rik Smithies (Sep 06 2019 at 19:43):

yes I also thought that. But then you have a mix of top level resources, for different levels of detail, which I don't like. And people won't figure that out. It doesn't seem too bad to have 3 levels but make 2 of them optional.