Stream: implementers
Topic: is-modifier
Malgorzata Schwab (Jan 02 2018 at 23:02):
Happy New Year!!
For the elements flagged as modifiers (is-modifier set to true), specifically “patient.animal” : The example at https://www.hl7.org/fhir/patient-example.xml.html just skips the animal element. But the conformance link https://www.hl7.org/fhir/conformance-rules.html tells us to have cardinality set to one for such modifiers. What is your advice? Our patients are only humans. Also, can profiles be used to trim out not needed modifiers?
Eric Haas (Jan 02 2018 at 23:13):
isModifier=true SHOULD also have a minimum cardinality of 1, but it is not always the case like this one where it makes no sense to require the element. So Patient.animal is 0..1 and can constrain it away in a profile with a card of 0..0
Lloyd McKenzie (Jan 02 2018 at 23:29):
Typically their minimum cardinality can be 0 if there's a default interpretation to a missing element - as there is for Patient.animal (namely that the patient is a human).
Lloyd McKenzie (Jan 03 2018 at 00:52):
Actually, I mis-spoke. There's no default for Patient.animal. If it's not specified, you don't know if they're an animal or not. There's no way to definitively say that someone is a human. @Brian Postlethwaite ?
Brian Postlethwaite (Jan 03 2018 at 01:28):
I believe that is correct. And for the most part, I'd suggest that it would be assumed.
If you knew it was an animal, but didn't know the details, you'd likely include the animal element with a null flavour indicating that you don't know what type.
Lloyd McKenzie (Jan 03 2018 at 03:12):
If that's the presumption, then it should be stated as "meaning when missing"
Brian Postlethwaite (Jan 03 2018 at 03:24):
If you were a veterinary system, then maybe that assumption is the other way around.
Lloyd McKenzie (Jan 03 2018 at 03:47):
We can't have the default context-specific by sender because as a receiver you don't necessarily have that information. (The only exception we allow is for language, which can be defaulted by national borders and is slightly easier.)
Malgorzata Schwab (Jan 03 2018 at 06:35):
The ElementDefinition.isModifier is set to true has the following effect: "The effect of this is that the element cannot be ignored by systems: they SHALL either recognize the element and process it, and/or a pre-determination has been made that it is not relevant to their particular system." So how can we communicate the pre-determination of non-relevance?
Eric Haas (Jan 03 2018 at 15:54):
A system "...SHALL either recognize the element and process it, and/or a pre-determination has been made that it is not relevant to their particular system." is true for any element for an implementation whether isMod or not.
Lloyd McKenzie (Jan 03 2018 at 16:24):
@Eric Haas Actually, that's not really true. For non-modifiers, an implementer who comes to the spec with a list of 3 elements they want to exchange can map only those elements and safely ignore the rest of the spec except for modifier elements and communicate safely (though they might miss useful "additional" functionality they could have taken advantage of).
@Malgorzata Schwab There's no need to communicate the pre-determination of non-relevance. The determination - and what action is taken based on it - is internal to your system.
Malgorzata Schwab (Jan 03 2018 at 19:33):
So it would be ok just to ignore it, not even implement the animal element. Wouldn't it be elegant to make a profile and trim it out?
Lloyd McKenzie (Jan 03 2018 at 19:44):
Well, first PA needs to decide whether its absense can be presumed to be a default. If they agree there's a default, then yes you can safely constrain it out in a profile. (And given that there are profiles that already do this, that's a strong argument for PA to define such a default...)
Malgorzata Schwab (Jan 03 2018 at 21:10):
PA as ... ?
Lloyd McKenzie (Jan 04 2018 at 01:45):
Sorry. Patient Administration. @Brian Postlethwaite is one of the co-chairs.
Malgorzata Schwab (Jan 05 2018 at 17:32):
when can we expect a decision?
Lloyd McKenzie (Jan 05 2018 at 17:42):
Decision - I would hope by end of the WGM, which is first week of Feb. However, R4 - which will reflect the decision - won't be published until end-of-year. If you're implementing based on R2 or R3, you can constrain it out, but there's at least some risk of misinterpretation.
Brian Postlethwaite (Jan 05 2018 at 22:43):
Can we please get a tracker logged for this on gforge (link at the bottom of the patient page - or any page for that matter)
Thanks.
Lloyd McKenzie (Jan 06 2018 at 03:55):
Last updated: Apr 12 2022 at 19:14 UTC
