Stream: Orders and Observation WG
Topic: Substance resource as an instance
Rik Smithies (Sep 16 2020 at 18:04):
I have been discussing this with @Hans Buitendijk and @Hugh Glover and we want to clarify the use of Substance resource as an instance and make changes to Substance to better support this
https://jira.hl7.org/browse/FHIR-28547
Lloyd McKenzie (Sep 16 2020 at 18:47):
Both Medication and Substance behave as both 'kind' and 'instance' - and it would be problematic (and unnecessary) to change that.
Rik Smithies (Sep 16 2020 at 19:22):
we are not changing that
Jose Costa Teixeira (Sep 16 2020 at 22:04):
I think substance code is not the same as substance instance identifier.
And the notion of a "instance flag" was briefly discussed in the product pattern, we adopted the instance backbone. Why is substance instance different from medication instance?
Jose Costa Teixeira (Sep 16 2020 at 22:06):
Perhaps this is the same debate as whether to use separate resources for kind and instance.
Rik Smithies (Sep 17 2020 at 12:12):
-I think substance code is not the same as substance instance identifier.
I agree
Rik Smithies (Sep 17 2020 at 12:13):
-And the notion of a "instance flag" was briefly discussed in the product pattern, we adopted the instance backbone.
Because a 0..* backbone element with several optional items in it doesn't make a very good flag. A boolean works better
Rik Smithies (Sep 17 2020 at 12:14):
-why is substance instance different from medication instance?
Because a medication is intended for a person, but a substance is intended as an ingredient, never for a person
Rik Smithies (Sep 17 2020 at 12:16):
-Perhaps this is the same debate as whether to use separate resources for kind and instance.
Yes it is part of that debate. Substance is already used for both and we see no reason to change that (@Lloyd McKenzie's point)
Lloyd McKenzie (Sep 17 2020 at 12:58):
If you're going to add a flag, it can't be mandatory (and it's not a modifier)
Rik Smithies (Sep 17 2020 at 13:08):
great - that is what we propose, not mandatory. But if it makes it an instance or a kind, is that not a modifier?
Jose Costa Teixeira (Sep 17 2020 at 13:14):
didn't we propose a flag in the Product pattern discussion (inside instance)? I think I remember it not being seen as necessary.
Jose Costa Teixeira (Sep 17 2020 at 13:15):
Rik Smithies said:
-And the notion of a "instance flag" was briefly discussed in the product pattern, we adopted the instance backbone.
Because a 0..* backbone element with several optional items in it doesn't make a very good flag. A boolean works better
true, a boolean works better for a flag - question is - why is this a "flag"?
Jose Costa Teixeira (Sep 17 2020 at 13:18):
this discussion seems 2016'ish . And it seems like a very good reason to have a pattern (as we do). If we keep hammering one or another new resource to find the best model, we will take a while.
Jose Costa Teixeira (Sep 17 2020 at 13:18):
(sorry for pushing for pattern again, but I don't realize how strong I'm pushing :) )
Hans Buitendijk (Sep 17 2020 at 13:29):
@Lloyd McKenzie : there needs to be recognition that when a resource intends to cover both an actual instance (albeit not always fully populated with all relevant identifiers to clearly make it so, thus somewhat kind-ish) and a definition/kind, that one always knows which context that resource is expected to be used in as the context that it is actually being used in (as referenced already or not yet) is not always present, and that during that resource instance's life cycle the meaning does not change, e.g., a resource that started as a definition suddenly gets a serial number and has become an instance. That needs some sort of flag, or boolean, or unambiguous absence or presence of certain data that never can change (immutable). Use cases that indicate they don't care are actually in the instance space with fuzzy/kind-ish identification. Those working with definitions would not suddenly want to change them mid-stream to instances as references that expect them in definition context would become problematic. For Substance it is o.k. to have one resource supporting both, but then it must be possible to unambiguously and immutably indicate what it represents. Relying on profiling is not strong enough. Absence/presence of certain data is not strong enough. Only an immutable flag/boolean is. And you can default as appropriate (mostly instance as reality is that there are many more instance instances than definition instances).
Lloyd McKenzie (Sep 17 2020 at 14:43):
Most systems working with medications and substances today don't differentiate and don't need to. You could certainly profile in your space to make it mandatory. However, given that many (most?) systems today don't know/don't care, FHIR certainly can't make such a concept mandatory. In many spaces the same resource instance can be pointed to as both kind (e.g. by the order) and instance (e.g. by the dispense). And that works just fine.
Lloyd McKenzie (Sep 17 2020 at 14:43):
So It's not ok to force the flag to be populated in the core spec - and I wouldn't even be comfortable with it being mandatory in a general-purpose IG like US-Core.
Rik Smithies (Sep 17 2020 at 14:47):
@Lloyd McKenzie the Jira does make it very clear that we are not making it mandatory. It basically states exactly what you just stated :-)
Lloyd McKenzie (Sep 17 2020 at 14:53):
I'm arguing w/ Hans, not you Rik :)
Rik Smithies (Sep 17 2020 at 15:50):
ah, but I was agreeing with both you and Hans, so something is up... :-)
Lloyd McKenzie (Sep 17 2020 at 15:53):
Hans is saying you always need to know the context in which the resource is intended to be used in - and I'm saying you don't. That for many use-cases, it's fine for the resource to be ambiguous
Rik Smithies (Sep 17 2020 at 16:02):
I can't speak for Hans, but we did chat earlier about that offline and we were agreed that the flag can be optional (then I wrote that up in the Jira). He did say above "can default as appropriate" which is how we discussed it.
Lloyd McKenzie (Sep 17 2020 at 16:44):
The flag would need to allow for 'unknown'. It can't be a boolean where if you omit it, a value is assumed.
Rik Smithies (Sep 17 2020 at 16:52):
if its not there the value would be "nothing stated about that". Which is neither true nor false, indeed.
I see "Default value" in the FHIR source spreadsheets. Does that not apply these days?
Lloyd McKenzie (Sep 17 2020 at 17:35):
Default values aren't allowed. You can have "meaning if missing". But in this case, if I have a Medication instance and I don't know/care whether it represents a kind or an instance (and might be used in both context), it needs to be exposed in FHIR that way.
Rik Smithies (Sep 17 2020 at 18:19):
A boolean can state yes or no, and if you dont know/care you dont use it. Are you saying there must be a way to positively state that we don't know? Also, if meaning if missing is a concept, why is that unable to work here?
Lloyd McKenzie (Sep 17 2020 at 18:37):
I'm saying I'd be happier with an optional code. Most environments can't handle an 'unknown' boolean.
Rik Smithies (Sep 18 2020 at 18:42):
A boolean is easier for people to grasp I would say. If there cannot be a default - or a meaning if missing (I'm unclear what role that plays) - then there is true (it's an instance), false (it's not, so it's a kind/definition) and no value, if it's not present, no statement is made about what it is. Is there a reason that that doesn't work?
Lloyd McKenzie (Sep 18 2020 at 19:35):
The reference implementations can't generally distinguish once the data has been parsed whether a boolean was present with false or absent entirely. So 'code' is really the only way to go to maintain the distinction safely.
Grahame Grieve (Sep 20 2020 at 19:35):
The reference implementations can't generally distinguish once the data has been parsed whether a boolean was present with false or absent entirely
That's not true of most of them, but it is true of some implementations
Last updated: Apr 12 2022 at 19:14 UTC
