Stream: committers
Topic: Product discussions ++
Jose Costa Teixeira (Aug 01 2020 at 06:43):
Methodologically, how do we fix the inconsistencies between our different resources that handle "product" and "product definition" and "product knowledge" and "product kind vs instances"?
Jose Costa Teixeira (Aug 01 2020 at 06:46):
We have a Product pattern, and we have several WGs that are working on this. I try to keep an eye and I notice inconsistencies, and I have some reservations about some parts, but I'm sure the committees will get this in order. Just as an example - I appreciate how Pharmacy MedicationKnowledge became more and more consistent (even if I disagree with the name and the initial scoping and design caused me some issues that I exposed - but we did work on it, and it got better)
Jose Costa Teixeira (Aug 01 2020 at 06:50):
I can handle keeping an eye on another discussion, and I'm happy we have many months before any of this goes normative (in my opinion this is still messy), but the issue seems like I had - I'm pointing my own flaws here:
When doing Catalogs, the resources did not support a graph-like structure that allows connecting medicationdefinitions to medicationdefinitions, to devicedefinitionss, to conditiondefinitions, etc. So we had a thing called CatalogEntry. I'm actually relieved CatalogEntry is on its way out, but how are we handling this?
Jose Costa Teixeira (Aug 01 2020 at 06:51):
in that case, the committe agreed with CatalogEntry and I think it was given a chance to prove its worth. Is that the way we'll iterate? (i.e. the committee agrees because things make sense at a given time, but then we can always go back and say "that was not our finest idea"?
Jose Costa Teixeira (Aug 01 2020 at 06:53):
I like that approach and I learned from it. But as we start looking at Catalogs and Inventory, we should have some consistency around handling the product concepts.
Jose Costa Teixeira (Aug 01 2020 at 06:57):
To be clear, the problem I've seen (mea culpa again) is that local consensus is easy - and easily diverges across WGs and across days of the week.
Rik Smithies (Aug 01 2020 at 09:38):
Hi José, it sounds like you have a general feeling of unease, and that is quite hard to address :-)
What are the inconsistencies you speak of?
A few issues that I am personally aware of (but I think these are acceptable because all proposed alternatives are worse):
Some resources can be both instances and types, e.g. Medication.
You can request one, you can dispense one, you can make a list and call it a formulary.
It could have a moodCode, but we don't want to go there.
In general instance vs type can be known from the context.
Systems don’t track it.
So in the end a problem in theory but not in practice.
Device vs DeviceDefinition. Here there is a clear distinction, instance vs type. But in fact both resources are virtually identical.
I would prefer them to be collapsed into one, and either allow the context to work itself out (probably) or have a "definition" flag (probably not).
MedicinalProductDefinition is a "detailed" version of Medication, and one that is only a type not an instance.
Maybe ideally Medication would have been a profile of it. But with (mostly) different usage communities, and practical issues around the vastly numerically more common use needing to be as simple as possible (Medication), what we have was agreed (very much across workgroups, and FMG) as the best - least worst - solution.
I don't see a need for CatalogueEntry because it seems better just to have a List of the actual resources, e.g. DeviceDefinitions, NutritionProducts for example.
Anything else - specifically - needs a fix?
At the end of the day the implementers are the ones who decide, less so the methodologists. If people take these resources and build working software, that is a good sign, and that is in fact the FHIR methodology.
Jose Costa Teixeira (Aug 01 2020 at 09:57):
Hi Rik. My question is where are these discussions taking place? I see you mention several points that we've discussed a few times.
Several years ago we started discussing "kind vs instance" and there was no specific place. Eventually OO took that and had been addressing Product discussions since.
My preferences are similar to yours, but even if we think alike, if we work in different silos we will eventually diverge. I am looking at catalogs and supply, and identification of products (not only IDMP but including it). You have the regulatory aspects in sight.
Jose Costa Teixeira (Aug 01 2020 at 10:00):
BTW, I agree with most of your details above but I disagree on others - but the point is - where should those discussions being handled? I would assume in 2 places: FHIR-IWorkflow has a Product pattern, would benefit from feedback. And we have a Product call on mondays.
Jose Costa Teixeira (Aug 01 2020 at 10:03):
and it's not a matter of not agreeing or disliking some designs:
I didn't like the design of the initial IDMP resources, but I appreciate how they evolved. Same with MedicationKnowledge.
I'd have made different mistakes - and most likely i'd have been wrong, hence my appreciation for common discussions.
Jose Costa Teixeira (Aug 01 2020 at 10:04):
4-5 years ago we did not see a need for "kind vs instance". Now we have it implemented differently.
Same with product catalogs and product definitions.
Jose Costa Teixeira (Aug 01 2020 at 10:07):
We've tried to put those under the Product discussions. That is the point - we can and should iterate freely, but how do we align internally? I'm assuming the existin discussions are an OK place, but I may be mistaken.
Jose Costa Teixeira (Aug 01 2020 at 10:17):
So it's about whether and how to discuss, not about particular issues.
And I suggest that everything that is Product-related (not the specifics like meds, or devices, or nutrition) continues to be discussed on the monday calls (and perhap a dedicated stream on Zulip?)
Rik Smithies (Aug 01 2020 at 13:06):
A lot of the conversations were held over the course of a year or so, at meetings of Pharmacy, BR&R, O&O, DSS and FMG.
Now we raise Jira tickets and discuss them on conference calls.
Those are the places. And we can and do continue to talk on here, of course.
If there are issues to discuss that are not getting the right audience why not suggest an agenda, with specific addressable items, for some joint workgroup calls?
"You have the regulatory aspects in sight".
That is a part of it, but the resources are "medication definition", and that includes identification, and the scope is not solely regulatory, but also pharmacopoeias etc., or any situation where you need to describe all the details of a medicinal products.
"IDMP resources"
There are no IDMP resources, only resources that have IDMP concepts in scope but are not limited to IDMP.
Rik Smithies (Aug 01 2020 at 13:50):
Cross product family issues at O&O seems a good fit, that is where we have discussed this before.
Jose Costa Teixeira (Aug 01 2020 at 14:02):
Let's continue in OO then. I will ask in the next Product call when to meet - that was my question - how do we collaborate more smoothly and frequently.
Lloyd McKenzie (Aug 01 2020 at 14:19):
From a governance perspective, if we think there's a general rule that should apply across design in multiple resources, MnM is the place that should happen. The FMG then vets the proposed rules from MnM and the proposed patterns from FHIR-I and decides how tightly to mandate them. Ideally we can detect variation with tooling that catches stuff in the build. The conversations and debates happen here on Zulip, via Jira, and at joint calls/meetings.
Jose Costa Teixeira (Aug 01 2020 at 14:54):
I will bring it up in a OO call to catch up with what's out there. I presume then that @Rik Smithies would wants / accept some of the resources in Medication definition to be added to that mix to that we can at least spot inconsistencies if any or learn from those resources.
I'm not too worried with the content, only with how easy it is to miss something important given all that's happening.
Maybe we have to revisit some resource scope proposals.
I understand that we can feed any info to MnM after discussing.
Jose Costa Teixeira (Aug 01 2020 at 14:56):
About governance still, I'd add one suggestion (i mentioned it before): As this gets more mature, we should look at design validation. Looking at our designs, prove they meet the use cases, and they don't add unnecessary risks, etc.
Rik Smithies (Aug 01 2020 at 15:12):
There are inconsistencies, and there are overarching things, such as how to make a list of products and what is an instance and what is a type. I think Jose you mean the latter, but Lloyd means the former - also important, but not what I thought the issue at hand was.
All the MedDef resources are of course in scope of any MnM rules, which we already try to keep up with e.g. the switch to all CodeableConcept, and preferring CodeableReference to a choice of code|reference. That isn't where we need O&O to decide perhaps, but all input welcome.
Jose Costa Teixeira (Aug 01 2020 at 15:23):
(if those resources want to be used also for devices, perhaps that diverges from the initial scope . I'm not worried with the types and minor inconsistencies. It's more: we start designing a car and separetly a bike. All that looks fine. 2 years later, the car designers say "we may abandon our requirement to not have 4 wheels". and the bikers go "we don't need to be engine-free". Especially when someone was trying to say "hey, what about motorcycles"? and now we have 2 of them - which is fun, but that motorcycles guy now has to spot the same things that would have been avoided).
Jose Costa Teixeira (Aug 01 2020 at 15:24):
Obviously, this is not a critique (and sorry Keith for the "motorcycle guy", it's obviously not you) but a challenge to see what can we do better
Lloyd McKenzie (Aug 01 2020 at 15:51):
Design validation is hard given that resources are supposed to be use-case agnostic. The best we can do is checking that the resources don't make common use-cases hard or impossible. And even then, not sure how you'd formally validate that. Historically, HL7 has relied on ballot review to identify issues/flaws/inconsistencies. If there are proposals for better/additional ways, certainly open to that.
Rik Smithies (Aug 01 2020 at 15:57):
@Jose Costa Teixeira devices in product packages has always been in scope and does not conflict with Device/DeviceDefinition.
Jose Costa Teixeira (Aug 01 2020 at 16:08):
I alread have an answer on the question on methodology, so, on that detail:
I'm looking for devices without relation to medication. Say a stent, or a catheter, or a pacemaker, or an infusion pump without any medication associated
Jose Costa Teixeira (Aug 01 2020 at 16:15):
Lloyd McKenzie said:
Design validation is hard given that resources are supposed to be use-case agnostic.
It's always hard, especially because all designs should not be too tight to a few specific use cases. And if /however we do it, it should be lean.
Jose Costa Teixeira (Aug 01 2020 at 16:21):
Perhaps
-
the devices in product packages should just clearly state that they are only to be used if there is a medication involved in that definition. (which I'd challenge, I'd want it broader)
or -
We say that we realise these resources can be used beyond their initial scope - and in which case I suggest the process should include an impact /scope check - and discussing with the OO group that works on that to see if that is still ok
Rik Smithies (Aug 01 2020 at 17:00):
I assume you mean for 1 that we need to decide if that is allowed or not and document it. I agree. It is allowed now by the model and always has been.
Some jurisdictions may want to treat devices as products, for consistency, so I don't see why not. It may appear to clash with the Device/DeviceDefinition resources, but I don't think so. Equally, I don't see that this would be very common.
For 2, you have your answer about methodology already.
Jose Costa Teixeira (Aug 01 2020 at 18:39):
TBD in the OO call
Jens Villadsen (Sep 03 2020 at 11:30):
@Rik Smithies would you happen to know if this link https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/substances-products-organisations-referentials-spor-spor-api-v2-specification_en.pdf is the closest thing there is to a IDMP FHIR IG?
Rik Smithies (Sep 03 2020 at 11:48):
yes it is. There is also the accompanying field by field "IG": https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/product-management-services-implementation-international-organization-standardization-iso-standards_en.pdf
Last updated: Apr 12 2022 at 19:14 UTC
