FHIR Chat · v2 conformance mapping to FHIR

Summary of my perspective on this morning's discussion:

We should not define an extension that conveys codes that are redundant with information already expressed in normative elements on ElementDefinition, particularly when those codes don't cover the full set of permitted combinations and/or will cause implementers to misinterpret meaning given that behavior in v2 and FHIR are different. The v2 codes do not provide computable capability that doesn't already exist in FHIR.
There should be clear documentation added to the FHIR spec in the comparison-v2 page in the FHIR spec that explains the relationships between v2 conformance concepts and FHIR conformance concepts so that readers familiar with v2 understand the relationship (and why FHIR expresses information differently)
FHIR-I should consider whether there is sufficient value to outweigh the risks associated with defining a 'simple' way to flag an element as not permitting extensions (which is what most people mean when they say "this element can't be null", though the meaning is actually quite different.)
Either FHIR-I or Conformance should consider defining a 0..* CodeableConcept element that can express mustSupport semantics. Possible codes would convey things like "must persist", "must display to user", "must allow user to specify", "must consider in logic", etc. (Note that these codes should not deal with what can/must appear in an instance.)

Grahame Grieve (Sep 22 2020 at 17:17):

with regard to #4 the first thing to do is to code up with a proposed code system

Grahame Grieve (Sep 22 2020 at 17:18):

There's already a clear and simple way to say that an element can't have extensions which is to set .extension max = 0. So what would #3 achieve?

Grahame Grieve (Sep 22 2020 at 17:22):

are we after an authoring short cut?

Lloyd McKenzie (Sep 22 2020 at 17:35):

It would be an authoring short-cut, yes - that wouldn't look so ugly in the snapshot view. (Because if you constrain extension (and modifierExtension) to max=0, then everything else gets listed in the snapshot

Lloyd McKenzie (Sep 22 2020 at 17:37):

Of course, providing a shortcut to do something that's generally a bad idea is not necessarily a good thing...

Grahame Grieve (Sep 22 2020 at 17:37):

if you want to change the presentation, that's not an authoring short cut then. that's something else

Grahame Grieve (Sep 22 2020 at 17:39):

I think that I could do that automatically, if people wanted - detect that the only changes made when walking into a type are to ban extensions, and present appropriately

Lloyd McKenzie (Sep 22 2020 at 17:39):

It's a bit of both, I think, but presentation would be most relevant

Grahame Grieve (Sep 22 2020 at 17:42):

do we have any profiles that do this now as a reference?

Lloyd McKenzie (Sep 22 2020 at 18:01):

Don't think so - which is good. Because preventing extensions is generally not good.

Lloyd McKenzie (Sep 22 2020 at 18:02):

Da Vinci probably wouldn't ever prohibit extensions, but there might be some places where they'd want to make value mandatory

Robert Scanlon (Sep 22 2020 at 18:04):

I interpreted 'mandatory' as value not null, not that extensions are disallowed (though perhaps I misinterpreted). If you really wanted to prevent null values, could you do that with an invariant?

Grahame Grieve (Sep 22 2020 at 18:07):

you could but the canonical way is to just to say what you mean: set .value to min = 1

Craig Newman (Sep 22 2020 at 18:09):

Is there somewhere that explicitly states that the presence of the Data Absent Reason alone does (or does not) fulfill the requirement that an element, when present (ie, as one with a minimum cardinality of 1 needs to be) "SHALL have a value attribute, child elements, or extensions"?

Grahame Grieve (Sep 22 2020 at 18:10):

there is nothing that makes any explicit statement like that about one particular extension.

Craig Newman (Sep 22 2020 at 18:11):

Does that mean that the presence of the Data Absence Reason extension is sufficient to meet that requirement?

Grahame Grieve (Sep 22 2020 at 18:12):

it would follow as given that an extension fulfills there requirement that an element SHALL have a value attribute, child elements, or extensions, since it is an extension

Grahame Grieve (Sep 22 2020 at 18:44):

I think that i should alert you to the fact that the data absent reason extension is far from special in the context of FHIR- there is plenty of other extensions that may or may not substitute for a value in some way

Lloyd McKenzie (Sep 22 2020 at 18:45):

There's no such thing as "null value" in FHIR - you're not allowed to have an element that's empty. For simple types, you must either have a value or extensions. For complex types, you must have either components or extensions

Lloyd McKenzie (Sep 22 2020 at 18:47):

There's nothing magic about "data absent reason". There are all sorts of extensions that could be sent on a mandatory element that would let you avoid populating 'value'. Some might actually convey a value in another form. Others might explain why a value is absent. Others might say nothing useful at all and just be a work-around to satisfy the validator. All are legal.

Lloyd McKenzie (Sep 22 2020 at 18:48):

Also, what's historically considered a 'null' in v3 and v2 can actually be a proper value. So if I send a Patient.gender with a value of "unknown", that's just as 'null' as if I send a Patient.name with an extension that says "unknown".

Lloyd McKenzie (Sep 22 2020 at 19:27):

I think the underlying issue here is that sometimes we want to say "there must be a value here". That's easy to understand for 'simple' types. It's more complicated for complex types. But having an easy way to assert that and render that would be useful. Along with clear guidance on when it's appropriate (and not appropriate) to set such a flag would potentially be a good thing.

Grahame Grieve (Sep 22 2020 at 19:36):

well, now i'm back to agreeing with this:

whether there is sufficient value to outweigh the risks

because there's a way to say whatever you want right now, and any easy short cut is basically only easy because you're being ambiguous

Craig Newman (Sep 22 2020 at 21:20):

I agree that there are many ways to send "null" including value sets and in many cases these "null" values are perfectly valid and useful. The reason the Data Absent Reason extension does seem "special" to me is that it is part of the core standard and that by definition it seems (to me at least) that this extension would only be used when there is no value attribute, child element or extension other than this one. So by it's existence it provides an HL7 provided way to avoid the spirit (as I perceive it - which may be wrong) of a 1..x cardinality where there is a use case for the element to always be populated.

Grahame Grieve (Sep 22 2020 at 21:22):

it's in core, yes. But it's not the only extension that's relevant here. This discussion is inappropriately focused on the one extension. There's these possibilities:

the data is absent for some reason
the data is this string I don't know how to present properly
the data can be calculated with this expression, if you know some other value(s)
the data is here in the wrong code system

I can never tell which of these possibilities you intend to cover or not.

Craig Newman (Sep 22 2020 at 21:22):

For example, in an IG if I want to indicate that an Immunization resource where Immunization.vaccineCode which only contains the Data Absent Reason extension should not be sent, is my only option to constrain away the ability to use any extension on this element? I agree that unless I do that, an implementer can always come up with their own extension to do the same basic think, but I suspect that many implementers will feel less "guilty" about using the Data Absent Reason extension because it's part of the base standard than they would if they defined their own extension.

Grahame Grieve (Sep 22 2020 at 21:23):

is my only option to constrain away the ability to use any extension on this element

no, it's certainly not. you can prohibit the use of that particular extension

Craig Newman (Sep 22 2020 at 21:24):

OK, I didn't know you could get that specific

Craig Newman (Sep 22 2020 at 21:26):

I still have a nagging feeling that "absent" is a bit different from "can't be expressed as required by the resource definition" but I guess ultimately, they are functionally similar

Grahame Grieve (Sep 22 2020 at 21:27):

that depends. Which is why the discussion shouldn't be obsessed with a single extension

Lloyd McKenzie (Sep 22 2020 at 21:36):

However, prohibiting the HL7 core dataAbsentReason extension won't keep someone from sending their own local dataAbsentReasonPlus extension that does exactly the same thing

Lloyd McKenzie (Sep 22 2020 at 21:37):

So there's no practical mechanism to allow certain classes of extensions while prohibiting other classes of extensions - in part because there's no current way of classifying extensions (and I'm not terribly confident that we could come up with a workable and reliable classification mechanism if we wanted one).

Richard Townley-O'Neill (Sep 24 2020 at 04:14):

On item 3, I would think that generally what is required is a value, so make value required rather than prohibiting extensions.

Grahame Grieve (Sep 24 2020 at 06:12):

that works for simple data types, but not for others, such as HumanName, Address, Coding, CodeableConcept, Quantity

Craig Newman (Sep 24 2020 at 13:12):

Richard Townley-O'Neill said: