Stream: fhir/infrastructure-wg
Topic: Where are we on my isMod tracker
Eric Haas (Jun 25 2018 at 16:31):
From our last discussion the only person who seems to have a grasp of isMod is Lloyd. So I think:
a) We let Lloyd be the isMod authority which I don't think is scalable.
b) We scrap it as undefinable - because most people can't come up with isMod reason outside a tautological rehash of the current isMod definition (' 'cause it shouldn't be ignored! ') I don't see how we can apply it with any consistency and thus seriously undermining its utility.
c) Ask the community whether they pay attention to it in the real world and whether they need something beyond required and must support. maybe an 'ATTENTION' extension flag to indicate need to pay special attention to element.
Grahame Grieve (Jun 25 2018 at 19:32):
when would you not set ATTENTION! ?
Lloyd McKenzie (Jun 25 2018 at 20:01):
This has nothing to do with "attention". It has to do with whether an element is safe to ignore. Most elements are. You can easily ignore patient name, gender, date of birth, etc. They don't change the meaning of the other data. Safety to ignore is critical to get agreement on because if we don't have that, then it won't be clear when to use modifierExtension vs. not. And if that's not true. then you can't safely ignore any extensions. And if that happens, FHIR is in deep trouble because it suddenly means you have to build a custom interface for every system you talk to and coordinate updates with all of your communication partners.
Eric Haas (Jun 26 2018 at 00:13):
when would you not set ATTENTION == when would you not set isMod
To me the bigger issue is the difficulty in consistently applying this flag undermines its utility. Its too contextual to determine what and what can't be ignored.
Eric Haas (Jun 26 2018 at 00:15):
The idea that if there is no flag you can say "whew' that is not going to affect some safety issue" is itself a safety issue. What is meant by 'safe' anyways?
Grahame Grieve (Jun 26 2018 at 03:17):
so you're just moving the deck chairs around.
Grahame Grieve (Jun 26 2018 at 03:17):
take Patient Gender: anyone can construct a workflow example where it's critical that you don't ignore it.
Grahame Grieve (Jun 26 2018 at 03:18):
that doesn't make it a modifier: every element in FHIR is present because it's critical for some reason or other, and we fully expect every element to be impossible to ignore in some workflow
Grahame Grieve (Jun 26 2018 at 03:19):
what makes an element a modifier is that it modifies the interpretation of the parent element or a sibling element by changing it's meaning - either negating it, or qualifying it significantly.
Grahame Grieve (Jun 26 2018 at 03:20):
e.g. entered in error
Eric Haas (Jun 26 2018 at 03:45):
The key here is " it modifies the interpretation of the parent element or a sibling element by changing it's meaning" interpreted by Whom?
Still a concern that if is not applied consistently then is unreliable.
Grahame Grieve (Jun 26 2018 at 03:54):
we're still waiting for Lloyd to do doco on this, no?
Lloyd McKenzie (Jun 26 2018 at 06:10):
I'll see what I can do during my meetings today
Eric Haas (Jun 26 2018 at 14:22):
The bottom line is that despite Lloyd's dulcet prose, IsMod will always be subjective and thus unevenly applied. Like mustSupport, its usefulness is closer to the implementation level, but I don't think it is appropriate in the base.
Lloyd McKenzie (Jun 26 2018 at 18:20):
If isMod is subjective, we're in deep trouble. There may be situations where the meaning of the resource itself is subjective, and the setting of isMod will need to take that into account. But the meaning of isMod should never be subjective.
Lloyd McKenzie (Jun 26 2018 at 18:22):
It needs to be in the base for two reasons:
1. To give examples to implementers to help them decide whether new extensions need to be modifier extensions or not
2. To identify places where future values are also allowed to be modifier values. For example, where "status" is a modifier element, then we could introduce future codes that are themselves modifiers. But we wouldn't be able to do that for gender, for example.
Eric Haas (Jun 26 2018 at 19:23):
What I meant is the interpretation whether an element is an IsMod will always be subjective.
Lloyd McKenzie (Jun 26 2018 at 19:37):
If the rules are clear, the interpretation shouldn't be subjective.
Eric Haas (Jun 26 2018 at 19:53):
...
Lloyd McKenzie (Jun 26 2018 at 19:58):
(I'm working on it :))
John Moehrke (Jun 26 2018 at 21:12):
Seems you are re-inventing the mustUnderstand property found in SOAP. I think that concept is far more clear than isModifier. .. https://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383500
Lloyd McKenzie (Jun 26 2018 at 21:16):
Must-understand implies that systems can't ignore the element - which is untrue. If I don't care if a Patient is actually still a patient, I can ignore the deceased[x] and active elements. I just have to understand what impact those elements could have on the resource in making my decision to ignore.
John Moehrke (Jun 26 2018 at 23:28):
I am very confused by this... How will an app have any idea that an isModifier is ignorable if it doesn't understand it? It seems to me that isModifier is a must understand concept. One can ignore it, but you must understand it. Yes in SOAP they say that you must process it, but they never defined what process..... All of these fail in the same way... what does "Modifier" mean? what does "Support" mean? what does "Process" mean?
Lloyd McKenzie (Jun 27 2018 at 05:28):
The application doesn't need to understand it. The developer/designer making the decision to ignore the element needs to understand it. The difficulty is that if we label it "must understand", readers will assume that applies to the system, not to a designer.
Lloyd McKenzie (Jun 27 2018 at 05:28):
From a system perspective, the extension could just be on a list that says "safe for this system to ignore"
John Moehrke (Jun 27 2018 at 12:57):
a developer writes an app today... two years from now a resource comes in with an extension marked with isModifier... How is the developer involved?
Lloyd McKenzie (Jun 27 2018 at 18:18):
The developer is involved in deciding how to process "recognized" extensions. They'll also write code for how to handle unrecognized extensions. The explanation of how the extension can make understanding untrue only matters for the first case.
Lloyd McKenzie (Jun 27 2018 at 18:18):
(Though it also matters for the developer who introduced the new extension and had to figure out whether it was a modifier or not)
Grahame Grieve (Jun 27 2018 at 20:03):
I have a routine called 'checkNoModifiers' that I call on every class I touch...
Eric Haas (Jun 27 2018 at 20:27):
@GG ? is that a comment in support or against Lloyd's position
John Moehrke (Jun 27 2018 at 20:36):
seems it is a comment in support of my assertion that isModifier is the same as mustSupport...
John Moehrke (Jun 27 2018 at 20:37):
It is so much fun re-inventing SOAP... :-)
Eric Haas (Jun 27 2018 at 20:42):
I think you meant mustUnderstand ?
no matter I find the same underlying issue with that too. How did and does mustUnderstand fly in the real world?
Eric Haas (Jun 27 2018 at 20:43):
as an object lesson... (no pun intended)
John Moehrke (Jun 27 2018 at 21:05):
yup. mustUnderstand.... How it flys in the SOAP world is that an recipient must fail a communication that includes mustUnderstand that it does not... so the whole world comes to a halt.
Lloyd McKenzie (Jun 27 2018 at 21:37):
We're not that strict. You don't have to halt, but you need to take care in your processing. For example, you might just display narrative, you might warn the user that data returned includes content with unrecognized isModifier elements. You might strip the element containing the isModifier if you don't care about that element (e.g. a Patient.contact with a modifier element saying "do not contact")
Eric Haas (Jun 27 2018 at 21:54):
My Question was really how it was applied , is it ignored ( don't actually halt ) , who is the decider and is it generally useful
Lloyd McKenzie (Jun 27 2018 at 21:58):
The decider is the receiving application. The decision is driven by the types of action the system does. "Display the narrative" isn't a useful option to a clinical decision support engine. However "ignore the element containing the modifier" might be if that element isn't needed to deliver the decision support. Knowing that you may have a false interpretation of the data if you ignore the element is "generally useful" in my book...
Lloyd McKenzie (Jun 27 2018 at 21:59):
(I've passed draft language to Grahame for review. I'll share it as soon as he agrees it's complete and in alignment with his understanding of isModifier.
Grahame Grieve (Jun 28 2018 at 04:08):
I think it's ok
Lloyd McKenzie (Jun 28 2018 at 06:25):
https://docs.google.com/document/d/1z7FqdA9ZNkOaIrY0BFVSoSVTK4EIqVn_zUND7MHHc0w - additional feedback welcome.
John Moehrke (Jun 28 2018 at 13:07):
I worry most about your statement to those creating extensions to mark it as an isMod if they are uncertain... This will result in many false uses, and thus water down the usefulness.
Lloyd McKenzie (Jun 28 2018 at 18:42):
That's why the first instruction was to consult the community. If there's still uncertainty, then I'd rather they err on the side of declaring isModifier than not
Eric Haas (Jun 28 2018 at 19:51):
I read through it and would like more concrete objective guidelines - I but don't think you can put three people in a room and have agreement on what is an what isn't an isMod for everybody else. maybe IsMod Reason should replace the flag thus raising the bar way higher.
Lloyd McKenzie (Jun 28 2018 at 20:16):
What would "more concrete" look like? You believe there'd be disagreement over whether ignoring an element could lead to a false interpretation?
If the flag is yes, I believe the reason is required, so it's sort of behaving that way already.
Eric Haas (Jun 28 2018 at 21:08):
- who is the target - machines that process or people?
- what percentage of the target audience needs to know this ( who it could potentially affect ) before the flag is set 1% , 50% or %100?
- what would change - the resource or the neighborig element?
- what it the meaning of modify? meaning?, interpretation?
Eric Haas (Jun 28 2018 at 21:13):
Flag are easy to set and a crutch to make up some hokey reason why... But I'm not really sure it changes anything anyway. It makes it easier for me to reject trackers and send back to the author though :-)
Lloyd McKenzie (Jun 29 2018 at 05:50):
1. Target is machines - the machine needs to know if the data is safe to process if it ignores the extension
2. 100% of machines need to know whether the containing element is safe to process if it doesn't recognize the modifier element
3. The containing element or any of its descendants
4. The meaning of modify is described in the document - an interpretation made when ignoring the element could be made untrue by paying attention to the element.
I'll add 1-3 into the document.
Lloyd McKenzie (Jun 29 2018 at 05:50):
Actually just 1 & 3
Lloyd McKenzie (Jun 29 2018 at 05:56):
See if the added documentation helps
Ewout Kramer (Jul 02 2018 at 12:11):
"Because the resource definition does not make clear what the interpretation is, the element must be marked as a modifier because it is known that a reasonable interpretation of the resource practiced by a not-insignificant number of systems could be negated by the value of the element."
This might be the heart of the issue: "because it is known", "reasonable interpretation", "not-insignificant number". Workgroups will try to find answers to these subjective (I think) qualities - often by determining whether something is isMod for a specific usecase.
Lloyd argues that we must look at the interpretation of elements "across all usecases" (unless documented otherwise), and then determine "the reasonable interpretation", this is very hard -I think- and also the source for subjective (and ultimately inconsistent) use of the isMod element.
To make the pain felt, take a look at the extreme example "Basic". It's very generic, it's really hard to argue across all usecases, so really hard to prove (or disprove) that there is not a "significant number of systems" that would interpret the elements of Basic incorrectly, hence all elements could be argued to be isMod.
Now, obviously, there are clear cases (entered-in-error), and Basic is at the other end of the spectrum, but a lost of cases will be something in between - and thus a cause for inconsistent application of isMod.
Lloyd McKenzie (Jul 02 2018 at 12:23):
Well, with 'basic', you've got Basic.type which qualifies the context. And most extensions on Basic would only be allowed for a particular basic.type, so the use-case space would still be relatively constrained. "reasonable interpretation" and "not-insignificant" are necessary because some implementations wilfully misinterpret the meaning of an element, and we can't try to allow for that.
Ewout Kramer (Jul 02 2018 at 12:24):
Otherwise put: there is always a way for an element to be reasoned to be non-modifier. We can see that clearly when Lloyd writes:
"Even something as critical as Observation.code is not a modifier element. While the Observation would have little utility without the code, the understanding when ignoring the element that “some” Observation had been made on the specified subject at the specified date and time would still be true when the element was reintroduced."
I think I could reformulate this like so:
"Even something as critical as Patient.deceased is not a modifier element. While we would no longer know whether the patient is alive, the understanding when ignoring the element that “some” Patient exists or existed, and that some Observations have been made on the specified subject would still be true when the element was reintroduced."
Still, Patient.deceased is isMod, while Observation.code is not.
Lloyd McKenzie (Jul 02 2018 at 12:24):
The point remains that if we don't have isModifier, FHIR is in deep trouble. If you can't safely ignore regular extensions, we're back in the world of 1:1 interfaces with coordinated roll-out of enhancements.
Lloyd McKenzie (Jul 02 2018 at 12:26):
If someone is deceased, they no longer meet the definition of Patient - they're no longer receiving healthcare services. If the definition made clear that it includes past-recipients, then I'd agree that isModifier is unnecessary.
John Moehrke (Jul 02 2018 at 12:33):
Lloyd, you are ignoring the solution I have presented. That non-core extensions are forbidden from being a modifier. If someone needs to do this, then they clearly have a use-case that is NOT in the definition of that Resource. This does not forbid us from having core elements that are modifiers, or even core extensions that are modifiers. It just says that once someone understands the NORMATIVE content, they can be assured that no extension can invalidate that understanding.
John Moehrke (Jul 02 2018 at 12:34):
Clearly Basic is unique given that its only reason for being is to handle these unusual cases.
Ewout Kramer (Jul 02 2018 at 12:36):
"If someone is deceased, they no longer meet the definition of Patient" - this is unsure and sounds like a pretty ad-hoc argument, made up as part of thinking about "isMod".
Still, we're getting to the root cause, since this is in line with what happens when thinking about isModifier with a workgroup. The questions about "what thing in reality is this Resource representing? (alive patients? dead patients?)" keeps popping up -- often without clear answers - and so it becomes hard to reason about isModifier. It's interesting that the way to clear this up, is to step back and look at the definition - and maybe change or clarify it.
Johns comments made me think: workgroups can do that - but not third parties. Actually, when John says "If someone needs to do this, then they clearly have a use-case that is NOT in the definition of that Resource" might be very true. I have to think about that for a bit.
Lloyd McKenzie (Jul 02 2018 at 12:38):
@John Moehrke That doesn't work in the real world. Implementers will need to introduce modifiers. They always have. And they've always done so - conformant or not. As a result, implementations tend to be cautious about allowing instances that contain unrecognized extensions
John Moehrke (Jul 02 2018 at 12:43):
Yes, my solution forbids bad behavior. Your counter argument is non substantive and non persuasive. Discussions about what a modifier is in the context of the normative elements and core extensions is showing that there is not a good understanding of what a modifier is... given this, it is very hard to accept that we should allow this on any random extension.
Ewout Kramer (Jul 02 2018 at 12:45):
Yes, if you need a degree in philosophy, ontology or semantics to make this work, we're putting up a high barrier.
Maybe, though, in practice the situation is not that bad. It might be done inconsistently (outside of the core materials), and probably be over-used. But if it's used in a certain context of exchange, people within that context will probably agree it's a really important bit of data to exchange, so no one will complain. If it becomes apparent later on that isModifier is too restrictive (since other usecases are found in that context of exchange), turning an extension back into non-modifier will not break anything.
Lloyd McKenzie (Jul 02 2018 at 12:48):
@John Moehrke It's not "bad" behavior. It's meeting an implementation requirement. If a system needs to communicate something, it will communicate it. Our job is to find a safe way for that to occur.
Lloyd McKenzie (Jul 02 2018 at 12:49):
@Ewout Kramer, I agree that the failure mode seems to be that implementers will over-use isModifier rather than under-use it, which is the "fail safe" scenario.
Lloyd McKenzie (Jul 02 2018 at 12:50):
And I agree too that changing something to no longer be a modifier if it was marked so incorrectly originally is also a safe thing to do.
Ewout Kramer (Jul 02 2018 at 12:51):
Yes, and we should be able to find a way to make its use consistent within the FHIR spec (although I am still afraid we might open a pandora's box while doing so ;-)
John Moehrke (Jul 02 2018 at 12:51):
I don't agree that over-use is more safe. It is from the interpretation of that element, but it is NOT from the interpretation of everything else. The perspective I am focused on is the recipient, where you seem to be focused on the sender. Bad behaviour by a sender, does negatively impact a recipient.
John Moehrke (Jul 02 2018 at 12:52):
Consistent definition of what a modifier is and when it is appropriate is clearly needed before we can proceed on if it should be allowed in random extensions.
John Moehrke (Jul 02 2018 at 12:53):
I am not against them, if they are well defined... but as defined today, means any random extension that got marked as a modifier will cause a denial-of-service attack... because I can't ignore it, but can't process it because I don't know what it is...
Lloyd McKenzie (Jul 02 2018 at 12:54):
If someone sends you data you can't process, you can reject it. isModifier doesn't make a more effective denial of service attack than sending malformed XML or any other instance that triggers a rejection
Lloyd McKenzie (Jul 02 2018 at 12:56):
Sending instances that contain modifier extensions always carries the risk of the instance being rejected, filtered, not processed or otherwise not fully processed. That's the price the sender agrees to incur by including them in the instance. The sender is the one who wants the data processed. It's no skin off the receiver's nose if it can't process something the sender wants it to because of something the sender has done.
John Moehrke (Jul 02 2018 at 13:04):
If I can reject a resource because of an unknown isModifier, then this is just like SOAP mustUnderstand... Yet, you argued strongly that it is NOT... If we can clarify that isModifier is a must understand; then I can get back on the positive side.
Lloyd McKenzie (Jul 02 2018 at 13:21):
You can reject. But you don't have to
John Moehrke (Jul 02 2018 at 14:04):
the clarification I am making is that if I don't understand the extension (that is marked as a modifier) then I must reject. I can understand and choose to ignore, that is logical. But I must first understand the extension. Where as non-modifier extensions can be safely ignored if they are not understood.
Lloyd McKenzie (Jul 02 2018 at 14:07):
You don't have to reject. You can strip the element containing the modifier. You can choose to only process the narrative. You can highlight to the user that a modifier is present and get them to figure out what to do. You can kick it off to manual processing.
Lloyd McKenzie (Jul 02 2018 at 14:08):
What you can't do is process it as normal if you see an element with a modifier extension you don't recognize.
John Moehrke (Jul 02 2018 at 14:10):
Then what is the meaning of true? It sounds like your definition of meaning is that "the sender thinks this is an important element."...
Lloyd McKenzie (Jul 02 2018 at 14:12):
It has nothing to do with importance. It has to do with whether it can falsify the interpretation of the containing element or its descendants.
Lloyd McKenzie (Jul 02 2018 at 14:13):
If I send a "do not contact" flag on Patient.contact, that might not be super important to the sender and might not matter at all to the receiver (because they'd never contact anyone). But it certainly falsifies the interpretation of Patient.contact when you ignore the extension.
Lloyd McKenzie (Jul 02 2018 at 14:14):
On the other hand, "name" might be of critical importance to both sender and receiver. But ignoring it doesn't lead to a false interpretation of the rest of the instance.
Lloyd McKenzie (Jul 02 2018 at 14:15):
I might declare that name is minOccurs=1 and mustSupport. But it's not a modifier.
John Moehrke (Jul 02 2018 at 15:07):
so I must understand the "do not contact" before I can chose to ignore it as it doesn't affect me.... Thus I am stressing that I must understand.
Lloyd McKenzie (Jul 02 2018 at 16:08):
All of the solutions I described can be performed without knowing anything other than "there's some unrecognized modifier extension appearing on one of the Patient.contact elements"
Lloyd McKenzie (Jul 02 2018 at 16:09):
If you recognize it, then you can choose to process the instance as normal if you determine that the impact of the extension doesn't interfere with your "normal" processing.
Eric Haas (Jul 03 2018 at 23:40):
see this chat for a test case why is so frustatingly impossible to apply? :
Eric Haas (Jul 04 2018 at 15:36):
Although I understand the intent, its impossible IMO to nail this down - it boils down to the subjective nature of what interpretation is and the application of isMod becomes arbitrary.
can't we just have a blanket statement that implementers must consider the ramifications of ignoring any element and extension and leave it at that?
I'll ask again, does this work in the real world for SOAP. Or have they run into the same issues?
Eric Haas (Jul 04 2018 at 15:41):
Can we at least agree it is highly subjective and arbritary?
Lloyd McKenzie (Jul 04 2018 at 15:49):
I don't see how this is subjective or arbitrary. It's a very simple test. It's possible that the interpretation of the resource itself might be unclear, but that's an issue with the resource definition, not with what isModifier means
Lloyd McKenzie (Jul 04 2018 at 15:51):
When you look at Observation.focus and see what it can do to the meaning of the Observation, I don't see how there's any subjectivity in evaluating that "yes, if you ignore this element, you could come to a false interpretation of the Observation instance".
Grahame Grieve (Jul 04 2018 at 19:57):
I have some sympathy for Eric here. It all depends on the definition of .subject. If you say 'this observation is made on this subject' then focus is a modifier. If you say 'this observation is made about this subject' then focus is not a modifier
Grahame Grieve (Jul 04 2018 at 19:57):
given the definition of .subject at the moment, focus is clearly not a modifier
Grahame Grieve (Jul 04 2018 at 19:58):
@Lloyd McKenzie if you're going to maintain that things can become modifiers because people wrongly interpret the definitions of elements, then we are in trouble indeed
Lloyd McKenzie (Jul 04 2018 at 21:28):
If you have an Observation that says "code=blood type", "value=B+", "subject=Jane Smith", you will interpret that to mean that Jane Smith's blood type is B+. And if .focus gets added that says "fetus", then it becomes clear that the previous interpretation was wrong. There's no "wrong" interpretation of the definitions of elements involved.
Grahame Grieve (Jul 04 2018 at 21:28):
you will interpret that to mean that Jane Smith's blood type is B+
Grahame Grieve (Jul 04 2018 at 21:28):
have you read the definition of Observation.subject?
Lloyd McKenzie (Jul 04 2018 at 21:32):
Yes. Are you saying that if I just have code, value and subject, that I cannot infer that the blood type is the blood type of the patient? That focus must be present before I can be sure whose blood type it is? Because that's the only other possibility here.
Grahame Grieve (Jul 04 2018 at 21:36):
I'm saying that following the definition of subject, you cannot infer that meaning without first checking focus. That doesn't make focus a modifier, because the fact that focus matters is explicit in the definition of subject.
Lloyd McKenzie (Jul 04 2018 at 21:41):
So we can make all modifier elements non-modifier by just noting their relevance in the definition of the resource or other elements? I don't think that makes sense.
Lloyd McKenzie (Jul 04 2018 at 21:42):
The fact the definition of an element acknowledges "my meaning may be transformed by element X" doesn't mean that element isn't a modifier. It should still be flagged. It just means we're calling attention to that fact from more than one place.
Grahame Grieve (Jul 04 2018 at 21:42):
that's very clear by our definitions. If we defined Observation as "Measurements and simple assertions made about a patient, device or other subject, or records of denial of making an Observation", then status = entered in error wouldn't be a modifier
Grahame Grieve (Jul 04 2018 at 21:43):
and I think we're at the heart of Eric's issue here. You're just making stuff up if you want to define ismodifier differently from what the definitions say
Grahame Grieve (Jul 04 2018 at 21:43):
my meaning may be transformed by element X
Still a modifier...
Grahame Grieve (Jul 04 2018 at 21:44):
my meaning is this or this or this... then the elements that modulate this... not a modifier
Lloyd McKenzie (Jul 04 2018 at 21:45):
So what you're saying is that if focus is not present, and I have "Jane smith, blood type, A+", I can't know who/what the blood type applies to. Correct?
Lloyd McKenzie (Jul 04 2018 at 21:48):
"Can I safely ignore the Observation.focus element knowing that doing so won't cause me to misinterpret the meaning of the remaining Observation information?" I can't see how that can be answered "yes".
Grahame Grieve (Jul 04 2018 at 21:53):
So what you're saying is that if focus is not present, and I have "Jane smith, blood type, A+", I can't know who/what the blood type applies to.
no, I'm saying that under the current definitions, you can't know that without looking to see if focus is present.
Grahame Grieve (Jul 04 2018 at 21:55):
"Can I safely ignore the Observation.focus element knowing that doing so won't cause me to misinterpret the meaning of the remaining Observation information?"
no, you can't ignore it. But that's not the definition. It is "An element is labeled "Is-Modifier = true" if the value it contains may change the interpretation of the element that contains it" - and I don't see how any rational interpretation of that doesn't depend on the definitions of the relevant elements.
if you're trying to clarify what is obviously a contentious subject, from a methodology prespective, you can't have your cake and eat it too; that will just cause confusion... and here we are.
Lloyd McKenzie (Jul 04 2018 at 22:00):
modifierExtension vs. regular extension is all about "can this be safely ignored, or might ignoring it result in misinterpreatation of the instance". That's why we have the boundary. You can always throw away regular extensions and have no risk of misinterpreting what remains. (Though you might lose 'important' information.) But you can't do that with modifier extensions because the modifier extension might change the interpretation of other information such that if you ignore the modifier extension, you'll misinterpret the information that remains. If you know the meaning of the modifier extension, you can decide that the change in interpretation doesn't matter for your purposes, but it's still a modifier.
If we were to have "focus" as an extension, I can't see how it could possibly be a regular extension that you can strip off and forward the instance and not worry about misinterpretation.
Grahame Grieve (Jul 04 2018 at 22:01):
if we had focus as an extension, then the definition of subject and observation would have to be different, and it would indeed be an extension.
Grahame Grieve (Jul 04 2018 at 22:01):
you're still providing 2 different definitions of ismodifier, and that's why you're creating confusion
Lloyd McKenzie (Jul 04 2018 at 22:01):
"it would indeed be a modifierExtension"?
Grahame Grieve (Jul 04 2018 at 22:01):
oh yes
Lloyd McKenzie (Jul 04 2018 at 22:02):
I think the rules for whether something is a modifier core element vs. a modifier extension need to be identical
Lloyd McKenzie (Jul 04 2018 at 22:02):
Otherwise we're going to cause tremendous confusion
Lloyd McKenzie (Jul 04 2018 at 22:03):
I think I'm providing only one definition. What do you think are my two definitions?
Grahame Grieve (Jul 04 2018 at 22:04):
definition one: can this be safely ignored
definition two: might change the interpretation of other information such that you'll misinterpret the information that remains.
Grahame Grieve (Jul 04 2018 at 22:04):
these are overlapping sets - but not the same thing.
Grahame Grieve (Jul 04 2018 at 22:04):
and until you actually deal with that.... confusion will result
Lloyd McKenzie (Jul 04 2018 at 22:08):
My definition is actually: "An element is a modifier if it cannot safely be ignored because ignoring it may result in misinterpretting the information that remains"
Lloyd McKenzie (Jul 04 2018 at 22:09):
The criteria is "ignoring it may result in misinterpretting the information that remains"
Grahame Grieve (Jul 04 2018 at 22:12):
ok. please clarify which of these 3 is closest to your meaning:
1. An element is a modifier if it cannot safely be ignored because ignoring it may result in misinterpreting the information that remains, based on the definitions of the relevant elements
2. An element is a modifier if it cannot safely be ignored because ignoring it may result in misinterpreting the information that remains, based on the Lloyd's belief about the meaning of the relevant elements
3. An element is a modifier if it cannot safely be ignored because ignoring it may result in misinterpreting the information that remains, based on our worst case assesment of the dumbest user of the resource
Grahame Grieve (Jul 04 2018 at 22:12):
now, to be serious, what we need is an objective criteria. So your definition is not yet satisfactory
Lloyd McKenzie (Jul 04 2018 at 22:13):
We can't take into account the definition of the element being ignored - because the presumption is for a modifier extension, it may not be known.
Grahame Grieve (Jul 04 2018 at 22:13):
"An element is a modifier if it cannot safely be ignored because information in it may mean that the meaning no longer conforms to the stated definitions"
Grahame Grieve (Jul 04 2018 at 22:14):
I hope that the context is that modifierExtension is on an element for which we already have a known definition. We've already agreed to ignore modifiers on tnigs we don't understand
Lloyd McKenzie (Jul 04 2018 at 22:15):
Yes, we can presume we know the meaning of the element the modifier appears on. But I struggle with the notion that the definition of the thing the modifier appears can acknowledge the potential existence of the modifier element and make it no longer a modifier.
Lloyd McKenzie (Jul 04 2018 at 22:17):
Super simple case - negationInd. Lets say that Procedure had a definition "Documents a procedure that occurred or did not occur". And we have an extension that flags that the procedure did not occur.
Grahame Grieve (Jul 04 2018 at 22:17):
so we need to differentiate between what the definition is, and the definition mentioning things that modify it
Grahame Grieve (Jul 04 2018 at 22:17):
then it's not a modifier, since the definition very clearly is 'did or did not occur'
Grahame Grieve (Jul 04 2018 at 22:18):
but I don't see how we could a definition like that, and have 'did not occur' as an extension. that would be clealry wrong
Lloyd McKenzie (Jul 04 2018 at 22:19):
Whether it's an extension or not can't matter
Lloyd McKenzie (Jul 04 2018 at 22:19):
It's a modifier in either case or it's not a modifier in either case.
Lloyd McKenzie (Jul 04 2018 at 22:22):
If, in the base resource, there was no presumption that the procedure had happened, then adding an element that flags "this happened/this didn't happen" would not be a modifier. However, it would have to be explicit either way. If element=true, then didn't happen; if element = false, then did happen; if element absent, then don't know if happened or not.
Rob Hausam (Jul 04 2018 at 22:23):
negationInd is a simple case? - fortunately we don't have it in FHIR :)
Lloyd McKenzie (Jul 04 2018 at 22:23):
But if you're setting a default "if absent, then happened", then the meaning of the resource when ignoring the element is changed when we pay attention to it. And that makes it a modifier.
Grahame Grieve (Jul 04 2018 at 22:23):
I proposed this:
"An element is a modifier if it cannot safely be ignored because information in it may mean that the meaning no longer conforms to the stated definitions"
Grahame Grieve (Jul 04 2018 at 22:23):
can we agree to that?
Lloyd McKenzie (Jul 04 2018 at 22:24):
I don't think so. Because in my example, we're not talking about a variance from stated definitions.
Grahame Grieve (Jul 04 2018 at 22:24):
which example?
Grahame Grieve (Jul 04 2018 at 22:25):
procedure? No, if the definition of the thing is 'did or didn't happen' then an element that tells you whether it did or didn't happen is not a modifier since it clearly doesn't modify the meaning
Rob Hausam (Jul 04 2018 at 22:25):
"the meaning" would need to be much clearer - at the least it would have to be "the meaning of the resource"
Lloyd McKenzie (Jul 04 2018 at 22:26):
And I'm saying that that's only true if the element doesn't have a default
Lloyd McKenzie (Jul 04 2018 at 22:26):
If it has a default, then it must still be a modifier
Grahame Grieve (Jul 04 2018 at 22:26):
well, it won't have a default - we've been clear about that.
Lloyd McKenzie (Jul 04 2018 at 22:26):
.focus does have a default
Lloyd McKenzie (Jul 04 2018 at 22:27):
If it's not present, the focus is the subject.
Grahame Grieve (Jul 04 2018 at 22:27):
"An element is a modifier if it cannot safely be ignored because information in it may mean that the meaning of the instance of the resource no longer conforms to the stated definitions of the elements in the resource"
Grahame Grieve (Jul 04 2018 at 22:27):
that's not a default, that's a meaning if missing. @Eric Haas I mean to say that before: focus clearly must have a meaning if missing.
Rob Hausam (Jul 04 2018 at 22:27):
much clearer
Lloyd McKenzie (Jul 04 2018 at 22:27):
meaning if missing has the same effect
Grahame Grieve (Jul 04 2018 at 22:28):
still, we have to be clear about this: if the definition is 'happened or didn't happen' then elements that pertain to did or didn't happen are not modifier elements, whether present or not or having meaning if missing or not.
Grahame Grieve (Jul 04 2018 at 22:29):
if you're going to propose a second criteria around something being a modifier because of having meaning if missing, I'm all ears
Lloyd McKenzie (Jul 04 2018 at 22:32):
Ok, then lets try that:
"An element is a modifier if it cannot be safely ignored because:
a) its value may cause the intepretation of the containing element or one of its descendants to no longer conform to its stated definition
b) the 'meaning if missing' for the means that ignoring the element may result in a misinterpretation of the containing element or one of its descendants"
Grahame Grieve (Jul 04 2018 at 22:34):
so we seem to have some convergence around (a) which is good
Rob Hausam (Jul 04 2018 at 22:35):
but 'b' isn't so clear
Grahame Grieve (Jul 04 2018 at 22:35):
(b) is interesting. it seems as the element modifies itself
Lloyd McKenzie (Jul 04 2018 at 22:36):
Meaning if missing by definition means "meaning of the containing element if missing"
Grahame Grieve (Jul 04 2018 at 22:37):
umm? really?
Grahame Grieve (Jul 04 2018 at 22:37):
"e Implicit meaning that is to be understood when this element is missing"
Grahame Grieve (Jul 04 2018 at 22:38):
it appears to relate to itself
Lloyd McKenzie (Jul 04 2018 at 22:38):
It has to be the meaning of something that exists - the element itself isn't there.
Grahame Grieve (Jul 04 2018 at 22:41):
still, I'm far from convinced about (b). What makes meaning if missing special?
Lloyd McKenzie (Jul 04 2018 at 22:44):
Let's make .focus an extension. Are we confident that the instance isn't going to be misinterpretted if the extension gets thrown away?
Grahame Grieve (Jul 04 2018 at 22:45):
don't know. what changes to do we make to the definitions when we make it an extension. I can't answer without that knowledge
Lloyd McKenzie (Jul 04 2018 at 22:45):
Throwing an element away means that the difference between the meaning of the element value and the meaning if missing doesn't matter to the interpretation of the rest of the resource.
Grahame Grieve (Jul 04 2018 at 22:46):
where does 'throwing an element away' come into this?
Lloyd McKenzie (Jul 04 2018 at 22:46):
That's what ignoring it does
Lloyd McKenzie (Jul 04 2018 at 22:47):
You treat the instance as if the element doesn't exist. (And in many cases, if you spit out the data to a subsequent consumer, the element won't be there anymore.)
Lloyd McKenzie (Jul 04 2018 at 22:48):
If that just loses data but doesn't make the interpretation of the remaining information inaccurate, it's not a modifier.
Grahame Grieve (Jul 04 2018 at 22:48):
let's just stick to one definition:
An element is a modifier if it cannot be safely ignored because: its value may cause the intepretation of the containing element or one of its descendants to no longer conform to its stated definition
Grahame Grieve (Jul 04 2018 at 22:49):
so, if meaning if missing or one of the possible values meets this criteria, it's a modifier.
Grahame Grieve (Jul 04 2018 at 22:49):
so, then this:
Lloyd McKenzie (Jul 04 2018 at 22:49):
"its value or absense"
Grahame Grieve (Jul 04 2018 at 22:49):
An element is a modifier if it cannot be safely ignored because its value, or it's meaning if missing, may cause the intepretation of the containing element or one of its descendants to no longer conform to its stated definition
Lloyd McKenzie (Jul 04 2018 at 22:52):
I'm struggling because you feel that it's possible to define Observation in such a way that Observation.focus is not a modifier. I don't think that is (or at least should) be possible.
Grahame Grieve (Jul 04 2018 at 22:55):
I believe that's because you don't like the definitions as they are. But as they are ,it's not a modifier. We can talk about the definitions, because they definitely need improving. Now, the can't ignore is in the scope, so for me, 2 things are required for the Observation definitions:
1. a very clear statement in the scope that Observations are linked to individuals, but not necessarily actually made on them, with some examples of where it's not safe to assume this (mother/fetus, conselling, organ donation)
2. a meaning if missing on focus.
Grahame Grieve (Jul 04 2018 at 22:56):
there's other ways to resolve this, but we definitely have a problem right now, in that the impact of a few words in the definition of subject is pretty significant, and it doesn't get the attention it deserves
Lloyd McKenzie (Jul 04 2018 at 22:57):
It has nothing to do with not liking the definitions. I don't think it should matter what the definitions are. If you strip off .focus, you risk misinterpretting the meaning of the resource. Because the meaning of the resource is that the subject is the focus. That's the "meaning if missing"
Grahame Grieve (Jul 04 2018 at 22:58):
I don't think it should matter what the definitions are
It very clearly must. You can't just make stuff up, and as a methodology co-chair you should never say that
Grahame Grieve (Jul 04 2018 at 22:58):
you need to find some soap...
Lloyd McKenzie (Jul 04 2018 at 22:58):
:D
Grahame Grieve (Jul 04 2018 at 22:59):
if you ignore the definitions of Observation, you risk mis-interpreting the observations. duh. maybe we should label the entire spec as 'must-understand'....
Grahame Grieve (Jul 04 2018 at 23:00):
but now, if the definition of Observation is 'pertinent to the patient' and you assume that it is 'on the patient' then you are wrong because you ignored the spec. But if you understand it as 'pertinent to the patient' then that's still true if you drop focus
Grahame Grieve (Jul 04 2018 at 23:01):
so, as the current definitions stand it is no a modifier, but we still have a problem because the current definitions are not what a casual user will expect. Making focus a modifier isn't actually a solution to that bigger problem
Lloyd McKenzie (Jul 04 2018 at 23:02):
I think I can accept that. But then I have a different issue :)
Lloyd McKenzie (Jul 04 2018 at 23:03):
There's two different ways to approach Observation. Have a definition that indicates that subject only indicates who the Observation is "pertinent to" and have focus be a non-modifier; or have a definition that indicates that subject indicates who the Observation was performed on, and have focus be a modifier.
Lloyd McKenzie (Jul 04 2018 at 23:04):
The same can be true for status, didNotOccur and various other elements.
Grahame Grieve (Jul 04 2018 at 23:04):
sure. go have that debate with OO
Grahame Grieve (Jul 04 2018 at 23:04):
I have opinions about that, but only in the sense that I am a domain user of Observation.
Lloyd McKenzie (Jul 04 2018 at 23:05):
We can always have a definition that allows for the elimination of isModifier. Or we can have definitions that require it. What is our guidance on when to do what?
Lloyd McKenzie (Jul 04 2018 at 23:06):
My premise is that it should be what's least surprising to implementers. I'm not sure that's what's happened here.
Grahame Grieve (Jul 04 2018 at 23:08):
from a methodology view point: there are places in the definitions where real life means that the definitions cannot be least surprising to users. When this is true, the committee should be very clear about how and why such surprises have been defined, and expect and cater for community debate about such cases. isModifier is one of the array of definitional tools by which a committee can advise implementers about safe implementations - but only one approach. Other methods the committees should keep in mind:
- make clear statement about this in scope
- provide good examples that illustrate the problem
- consider adding a note to the clinical safety checks in safety.html
- seek comment on this in ballot
Rob Hausam (Jul 04 2018 at 23:09):
I'm not sure which way you're suggesting that your opinions lie on this, Grahame - what do you think is the OO take on it?
Grahame Grieve (Jul 04 2018 at 23:09):
as product manger: OO need to be clearer about this.
as a domain user: I think I'm ok with the definitions as they are
Grahame Grieve (Jul 04 2018 at 23:10):
the surprise is the real world fact that observations are sometimes made on other individuals. Any casual user won't think of that, and it will be a surprise. It's not a surprise that OO invented either. So this is clearly a case where we can't have a least surprising outcome, since the surprise is a real world problem
Lloyd McKenzie (Jul 04 2018 at 23:12):
The question is whether the flag that alerts readers to that potential surprise should be an isModifier flag or carefully crafted definitions and examples. My opinion is that the former doesn't preclude the latter, but the former is the most visible.
Rob Hausam (Jul 04 2018 at 23:13):
agree that we should be clearer
Grahame Grieve (Jul 04 2018 at 23:13):
the other issue we clearly have - which is a little related - is around link/unlink patient records, and mother/child identifications
Grahame Grieve (Jul 04 2018 at 23:13):
that's a PA issue
Grahame Grieve (Jul 04 2018 at 23:13):
actually, I think that a good documentation the observation scope is much better than a isModifier flag. And good wording in the focus definition
Rob Hausam (Jul 04 2018 at 23:14):
agree
Lloyd McKenzie (Jul 04 2018 at 23:18):
I'm not arguing against good documentation in the observation scope. I'm suggesting that belt + suspenders is wise here.
Grahame Grieve (Jul 04 2018 at 23:19):
perhaps, but you can't just have 'ismodifier = true' because Lloyd wants it to be so
Lloyd McKenzie (Jul 04 2018 at 23:32):
I'm not advocating on the basis of "Lloyd wants it". I'm advocating on the basis of "what I think is going to be safest". I've presented my position on why I think isModifier for something like this is safer.
Grahame Grieve (Jul 04 2018 at 23:32):
but to be clear: your position is based on desired outcome, not methodology
Lloyd McKenzie (Jul 04 2018 at 23:36):
Right. There is no established methodology here. If we were to develop methodology, it would presumably be driven by desired outcome.
Grahame Grieve (Jul 04 2018 at 23:39):
yes but it actually needs to be methodological. can you update the google document now that we've had this disucssion, along with that definition at the start?
Lloyd McKenzie (Jul 05 2018 at 01:35):
I've taken my first stab at the changes
John Moehrke (Jul 05 2018 at 13:42):
That was better than the Independence Day Fireworks.... Im with Grahame on this, as I have clearly stated before. I think we need to think differently about core and core extensions; vs any other extension. This is becoming more clear with the current definition. To have a random extension declaring that it's existence has invalidated the core Resource definition or even just some element definition in the core Resource; is BAD modeling. This should be forbidden. If they really have a totally new definition, then they have a totally new Resource.
Lloyd McKenzie (Jul 05 2018 at 13:44):
It has nothing to do with bad modeling - it has to do with meeting real world requirements. If we forget to add the equivalent of "doNotPerform" to a resource and an implementer needs it, we must provide a mechanism of safely meeting that requirement that lets the implementer move forward in a matter of days, not months or years.
Grahame Grieve (Jul 05 2018 at 19:01):
of course we don't like this. But it's the world we live in
Ewout Kramer (Jul 23 2018 at 11:57):
I am sorry I am late to this discussion, but after reading this, I think (putting my developer hat on) I would prefer a section of narrative for each resource that the describes the "tricky"/"ismodifier" elements - and why I need to pay special attention to them, or why disregarding them might be dangerous etc, rather than an abstract flag. The advantage is that many more will actually take action on, and we will also get more feedback on it.
By the way, this (for me) is separate from modifierExtension - where if I don't understand the url I should take action.
Grahame Grieve (Jul 23 2018 at 12:00):
that's a good idea, but I don't know if we'll have time to pull that off for R4
John Moehrke (Jul 23 2018 at 21:32):
Is there a way for an Implementation Guide / StructureDefinition to declare that it allows Extensions that do not have the isMod, but forbids any extensions are isMod? --- (asking for a friend....) :-)
Eric Haas (Jul 23 2018 at 22:17):
using an isMod extension of course!
Grahame Grieve (Jul 23 2018 at 22:25):
the long way is to ban modifierExtensions on every element you profile. That's both exhausting and only deals with what you do profile.
Grahame Grieve (Jul 23 2018 at 22:25):
or you can state it in narrative....
Grahame Grieve (Jul 23 2018 at 22:25):
we can dsicuss better ways
Lloyd McKenzie (Jul 24 2018 at 02:03):
Can't it be done with an invariant? You should be able to assert that the count of descendant modifier extensions (or descendant modifier extensions with URLs other than a specified set) is 0
Grahame Grieve (Jul 24 2018 at 04:36):
yes on every profile
John Moehrke (Jul 24 2018 at 12:03):
If we are going to continue down this path of allowing any random extension to be an isMod.... Then we need a way for an IG to declare that it forbids them. The point of an IG is to define a narrow solution to a given problem. If a random extension with isMod can come along and invalidate the definition of a Resource or an element in a resource... THEN I need a way to say that is forbidden. I need to be able to say this about any random extension with isMod=tru, while allowing any random isMod=false extension. These things are evil to Interop!
John Moehrke (Jul 24 2018 at 12:06):
I will reiterate... We should not allow non-core extensions to be isMod. That is my original solution, it continues to be the solution I think we should go with.
Grahame Grieve (Jul 24 2018 at 12:20):
unfortunately we can't make that rule because projects come up with weird requirements.
Grahame Grieve (Jul 24 2018 at 12:20):
but we can and should make it easy to ban modifier extensinos
John Moehrke (Jul 24 2018 at 12:36):
I am not persuaded that it can't be forbidden. Any project that wants to break the core specification should not be catered to.. but if it is necessary, then please make it easy for a IG profile to forbid them.
John Moehrke (Jul 24 2018 at 12:39):
no one has in this whole stream expressed even ONE valid use-case... just a bunch of "projects will want to do it", or "projects will ignore our rules and do it anyway", or "look at this use-case in the core spec where isMod is used". No evidence that 'any random extension' needs the power to invalidate the specification by adding an extension with isMod=true set.
Grahame Grieve (Jul 24 2018 at 12:41):
umm, it's kind of difficult because we've all worked on projects where we did exactly this for v2 or cda, but for me they've mostly been commercial in confidence
Eric Haas (Jul 24 2018 at 14:36):
I liked Ewout suggestion for isMods ( non extensions )
Eric Haas (Jul 24 2018 at 14:38):
I'm not sure why they should be prohibited by projects. I can think of several like in QI-Core - throwing Bryn under the bus - where they redefine the Subscription.criteria as an event instead of a search string. That seemed pretty necessary IMO.
Eric Haas (Jul 24 2018 at 14:40):
also I added a line to the safety page for Observation.focus (last one) @Grahame Grieve is that what you meant?
Eric Haas (Jul 24 2018 at 14:40):
This is was I think Ewout was suggesting should be on each resource.
John Moehrke (Jul 24 2018 at 15:12):
could you restate what Ewout's suggestion is?
Eric Haas (Jul 24 2018 at 15:48):
Ewout Kramer: I am sorry I am late to this discussion, but after reading this, I think (putting my developer hat on) I would prefer a section of narrative for each resource that the describes the "tricky"/"ismodifier" elements - and why I need to pay special attention to them, or why disregarding them might be dangerous etc, rather than an abstract flag. The advantage is that many more will actually take action on, and we will also get more feedback on it.
By the way, this (for me) is separate from modifierExtension - where if I don't understand the url I should take action.
Grahame Grieve: that's a good idea, but I don't know if we'll have time to pull that off for R4
John Moehrke (Jul 24 2018 at 15:51):
okay, I remember that and agree with it, but i doesn't address the issue I am struggling with. He addresses that the core spec needs to be more clear about each modifier it contains. I agree with that. What I am concerned with is that we are allowing any random extension to be placed into a resource at any random time and with the abstract isMod flag indicate that it has somehow invalidated the meaning of the Resource or some element(s) in the Resource.
John Moehrke (Jul 24 2018 at 15:58):
Im happy to solve one problem at a time.. I am very happy to require that any core or core-extension or hl7-extension that has an modifier element must clearly define that modifier element. This seems to be very clear to me. I don't have an opinion on if these cases should have a isModifier decoration. These publications (core, core-extensions, and hl7-extensions) are easy to find and build into code. My issue is with any random extension from any random publisher with completely unknown governance being able to declare that their extension is an isModifier. And if we insist on giving them this power, I want the ability to forbid that kind of extension in my IG/SD.
Grahame Grieve (Jul 24 2018 at 20:03):
you've said that several times know, and we've agreed that's a good idea. So you probably don't need to keep saying it - maybe it's time to create a task
Lloyd McKenzie (Jul 24 2018 at 20:39):
I don't think isMod should generally be prohibited in projects, but in some cases, it's reasonable to say "this is a modifierExtension free zone" because that's a base expectation for interoperability in that environment. E.g. MHD could say you can't have modifiers on DocumentReference if you want to be MHD-conformant.
John Moehrke (Jul 24 2018 at 21:07):
Last updated: Apr 12 2022 at 19:14 UTC
