Current resources for defining a product split the attributes according to IDMP:

http://build.fhir.org/medicinalproductdefinition.html

http://build.fhir.org/administrableproductdefinition.html

http://build.fhir.org/packagedproductdefinition.html

This is forcing an attribute segmentation that is rarely used outside of the regulatory submission.

There are many places where a product needs to be defined, and an "administrable product" is not that conceptually completely different from a "medicinal product" or a "packaged product". One does not need to project the IDMP model and force the use of different resource types.

The current design convention is one of the possibilities to support IDMP, but it forces the same separation outside IDMP making the use of these resources unnecessarily complex outside of IDMP regulatory submission.

Note that IDMP regulatory submission does not yet have the maturity that product definition has in general. A more generic model (like medicationknowledge) could be sought but that would be a different discussion.

Proposal: these should be one resource type with the different attributes, using perhaps some generic properties like what is done in administrableproduct.property. This would start enabling to use this outside of IDMP regulatory submissions with much less complication.

The IDMP concepts should be standard profiles of these resources: one for Pharmaceutical Product, one for Medicinal Product, one for Packaged Product. That will keep the functionality exactly the same.

This proposal does not change the functionality. It does not even change the number of resources that need to be submitted in IDMP regulator yspace.

This proposal reduces the number of resource types that are needed for IDMP regulatory submission; It also reduces the number of resources AND resource types that are needed to cover the other use cases (outside IDMP). 

This proposal also approaches the model applied in MedicationKnowledge, making the continuum of master data sharing much more implementable.

Because this is not  a change in functionality. we cannot argue on use cases that are not supported. We can only evaluate the impact on implementers, and what is currently done out there today that we need to support.