AdministrableProductDefinition.identifier

[rlindstrm]

AdministrableProductDefinition.identifier is mandatory. I am not sure it can be expected to exist, and I suggest leaving it optional.

Two loosely related thoughts, that are less relevant:

1. As the resource refers to the administrable form of this specific product, .identifier should not contain PhPID. I think an extension might be needed for referencing relevant PhPIDs, but we don't have PhPIDs yet, so this is not urgent.

2. Right now, there is nothing that would force the AdministrableProductDefinition be linked to a medicinal product. formOf and producedFrom, that could be the link, are both optional. It might make sense to have a validation rule to make sure at least one of them is filled in.

[cander2]

Regarding identifier, from an industry perspective there would always be one. But don't mind setting back to optional to allow flexibility.

Profile updated.

Regarding #1, why would we need an extension for PhPID? This is where we have been putting them in the past few connectathons.

Regarding #2, yes, we'll have to rely on validation for things like this. I would prefer making it required but I think we need to leave it optional since most markets only focus on the MID. Will of course advocate for the inclusion of APD for anyone who adopts Type 2 ePIs but for now we're not there.

Let me know if you see a path for making it required though. I'd happily change if we can make it happen across markets.

[joofio]

We can add a constraint in gravitate to “upgrade” from the base specification Craig Anderson ***@***.***> escreveu em ter., 5/12/2023 às 19:40 :

…

Regarding identifier, from an industry perspective there would always be one. But don't mind setting back to optional to allow flexibility. Profile updated. Regarding #1 <#1>, why would we need an extension for PhPID? This is where we have been putting them in the past few connectathons. Regarding #2 <#2>, yes, we'll have to rely on validation for things like this. I would prefer making it required but I think we need to leave it optional since most markets only focus on the MID. Will of course advocate for the inclusion of APD for anyone who adopts Type 2 ePIs but for now we're not there. Let me know if you see a path for making it required though. I'd happily change if we can make it happen across markets. — Reply to this email directly, view it on GitHub <#94 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMJVUHT56KEZVA5ZOMR2HDYH52EBAVCNFSM6AAAAAA7PUTEFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGUYDCNZRGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rlindstrm]

Regarding the first issue.
AdministrableProductDefinition inside ePI does not define or describe the generalisation that the PhPID stands for. APD inside ePI describes the administrable version of that specific product.

Identifier should always be the identifier of the entity this particular resource describes - so if we have a register of PhPIDs, each of those would be associated with one APD resource and the identifier would be PhPID.
But if we want to say that the administrable version of this product is classified as PhPID xxxxxxx, we should use .classification or something else like that. This data element is currently not available, but nor are PhPIDs, so I think it's not an urgent change for real life use cases.

Here is an overly long thread about it.

[cander2]

Ah yes, PhPID is not the branded drug and ePI is branded so we would need an identifier and a PhPID.

But would you still agree that the PhPID goes in the APD?

[rlindstrm]

Yes, I agree. :)
It just cannot be in the identifier element. And there's no other element for it in the base spec at the moment.