Stream: Orders and Observation WG
Topic: Healthcare product related resources block vote
Hans Buitendijk (Jan 10 2020 at 20:30):
Early December a block vote went out for the following items. Due to meeting attendance and holidays we were not quite able to close this out and will have a final target of January 16, 1-2pm ET during the OO conference call to wrap this up.
If you do want any pulled, please let me know by noon that day if by e-mail, zulip message or at the start of the vote in person.
• DeviceRequest
o FHIR-25258 - No quantity on DeviceRequest – @Jean Duteau
o FHIR-20945 - Remove DeviceRequest in favor of SupplyRequest – @Jose Costa Teixeira
o FHIR-20604 - highlight that intent is an immutable element. – @Eric Haas
o FHIR-20601 - Consider adding "doNotPerform" to support “NotDone is true” expression in the quality measures – @Yanyan Hu
o FHIR-19631 - Complete workflow alignment pattern for OO resources in R5t – @Eric Haas
o FHIR-19563 - STU3 DeviceRequest base profile defines incorrect ValueSet reference for intent element binding - @Richard Ettema
o FHIR-15865 - DeviceRequest.supportingInfo definition is wrong – @Lloyd McKenzie
• Substance
o FHIR-16488 - generic extension "purchaseDate" for Device, Substance, Medication etc. – @Simone Heckmann
• BiologicallyDerivedProduct
o FHIR-20560 - Add optional UDI-DI and 'distinct identification' for BiologicallyDerivedProduct regulated as medical devices – @Ioana Singureanu
o FHIR-16063 - Change cardinality of BiologicallyDerivedProduct.manipulation – @Robinette Renner
• SupplyRequest
o FHIR-20942 - Remove Substance as Device.itemReference choice – @Hans Buitendijk
o FHIR-20941 - Add DeviceDefinition to SupplyRequest – @Hans Buitendijk
o FHIR -20604 - highlight that intent is an immutable element. – @Eric Haas
o FHIR-19631 - Complete workflow alignment pattern for OO resources in R5t – @Eric Haas
• SupplyDelivery
o FHIR-19631 - Complete workflow alignment pattern for OO resources in R5t – @Eric Haas
o FHIR-15922 - Include DeviceRequest for SupplyDelivery.basedOn – @Rick Geimer
• DeviceUseStatement
o FHIR-24680 - Reference from DeviceUseStatement to BodyStructure – @Nick Radov
o FHIR-20913 - Add a way within DeviceUseStatement to say "does not have this type of device" – @Alexander Henket
o FHIR-20601 - Consider adding "doNotPerform" to support "NotDone is true" expression in the quality measures – @Yanyan Hu
o FHIR-19631 - Complete workflow alignment pattern for OO resources in R5t – @Eric Haas
o FHIR-14142 - Harmonize DeviceUseStatement with MedicationStatement – @François Macary
Hans Buitendijk (Aug 27 2020 at 15:34):
The following block vote for OO owned healthcare product related resources is ready and will be voted on next week Thursday, September 3, 2020, during the regular OO conference call (1-2pm ET). Let me know if you wish to pull a JIRA that requires further substantive discussion. If it is a minor tweak/clarification then we can still keep it in. Note that we will now discuss any pulled topics next week, rather those will be put onto the Healthcare Product project meeting on Monday’s 3-4pm ET as part of the remaining JIRA-s requiring discussions.
• Device
o FHIR-28308 - Binding is missing for Device.operationalStatus.value and Device.associationStatus.value valuesets - @Ana Kostadinovska
o FHIR-28197 - Consider an element on Device for brand name - @Isaac Vetter
Waiting for feedback on pointer to FHIR-27765.
o FHIR-23704 - Why isn't the Device resources, considering it's patient reference, within the patient compartment? - @Isaac Vetter
• Device/Definition
o FHIR-26639 - Rationalise Davice.property values (and DeviceDefinition) - @Rik Smithies
o FHIR-26636 - Differentiation of implantable vs. pateint-use and "non-implantable" devices unclear - @Floyd Eisenberg
o FHIR-25400 - Change the type of .version element – @Ana Kostadinovska
o FHIR-20575 - Align UDI-DI and DI issuers across Device and DevideDefinition resources, reuse definitions - @Ioana Singureanu
o FHIR-16947 - Drop ItemInstance - 2018-May Core STU #141 - @Lloyd McKenzie
o FHIR-16314 - Keep Device Instance separate from Device Kind - Hans Buitendijk
• DeviceUseStatement
o FHIR-26900 - Incorrect clinical-patient search parameter on DeviceUseStatement. - @Eero Kelly
Lloyd McKenzie (Aug 27 2020 at 15:43):
For FHIR-16947, it's not clear what modification is being proposed. I disagree with the assertion that unambiguous differentiation of kind vs. instance is a requirement as many systems do not unambiguously differentiate and function perfectly well. As well, there's a continuum between instance and kind. If there's an order to supply something from lot 123, that's still not specifying a specific instance, but it's stricter than referring to a general product type.
Lloyd McKenzie (Aug 27 2020 at 15:43):
Would like this pulled from the block until the resolution has greater clarity.
Jose Costa Teixeira (Aug 27 2020 at 17:14):
Agree with pulling until we have more clarity (also don't see what is the change).
Jose Costa Teixeira (Aug 27 2020 at 17:19):
Lloyd McKenzie said:
many systems do not unambiguously differentiate and function perfectly well.
well, not perfectly well.. :)
If there's an order to supply something from lot 123, that's still not specifying a specific instance, but it's stricter than referring to a general product type.
Correct, and this argument should help us improve our approach in future discussions. But an instance is countable, whether we define the serial number or just product code. And may be associated with a patient... The product pattern parks the "instance" stuff not to a resource - preserving the difference. That should be part of future discussions
Lloyd McKenzie (Aug 27 2020 at 18:56):
Many systems don't differentiate at all :)
Lloyd McKenzie (Aug 27 2020 at 18:57):
The use-case often doesn't require countability. If I'm ordering, I could care less about countability/inventory most of the time. If I specify a serial number, I'm communicating a specific instance. If I don't, I'm not. Updating the order that was previously just the type to say "actually, use #12345" shouldn't ideally require using a completely different resource.
Jose Costa Teixeira (Aug 27 2020 at 19:09):
agree
Jose Costa Teixeira (Aug 27 2020 at 19:12):
Lloyd McKenzie said:
Many systems don't differentiate at all :)
Some systems don't consider instances, other systems consider instances as just additional payload.
Hans Buitendijk (Aug 31 2020 at 17:04):
Will pull for discussion.
Many systems also need the distinction unambiguously, thus accommodating only systems that do not need this (yet) is not appropriate either. We need a clear counter proposal on how to clearly distinguish a device as an instance vs. kind as presence/absence of certain data when combining it into 1 resource does not work for those many systems that do need to know that.
Hans Buitendijk (Sep 02 2020 at 13:22):
@Lloyd McKenzie : Can you provide use cases where the system creating/establishing the resource would not know what they are dealing with? Consider the following:
- Systems that do know that they are dealing with device definitions are those managing device descriptions, capabilities, and inventories. Examples include LIVD, ICU solutions, logistics.
- Systems that do not necessarily know or believe they do not need to know primarily deal with devices, albeit perhaps frequently in a fuzzy way. I.e., they do not need/care about the serial number, IP address, lot number, etc. but they are actually dealing with (a reference to) one device of sorts.
On the latter, if you record the device that made the observation, all you know may be that it was a large sized blood pressure cuff. Using Device for any of those scenarios as the default or only is reasonable and appropriate as there was a specific device in play and you only provide what you know. Even if you know full UDI, if somebody happens to create a new Device instance for another observation where another observation already had one, is manageable. Nice to not have dups, but workable across systems that may not know what others know (e.g., wheelchairs being re-used and documented across different systems interacting with the same supplier, different patients).
Systems that do deal with definitions know that, and need to keep the two separate where a definition instance can never become an instance instance. That's critical.
Therefore having both enables those who need device definitions, while those dealing with personal devices, or other devices and only need to focus on exchanging data between them can reasonable work just with Device.
I.e., those that indicate they really don't need to know the difference primarily and only deal with device instances anyway. And those who also, or instead deal with definition always know what they are dealing with and that distinction must be preserved from the moment the resource is created.
You can have a mandatory flag, clearly defined data that are present/absent at time of creation and never change, or two separate resources. But you cannot have ambiguity that is fluid over the lifetime of the resource.
Lloyd McKenzie (Sep 02 2020 at 13:43):
Systems often have a single table for device information that contains optional columns for fields like serial number and lot. The same table gets referenced whether ordering or supplying. Whether something is an 'instance' or 'kind' is inferred by context and level of detail present, not by having distinct records. In the case of UDIs, for many systems, those will be identifiers like any other - and the fact that some of them are specific to the instance and others to only the type may mean that the system won't even know they have instance-level data. Having a single resource kind doesn't keep you from maintaining separate instances for instance and type if you wish - pharmacy does that with Medication now. I'd feel much more comfortable if Device followed the same pattern as Medication, where there's a single resource that covers both kind and type and disambiguation is by the level of detail provided and the same resource is referenced for both request and event activities. You could then have a 'knowledge' resource that dealt with definitional characteristics that aren't generally captured as part of day-to-day use. I haven't yet heard a use-case that makes clear why devices and medications need to be treated differently.
Jose Costa Teixeira (Sep 02 2020 at 16:52):
Lloyd McKenzie said:
Systems often have a single table for device information that contains optional columns for fields like serial number and lot.
Not on this side. The only time this happened to me was a big - really big - mess, and required a redesign. So at least one major system was forced to separate the definition from the instances.
Jose Costa Teixeira (Sep 02 2020 at 16:55):
Lloyd McKenzie said:
I'd feel much more comfortable if Device followed the same pattern as Medication, where there's a single resource that covers both kind and type and disambiguation is by the level of detail provided and the same resource is referenced for both request and event activities. You could then have a 'knowledge' resource that dealt with definitional characteristics that aren't generally captured as part of day-to-day use.
I am disappointed to see that the term "knowledge" - which is a a marketing thing - is now promoted to standards. I do think that the medication resource containing an optional "instance" set of attributes is one option that, if extended, can solve the problem nicely.
Regardless of the name, the boundary between "kind" and "instance" is fluid, the boundary between "knowledge" and "kind" is arbitrary.
Jose Costa Teixeira (Sep 02 2020 at 16:56):
Also we should keep in mind that we have medication definition and medication knowledge resources, and that boundary is to me all but clear and has not been put to test AFAIK.
Jose Costa Teixeira (Sep 02 2020 at 17:05):
Trying to link several concurrent discussions, and giving one step, maybe too big and uncertain:
I would think of a resource pattern for "Products" (Medication / Device...), which can serve as a Kind or instance or as Knowledge.
Like NutritionProduct (i think this resource was built by @Jean Duteau and myself, but I don't remember who did what) - or a bit like MedicationKnowledge - most of the characteristics are optional, if you want to use only the code, then you do. If you want to fully describe a product, you can do that too.
Jose Costa Teixeira (Sep 02 2020 at 17:06):
The one change that I'd do there is to change the instance cardinality to 0..* (but that is for inventory management and I don't know for sure if that is a good choice)
Jose Costa Teixeira (Sep 02 2020 at 17:10):
This would mean abandoning (some of) ProductDefinition, just call it Product. Instance and Kind, if needed, can be profiles. This would also resolve the problems we have in cross-border prescription dispense where a code doesn't make it.
Lloyd McKenzie (Sep 02 2020 at 17:10):
I think Knowledge information tends to be stored and managed separately from the Kind/Instance information. The latter is what you pass around with an order or event and (if you have a registry of them) is driven by what's available/authorized in your space. The former is where you go to look up useful information - and is often supplied by knowledgebase vendors.
Lloyd McKenzie (Sep 02 2020 at 17:11):
The set of data elements are quite distinct. On the other hand, the data elements captured for kind vs. instance is typically pretty much the same, with the exception that there are a very small number of elements (generally just identifier/serial number) are exclusive to instances.
Jose Costa Teixeira (Sep 02 2020 at 17:12):
Well, indeed, "knowledge" information is master data, the others are transactional. they are best kept separate. But in a prescription you may need to convey a number of definitional attributes. See the recent question about "where do I put ATC in a Medication in a Prescription" - this will always happen.
Jose Costa Teixeira (Sep 02 2020 at 17:16):
the "medication definitional / knowledge" information is provided by several sources, inlcuding Medicinal Product Dictionaries (that is the ISO term for knowledgebase).
Jose Costa Teixeira (Sep 02 2020 at 17:17):
When i say "I want to order this product, but since I don't know the code, here is active substance, the dose form, the strength, the color..." - is this a medication or knowledge?
Jose Costa Teixeira (Sep 02 2020 at 17:17):
When we specify a medication, we can do that by a code, or by a set of defining attributes which may or may not have a corresponding code.
Jose Costa Teixeira (Sep 02 2020 at 17:18):
I am not 100% sure we should abandon the "definitional/knowlege" vs "kind" boundary, I am just exploring where it makes less sense.
Jean Duteau (Sep 02 2020 at 17:20):
Jose Costa Teixeira said:
When i say "I want to order this product, but since I don't know the code, here is active substance, the dose form, the strength, the color..." - is this a medication or knowledge?
I'm trying not to get involved in this conversation but rather see it play out, but I had to ask - when would you ever order a product by saying "it's a red 10mg tablet with an active ingredient of Gymnema"? You could certainly use a Medication Knowledgebase to look up a product with those characteristics, but then you'd get a choice and pick one to actually order.
Unless you are talking about compounds where you don't specify colour but rather form, and list of ingredients?
Jose Costa Teixeira (Sep 02 2020 at 17:22):
When the prescriber and dispenser are in different European countries
Jose Costa Teixeira (Sep 02 2020 at 17:23):
extemporaneous preparations are another case indeed.
Jean Duteau (Sep 02 2020 at 17:24):
Jose Costa Teixeira said:
When the prescriber and dispenser are in different European countries
Interesting. We have never heard of this use case before. I would have assumed that they would simply order a generic formulation of the drug they wanted.
Jose Costa Teixeira (Sep 02 2020 at 17:25):
OpenMedicine has presented this, but a long time ago.
Jose Costa Teixeira (Sep 02 2020 at 17:25):
They may be unable to order a generic formulation - there is no code for that generic formulation
Jose Costa Teixeira (Sep 02 2020 at 17:28):
besides, the generic formulation would hide possibly important characteristics - what if the physician says "this brand, and please do not substitute"? or if the physician chooses one brand because he has checked that this brand is the one without lactose?
Jean Duteau (Sep 02 2020 at 17:29):
Jose Costa Teixeira said:
besides, the generic formulation would hide possibly important characteristics - what if the physician says "this brand, and please do not substitute"? or if the physician chooses one brand because he has checked that this brand is the one without lactose?
Sure, but now you have a brand, so you have a code. Your initial statement was that an order would be made without a code but so I'm going to describe it by using form, strength, active ingredient and physical characteristics.
Jose Costa Teixeira (Sep 02 2020 at 17:29):
you have a code in one country that means nothing in the other country
Jose Costa Teixeira (Sep 02 2020 at 17:31):
Back to issue at hand - I am not sure we must split definition / kind /instance. I think this analysis that Hans is doing is the one that has to be done, if we need consistency. Until now, these differences were, at best, implicit in our resources
Hans Buitendijk (Sep 02 2020 at 17:36):
@Lloyd McKenzie While some systems may lump instance and kind together, it would be inappropriate to state that others do not and need not. That's not our place to dictate. Agreed with @Jose Costa Teixeira that where that is done and you want to go beyond simpler use cases that becomes a big challenge very fast. So FHIR must recognize both needs. Having separation provides that easiest path to that and those that have a critical need to separate can, and those who primarily deal with devices as instances with incomplete data can use device. That leaves some space in the middle, but as you said, the system that created the resource understands the context and can be reasonable expected to communicate that context as part of the appropriate resource. That context cannot remain hidden inside a system and not shared, particularly as having one resource instance to be considered a true definition and in other an actual device without all identifying information hampers interop at necessary level of fidelity.
And so far, all use cases where there is a desire to just use one resource end up being ones that really are references device instances with limited identifier information that would be reflective of an instance. That's fine. Use Device and do not value those attributes.
Lloyd McKenzie (Sep 02 2020 at 18:36):
@Jose Costa Teixeira If you want to order by characteristics, that would generally be a descriptive text string, not discrete data elements for each characteristic.
@Hans Buitendijk Forcing distinct resources means that implementers are forced to disambiguate even if they don't have the capability. With a single resource, it's certainly possible for implementers who wish to distinguish to do so. I'm sure there are systems in the medication space where implementers do have separate repositories for instances and kinds - and they can still work just fine with a single Medication resource.
If the references from different resources force use of DeviceDefinition and don't allow Device everywhere, then there's a problem. And if some implementers will stick an instance in Device and others in DeviceDefinition, that's also a problem.
Jose Costa Teixeira (Sep 02 2020 at 19:01):
Lloyd McKenzie said:
Jose Costa Teixeira If you want to order by characteristics, that would generally be a descriptive text string, not discrete data elements for each characteristic.
yes for officinal formulas inside the same country, not for cross-border prescription, dispense, supply and monitoring
Hans Buitendijk (Sep 03 2020 at 14:25):
@Lloyd McKenzie : I updated the proposed disposition to clarify the intent, https://jira.hl7.org/browse/FHIR-16947, to close this JIRA as ItemInstance does not exist anymore and direct any new comments to Device and/or DeviceDefinition as those were the result of substantial community discussion/review and concluded to use those to support the respective needs. That would then help focus any future discussions on what we have, not on what is not there anymore. With that, can we un-pull this JIRA from the block vote?
Lloyd McKenzie (Sep 03 2020 at 15:00):
Not yet - the resolution doesn't make clear what modification is anticipated.
Hans Buitendijk (Sep 03 2020 at 15:34):
@Lloyd McKenzie : As ItemInstance does not exist anymore, there are no changes to ItemInstance. Rather any suggestions need to be made in context of what Device and DeviceDefinition currently provide, i.e., if there is a need for modifications, that should be stated against either of those. The current JIRA has not enough concrete information to do anything. Particularly in light of the reviews/discussions that have occurred since that lead to current state. I.e., this is about removing JIRAs that cannot really be acted on as they were submitted and require the submitter to address any remaining proposals in the context of what exists.
Lloyd McKenzie (Sep 03 2020 at 18:23):
If there are no changes, it should be "not persuasive" rather than NPw/M
Lloyd McKenzie (Sep 03 2020 at 18:24):
If it says 'mod', that means that some sort of change is being made to the spec
Hans Buitendijk (Sep 03 2020 at 19:33):
Will adjust.
Last updated: Apr 12 2022 at 19:14 UTC
