Stream: BRR - Pharmacy model
Topic: use of contained
Jens Villadsen (Jan 03 2022 at 23:45):
Having looked on the examples of http://hl7.org/fhir/5.0.0-snapshot1/medicinalproductdefinition.html I see a high degree of examples that uses contained almost as if it is the preferred way to refer to resources. May I encourage not to do so in all but eg. one example as searching within contained content is a pain.
Rik Smithies (Jan 04 2022 at 11:25):
This is really just because we had some specific cases recently that needed illustrating for ballot issues.
We want to add more examples.
If you have other examples, that illustrate different things, please contribute them.
Jose Costa Teixeira (Jan 04 2022 at 13:22):
Rik Smithies said:
This is really just because we had some specific cases recently that needed illustrating for ballot issues.
The example of VMPP ( e.g. "paracetamol 500 mg tablets box of 20" is a global, common requirement) requires several contained resources - which is really messy.
Jose Costa Teixeira (Jan 04 2022 at 13:26):
I agree with Jens's point
Jose Costa Teixeira (Jan 04 2022 at 13:27):
Just want to mention that the use of contained resources in BRR resources seems to be fundamental, not just a "specific case". The current design makes contained resources necessary
Jose Costa Teixeira (Jan 04 2022 at 13:27):
(And I see no requirement for that being so)
Jose Costa Teixeira (Jan 04 2022 at 13:27):
https://chat.fhir.org/#narrow/stream/179308-BRR--.20Pharmacy.20model/topic/Ingredient/near/214370708
Jose Costa Teixeira (Jan 04 2022 at 13:33):
I'd like it to be clear - at the time I was told that we'd use contained resources because that is the intended way.
Now I am reading that it is considered a specific case?
Rik Smithies (Jan 04 2022 at 14:36):
The full representation of a product, and its lifecycle, needs more than one resource. In some use cases that full representation is not needed, so it is possible to use the resources as contained - but you don't have to. A "one resource" model doesn't work for all use cases, and a multi-resource model does work, but is a little complex for some use cases. So we compromise on the model that works, knowing that it is not perfect for everyone.
Rik Smithies (Jan 04 2022 at 15:18):
If the question is "do I have to use contained resources with this product model?" then the answer is simply "no, you do not". If the question is, are the some circumstances where it makes sense to use contained resources, then the answer is yes. I think that is true of all sets of related FHIR resources.
We want all uses of this set of resources to be as consistent as possible. In some uses cases there is not enough data or workflow to make populating a standalone resource desirable, and a contained one is more convenient (and we can show examples of that, because they may be less obvious than some other cases). But it is always possible to use the standalone resources. The two solutions will both use the same resources and attributes, and so are consistent.
Jose Costa Teixeira (Jan 04 2022 at 16:21):
The question is: Do we have to use contained resources for something that is a common, global, legal requirement?
The answer seems to be - with this approach, yes.
Jose Costa Teixeira (Jan 04 2022 at 16:21):
The other question is: Could this be avoided for that use case, while maintaining the support for the others? The answer is - yes, if we simplified the resources.
Jose Costa Teixeira (Jan 04 2022 at 16:23):
The examples in the core spec should focus on the common use cases.
Jose Costa Teixeira (Jan 04 2022 at 16:23):
If for such a common use case our core spec example uses contained resources, then I'd say something is wrong - either the example or the resources.
Jose Costa Teixeira (Jan 04 2022 at 16:24):
(There are several places where we have contained resources in the examples, but in those cases we can see it's an editorial simplification, not a functional need)
Rik Smithies (Jan 04 2022 at 17:01):
As stated previously, you do not have to use contained, but it is an option.
We put contained in the examples for 2 reasons.
Firstly that use is not as obvious, so needed an example. When a case comes up that needs an example, we add an example.
Secondly we thought at one point that examples for a resource had to be of the type of that resource. That is a problem for a multi-resource examples. Only later did we realise that Bundles were allowed (though they can also obscure the use case somewhat). So some contained examples here are editorial, indeed.
The set of examples there is not fixed and doesn't reflect the frequency of any given scenario. The same is true of other resources. We don't add thousands of basic Patient examples and just one for a less common scenario. We try, eventually, to cover all the scenarios.
Rik Smithies (Jan 04 2022 at 17:12):
Re simplifying the model, we can only do that if it doesn't block the more complex common requirements and doesn't lead to inconsistent representation. We could simplify package representation by redundantly repeating the package name - your example - on the product. But then there are two places to put it. We know that some uses cases need a separate resource for packages (at least because of lifecycle issues, and because of the legal requirements you mention in fact - the ability to point at a package with an authorisation). The resource can be used contained if need be (but doesn't have to be), and that is consistent with the standalone resource pattern - using the same name attribute. This maintains the requirement for consistency, at the expense of some inconvenience in certain use cases.
Rik Smithies (Jan 04 2022 at 17:16):
The fact is that the richer solution works for the simpler but not vice versa.
And if the richer solution is necessary for the known current requirements, and is not just blue sky modelling, then that has to be chosen over the one that is too simple or is inconsistent.
Jose Costa Teixeira (Jan 04 2022 at 18:29):
Rik Smithies said:
Re simplifying the model, we can only do that if it doesn't block the more complex common requirements and doesn't lead to inconsistent representation.
Does that mean that BRR would entertain an opportunity to do that?
Jose Costa Teixeira (Jan 04 2022 at 18:31):
I think FHIR would benefit from a Package approach that is consistent with other resources that have the same requirement. From my perspective, a Packaging or ItemPackage or PackagedItem deserves its own resource type.
Jose Costa Teixeira (Jan 04 2022 at 18:34):
The rest of the simplification I'd propose is for better supporting IDMP especially in its necessary ambiguity and in supporting other requirements - I believe the example I mentioned is is a core DM+D concept, so it's pretty much universal.
Rik Smithies (Jan 04 2022 at 18:34):
I don't speak for BR&R but any workgroup will always look at new actionable proposals. You would have to bear in mind that many of these ideas have been discussed at great length already. I doubt there is an appetite to revisit ideas already covered unless there is significant new information.
Jose Costa Teixeira (Jan 04 2022 at 18:35):
Having an alternative was never discussed at lenght. "whether ould have an alternative" was argued against at length, but I never had 30 minutes to present such an alternative.
Jose Costa Teixeira (Jan 04 2022 at 18:36):
(at least my alternative, which was: stick to one MedicinalProductDefinition, make 3 core profiles, get rid of Ingredient)
Jose Costa Teixeira (Jan 04 2022 at 18:38):
"significant new information" - there's just more practical experience and more fundamented hestitation to use such complicated resources.
Jens Villadsen (Jan 04 2022 at 18:41):
@Rik Smithies my point is: If 5 out of the 8 examples heavily depend on contained resources, then you are also passing that message on by "illustrating/leading by example" - and that is probably not what you want to do. Especially not if you want the contained items to be searchable or leading to the actual resource. That was just my concern - but I don't know your use cases which may be valid reasons to make the examples the way you/others did them.
Rik Smithies (Jan 04 2022 at 19:03):
@Jose Costa Teixeira BR&R had 2 one hour sessions discussing your ideas and we stopped when there were no further new points being made. Please let us know specifics about the extra implementation experience you now have.
@Jens Villadsen agree that contained is over represented currently. Reasons are given above and it will be improved.
Jose Costa Teixeira (Jan 04 2022 at 19:05):
@Rik Smithies BRR had a long discussion about whether to discuss the ideas. There was never a substantial discussion, only arguing against entertaining changes
Rik Smithies (Jan 04 2022 at 19:06):
Best to take it up with the BR&R co-chairs Jose.
Jose Costa Teixeira (Jan 04 2022 at 19:06):
I had the chance to express my concern after waiting months for an opportunity to express the alternative, being told it was too early, and then immediately after being told that it was too late.
Jose Costa Teixeira (Jan 04 2022 at 19:08):
Rik Smithies said:
Best to take it up with the BR&R co-chairs Jose.
Right, that was the indication I had before, and that is what I did. I just I don't want to leave the impression that we did discuss an alternative. we didn't.
Jose Costa Teixeira (Jan 04 2022 at 19:09):
as for the new information, it is as I mentioned before - I said that using contained resources was difficult (e.g. because of search), and someone in the group said that that that was not true. It seems there was some merit.
Jose Costa Teixeira (Jan 04 2022 at 19:11):
I was clearly told that contained resources were the way to go.
Jose Costa Teixeira (Jan 04 2022 at 19:14):
so, suggestion is still the same:
- Get rid of Ingredient (which is a modeling artifact, there is no justification for that IMO - whether from drug DBs or from IDMP, or from implementers)
- Support more product concepts by sticking to a "MedicationProductDefinition" and create 3 core profiles. (IMO this would better reflect IDMP and can avoid so many contained attributes - the Paracetamol 500 mg is a good, symptomatic example of that: we need to contain several resources just for the purpose of borrowing data elements that actually belong together).
Jose Costa Teixeira (Jan 04 2022 at 19:16):
If we did that, we would be supporting IDMP much better by bringing IDMP (and other regulations/regulators) outside of the regulatory silo.
Jose Costa Teixeira (Jan 04 2022 at 19:18):
I hope the additional confirmation that "contained resources are evil" helps BRR reconsider.
Also the fact that some implementers consider these resources to be in need of simplification.
Jens Villadsen (Jan 04 2022 at 19:43):
in regards to: "contained resources are evil": It can be perfectly valid to use contained resources, but usually (99 out of a 100) it should be your very last resort and don't expect them to be searchable or used as reference or anything like that. In regards to "someone in the group said that that that was not true" - that someone should probably try to implement the technical details around it - then we can talk about what is considered difficult.
Jean Duteau (Jan 04 2022 at 19:49):
i really really really don't want to tread into this discussion, but I wanted to point out that I believe that many of the entity resources (Medication, Device, NutritionProduct, etc.) will get used as contained more often than not because implementers probably won't have actual resources on their system that they want to reference. i.e. if I'm sending a medication recipe, I probably won't actually create a Medication resource and then refer to it. In compounding pharmacies, I would expect resources to be created, but in "regular" pharmacies, I wouldn't. Thus I don't think "contained resources are evil" is a valid message.
Jens Villadsen (Jan 04 2022 at 19:51):
You could just as well then send a bundle of resources, right?
Jean Duteau (Jan 04 2022 at 19:55):
you could, but very often the Entity resource really doesn't have a life of its own. In the pharmacy systems I've been working with in Canada and the US, medications are either a code (no resource) or a recipe that doesn't have a life of its own, i.e. it is tied to the dispense, so there is never an actual Medication resource in the system's data store.
In that case, sending the contained resource as a resource in a bundle seems to me to imply it is a "real" resource.
Jose Costa Teixeira (Jan 04 2022 at 20:10):
@Jean Duteau I do think there's a valid case to use contained resources. Indeed, when sending a dispense of a medication, you may not have a resource in the server for each serialized medication. That is ok (and the medication resources was the example I consider valid because we don't want to contaminate the focus example, so a contained is fine).
Jose Costa Teixeira (Jan 04 2022 at 20:12):
The point that made me react is that it seems more pertinent that using contained resource to borrow attributes is not as solid as we discussed, and it was one of the arguments to not have that redesign.
Jose Costa Teixeira (Jan 05 2022 at 10:58):
I see this as another argument to reconsider the design (having to use contained resources to borrow attributes will not work easily - besides seeming conceptually awkward and functionally unnecessary).
Jose Costa Teixeira (Jan 05 2022 at 11:00):
But I feel this discussion is still not really welcome.
Jose Costa Teixeira (Jan 05 2022 at 11:03):
I see no functioning mechanism to promote discussion for eventual change.
Rik Smithies (Jan 05 2022 at 11:36):
Jose, there is no new information here, especially not about contained (some good opinions but no new facts), so I personally cannot see anything new to discuss. Repeated discussion of the same points is not helpful imho. We know what your proposals are, you have put them forward many times on here, on Jira (where there was lots of discussion), and had opportunity on two dedicated one hour calls. But raise it with co-chairs if you think you have a new point to make.
Here is my view on the options (taking the example of package name attribute):
a) just use the resource (PackagedProductDefinition)
b) use it contained
c) move the attribute to the other resource - but, although good for your case, it is incompatible with many applications
d) clone the attribute to the other resource - but this breaks consistency
e) replace all the resources with a profile of one of them - see option c)
a and b are the only viable options, and no one is forced to use b.
c, d and e don't work so don't get out of the gate.
As for e), FHIR is firstly a resource oriented system not a profile oriented one. We don't use profiles to create first class domain concepts. If we did then there would be a Participant resource profiled into Patient and Practitioner, because they share a lot of attributes. But since they are well known to be distinct concepts in the domain (and this is not the RIM) we have two resources and not two profiles.
The only question then is if products and packages are distinct concepts, and the answer, based on various models (including your own example of dm+d) and practical current implementer experience, is, in the main, yes.
Jose Costa Teixeira (Jan 05 2022 at 12:10):
Rik Smithies said:
Jose, there is no new information here, especially not about contained (some good opinions but no new facts), so I personally cannot see anything new to discuss.
One of the reasons that an alternative was dismissed was because someone asserted, against my opinion, that search on contained resources was not an issue. I see confirmation that such an fundamental assertion was not solid, based on this additional insight.
As for the discussion - I think this thread confirms the point - a simple proposal - get rid of ingredient, keep package, combine other resources into 1, and make profiles, which would simplfiy other medication concepts and still guarantee that core IDMP concepts are supported.
Jose Costa Teixeira (Jan 05 2022 at 12:19):
So,
-
It seems that some of our starting assumptions/assertions are fragile - technically it won't work well. Up to you and BRR to acknowledge that or not.
-
An alternative was proposed and I was looking at finding middle ground, which there was no chance.
-
You say "it won't work" - that is not an inviting argument, especially after things do work.
-
There is not a lot of independent implementer experience on these resources. There is vast implementer experience on alternative ways to represent it - it just seems that you don't want to consider that experience.
-
There seems to be some confusion between distinct resources and distinct resource types. the DM+D proves that the current resources are a mess.
I just wanted to set that straight. From this thread, it seems that as soon as I propose "perhaps let's discuss" you say "nothing new here".
It's almost as Iif I just came here for an argument...
Jose Costa Teixeira (Jan 05 2022 at 12:22):
I hope it's clear that these 2 issues are still blocking the use of those resources anywhere outside new IDMP-dedicated databases. It's a pity that we have such a silo.
Rik Smithies (Jan 05 2022 at 12:35):
I will say again Jose, please bring your new proposals - and especially the implementation feedback that you mention - to BR&R co-chairs.
Jose Costa Teixeira (Jan 05 2022 at 12:41):
I did. What I am saying is that the proposal is still the same, the ball is in the BRR court (and you) that rejected a discussion. Any chance things would be different now that you got this additional feedback?
Rik Smithies (Jan 05 2022 at 12:45):
Is it the same or is there additional feedback? When you had the chance to talk to BR&R at the two specially convened calls, your arguments were not persuasive. If you didn't manage to make your case in that time, I am not sure what else can be done, unless the case is now different. But please give us your implementers' feedback.
Rik Smithies (Jan 05 2022 at 13:16):
I would especially like to hear your dm+d implementation feedback. When I implemented this a couple of years ago for a client (and showed part of it later at a Connectathon), I did have some problems. These were raised as Jiras and brought into the current model. So it would be great if your implementers can raise some Jiras.
Jose Costa Teixeira (Jan 05 2022 at 14:15):
Rik Smithies said:
When you had the chance to talk to BR&R at the two specially convened calls, your arguments were not persuasive.
I don't like this confusion. You should not say the arguments were not persuasive. You said that it was not persuasive to engage in such a change because things were fine (for example that search in contained resources was fine).
Jose Costa Teixeira (Jan 05 2022 at 14:20):
Please consider that dm+d implementation is unnecessarily complicated (the example in the core spec is clear enough - why would we ever need 3+ resources to convey what is a very common, legal need?). Unlike we were told before, contained is not a good option because we need to search on those.
Jose Costa Teixeira (Jan 05 2022 at 14:20):
I'd love to have a substantial discussion on alternatives because it is only 2 simple changes.
Rik Smithies (Jan 05 2022 at 14:43):
May I suggest that you bring any new proposals and implementation experience to BR&R co-chairs?
Jose Costa Teixeira (Jan 05 2022 at 16:37):
@Hugh Glover @Jean Duteau here it is:
Process-wise: The starting assertion that contained resources were harmless seems not really solid.
There are arguments ready, but we stopped at "why should we discuss this". "bring the proposals" and "why bringing proposals? they won't work".
Content-wise:
I need something that can contain IDMP and non-IDMP definitions of medication. Current resource types are complicated. The VMPP (Acetaminophen) example shows how messy simple, common things can get.
I don't have a magic formula except - getting people around a table. Starting proposal is simple:
- Get rid of Ingredient
-
Collapse AdministrableProdDef with MedicinalProductDef and the "clinical" bit of PackagedProduct
-
because it's Christmas - check the overlaps between PackagedProduct and ManufacturedItem, create a ProductPackage that can be reused - not a PackagedProduct, but a ProductPackage
Rik Smithies (Jan 05 2022 at 16:45):
@Jose Costa Teixeira Just to say that every single one of those have recently been extensively discussed on ballot reconciliation and voted on
Jose Costa Teixeira (Jan 05 2022 at 16:45):
Right. I wasn't there - see above.
Jean Duteau (Jan 05 2022 at 17:03):
BTW, I'm not a BR&R co-chair, so I didn't need to be @ed. :). I'm comfortably using the resources as they exist in the latest R4B snapshot for my SPL project, so I'm good.
Jose Costa Teixeira (Jan 05 2022 at 17:04):
I thought you were a co-chair, sorry for that
Jose Costa Teixeira (Jan 13 2022 at 10:00):
(It's been a while. I don't know if I should expect any response from co-chairs this time)
Last updated: Apr 12 2022 at 19:14 UTC
