Stream: BRR - Pharmacy model
Topic: Alternative MedicinalProduct definition resources
Jose Costa Teixeira (Nov 09 2020 at 08:27):
I think we can use this stream for the discussion about streamlining the resources we have, as a possible alternative to the resources that are drafted now. Depending on the feedback, we can find other methods but I presume we can start here.
Jose Costa Teixeira (Nov 09 2020 at 08:28):
This is an exploration of an alternative which I think is needed. I'd like the resources to be supporting IDMP but other models, and not only regulatory aspects but also clinical (prescribing and monitoring)
Jose Costa Teixeira (Nov 09 2020 at 08:34):
Some starting topics I'm working on:
- Fusion of the MedicinalProductDefinition, AdministrableProductDefinition and PackagedProductDefinition resources. There's some overlap of attributes.
Jose Costa Teixeira (Nov 09 2020 at 08:36):
Practical impact of this fusion to IDMP implementers: none - each IDMP concepts (PhP, MP, PP) is simply a profile of this resource type.
Practical impact of this fusion to other implementers that already exist (SNOMED, the many national concepts, others) - It allows to also profile such concepts, without a lot of extensions or contained resources.
Rik Smithies (Nov 09 2020 at 10:52):
hi Jose, some feedback:
Firstly, the proposal you mention here is already a subject of a Jira you have raised (perhaps you can add a link to it for us). There are some specific and significant comments on there that may help guide us.
Secondly you are saying that there are no practical impacts to what you are suggesting.
I believe the impacts are wholly practical.
They are practical in the sense of no conceptual difference but actual difference in the experience of use.
Using distinct resources vs having to create the same concepts by profiling is exactly a practical issue.
It may not be a logical or conceptual one, but it is a practical one. The model you create will be equivalent, but more abstract and will need practical work to tailor it for each use case.
Of course there is a continuum of ways to model this, from one extreme to the other. You can do it like the Common Product Model and the RIM. Or you can do it like most of FHIR where common domain concepts have their own resources (e.g. Condition, Observation, Procedure - those have a lot in common but we don't expect people to profile them from an abstract concept before using them).
I believe what we have is a good compromise that fits what implementers (regulatory and otherwise) tell us they need. No other set of resources in FHIR insists on using profiles to support the basic use cases found in the domain (though further resource specific profiling is always sensible).
For example the stakeholders I'm in touch with, and some common industry models, do want a clear distinction between product and pack at resource level, so there will be some push back on removing the package resource that implementers are currently using.
Thirdly, for the work proposed, rather than suggesting the solution first, I would suggest stating the requirements and aims first, then looking for a solution that addresses it. Otherwise it is not clear what is trying to be achieved. Changing (or proposing an alternative to) the current models is not a goal in its own right - it’s a solution to some issue. Let’s articulate what that issue is.
Jose Costa Teixeira (Nov 09 2020 at 10:56):
@Rik Smithies I'd like to have a topic that is focused on the changes and ideas. For meta-discussions we can open a parallen discussion. I want this to be a clean discussion if possible. Here we can comment on the changes.
Rik Smithies (Nov 09 2020 at 11:05):
3 points directly about the changes:
- We have existing comments on the exact changes proposed, we need to consider those
- The changes proposed have practical impacts that we must consider in the evaluation
- We need to have a rationale for the changes to be able to evaluate the changes
Jose Costa Teixeira (Nov 09 2020 at 11:05):
If this is about "what to change" - here is a good place. If this is about "whether/how", not here please
Jose Costa Teixeira (Nov 09 2020 at 11:07):
So back on topic: I'm thinking of drafting a single resource that would be a MedicinalProductDefinition that includes the non-duplicate attributes from the AdministrableProduct and the PackagedProductDefinition
Jose Costa Teixeira (Nov 09 2020 at 11:08):
Except the "Package" part in PackagedProductDefinition - that would perhaps be better as a separate resource
Rik Smithies (Nov 09 2020 at 11:09):
okay - please let us know what problem that solves, so that we can know if you have solved it better than the existing solution
Jose Costa Teixeira (Nov 09 2020 at 11:09):
It will be in the design after the resources are drafted.
Rik Smithies (Nov 09 2020 at 11:10):
It's hard to comment at this point then, if we don't know what you are trying to achieve
Jose Costa Teixeira (Nov 09 2020 at 11:11):
You don't need to comment yet, please let us work towards an alternative and then we compare
Jose Costa Teixeira (Nov 09 2020 at 11:14):
So, again on the key initial ideas, here's my expected target:
- Merge the xxxDefinition resources - saving duplicate files while still allowing for profiles to provide the same functionality.
- Package would be its own resource
Jose Costa Teixeira (Nov 09 2020 at 11:15):
some questions
- Does a Package point to a Product or a Product point to a package? I think it is a Package that points to a Product, but I'd hope for feedback
Jose Costa Teixeira (Nov 09 2020 at 11:18):
- in AdministrableProductDefinition.routeOfAdministration - when merging, should that rather be of Dosage datatype, instead of a backbone element with all the attributes?
Rik Smithies (Nov 09 2020 at 11:20):
#1 A product has packages, that it the logical direction. But there is the possibility to represent this logical link in two physical directions. "product has a (child) package" and "package has a (parent) product". The packages come and go more often, so there is a rationale to allow them to reference the product rather than the other way around. Compare to Patients having encounters, but the physical link goes the other way, because you don't want to update Patient continually. Both physical directions of product to pack are possible currently, but there is only one direction conceptually.
Rik Smithies (Nov 09 2020 at 11:21):
#2 this is already merged. Route is not a dosage.
Jose Costa Teixeira (Nov 09 2020 at 11:35):
#1 Yes, I think Package resource would point to the Product - this would go well with other products that have a package
Jose Costa Teixeira (Nov 09 2020 at 11:36):
#2 the Dosage data type has some (most?) of the attributes of what is called "routeOfAdministration". I think there's potential for reuse
Rik Smithies (Nov 09 2020 at 11:38):
You may need to define what you see as route of administration. When I have seen it it is usually just a code for a route. e.g. oral, intravenous, etc. CodeableConcept has the necessary attributes for the use cases I am familiar with.
Jose Costa Teixeira (Nov 09 2020 at 11:43):
what the current resource defines as ".routeOfAdministration" looks a lot like a Dosage which includes the route of administration
http://hl7.org/fhir/dosage.html#Dosage
Rik Smithies (Nov 09 2020 at 11:45):
ah you mean the backbone itself. Yes some of those could be done using Dosage, but it would be overkill and less convenient. A quantity is already a reusable datatype.
Jose Costa Teixeira (Nov 09 2020 at 11:48):
Why "overkill and less convenient"? We'd reduce the number of elements
Rik Smithies (Nov 09 2020 at 11:49):
it would need multiple Dosages, and a way to tell them apart. Reducing the number of elements is not a design goal in itself.
Rik Smithies (Nov 09 2020 at 11:51):
The most convenient thing is when you have the exact named concept you need and the exact datatype for it. Other more general solutions are less convenient, but if wider uses cases are needed, they may be preferable. It's a balance. If there are no other use cases then there is no need to change it.
Jose Costa Teixeira (Nov 09 2020 at 11:52):
Let me make a proposal about that. I retain the requirement - there need to be multiple dosages/routes.
Jose Costa Teixeira (Nov 09 2020 at 11:52):
I will try to use Dosage in the merged resource.
Jose Costa Teixeira (Nov 09 2020 at 11:53):
I'll ping back once I have any idea what to do with Species there.
Last updated: Apr 12 2022 at 19:14 UTC
