FHIR Chat · R4B questions / issues

I've finally spent some quality time with the latest R4B draft. I've catalogued a number of issues locally and today I'm trying to open Jira issues for the ones that make sense. I think I will post questions/discussions in this thread for the superset (assuming that is helpful for folks). Or maybe I should start a separate topic for each one?

High-level summary:

duplicate version suffix in canonical reference values
potentially bad invariant in RatioRange
clarification on RatioRange and CodeableReference data types in "open" choice types
codesystem-FHIR-version: removes "4.0.1" and replaces it with "4.1.0" ...shouldn't it be additive?
codesystem-remittance-outcome: removes "queued" ...I'd consider that a breaking change to ExplanationOfBenefit, ClaimResponse, CoverageEligibilityResponse, EnrollmentResponse, and PaymentReconciliation
ValueSets ConceptSubsumptionOutcome and StandardsStatus are missing in R4B; and ValueSet StatisticsCode is invalid
ResourceTypes Codesystem contains duplicate entries

I havn't checked whether any of these apply to R5 as well, but some of them may.

Vadim Peretokin (Dec 08 2021 at 13:40):

I'd say a separate topic for each is better - otherwise the discussion would be hard to follow.

Josh Mandel (Dec 08 2021 at 14:18):

@Lee Surprenant these are great finds, thank you! Meta question: can you talk about your methods of investigation? E.f., should we expect that since you found one surprising ValueSet change, there are no others lurking?

Lee Surprenant (Dec 08 2021 at 14:19):

I'm going through the exercise of updating our fhir server implementation (on a branch), so thats how I found these.

Lee Surprenant (Dec 08 2021 at 14:20):

I regenerated our model classes and checked the diffs. We use enums for required code bindings and so the diff was pretty clear on those.

Lee Surprenant (Dec 08 2021 at 14:21):

there's others I've opened previously as well (which aren't fixed yet)...maybe I'll go find those and mention them here just so i have a single list i'm tracking :-)

Lee Surprenant (Dec 08 2021 at 14:31):

ok, i added the main one i was thinking of and linked them to the various topics

Lee Surprenant (Dec 08 2021 at 18:11):

A similar, but more acceptable, set of CodeSystem changes that I would consider "backwards-breaking" is in the foundational resource types.
To align with the updates to this version of FHIR, concepts have been removed from the following ValueSets:

These (at least the ResourceType one) have required bindings from many foundation resources like OperationDefinition, StructureDefinition, ElementDefinition, MessageDefinition, CapabilityStatement, SearchParameter, Questionnaire, CompartmentDefinition.

Presumably we wouldn't expect conformance artifacts like these that are valid in R4 to also be valid in R4B, right?
Are we comfortable saying a valid R4 Questionnaire may not be a valid R4B Questionnaire (even though the chances of having one that references one of the removed resource types is extremely slim)?

Grahame Grieve (Dec 08 2021 at 18:31):

those particular value sets are version specific, and will change. But what's been deleted from data types?

Grahame Grieve (Dec 08 2021 at 18:33):

ah SubstanceAmount. yes, that's fine.

Lee Surprenant (Dec 08 2021 at 18:50):

yep, they even have this nice warning:

This Value Set is normative - it is generated based on the information defined in this specification. The definition will remain fixed across versions, but the actual contents will change from version to version

I assume "The definition will remain fixed across versions" is just saying concepts won't change meaning (so CodeSystem.versionNeeded=false)?

Grahame Grieve (Dec 08 2021 at 18:52):

yes

Lee Surprenant (Dec 08 2021 at 18:53):

Ok, thanks. I wasn't too concerned about any of the resource types I listed there...Questionnaire seemed the most iffy which is why I singled that one out in my question, which is sort of me just testing the boundaries of this statement from Josh:

Valid R4 resources should absolutely be valid R4B resources.

Safe to assume my answer is "we are comfortable with these potentially breaking changes", so no need to open an issue for this one?

Grahame Grieve (Dec 08 2021 at 18:58):

yes. in the corner case that you were writing a questionnaire with a subjectType of a resourceType like MedicinalProductPackaged, it couldn't be valid in R4B.

Lee Surprenant (Dec 10 2021 at 20:52):

A few more tidbits from the investigation: was going through the examples zip downloaded from https://build.fhir.org/branches/R4B/downloads.html and seeing a lot of issues. So far, the leading two causes I've seen are the following:

Somewhere between R4 and the latest draft at build.fhir.org, the value at http://hl7.org/fhir/extension-structuredefinition-fhir-type.html got flipped from url to uri. In R4B, the definition is still url but almost all the StructureDefinition examples use uri.
LOTS of ValueSets that claim conformance to http://hl7.org/fhir/StructureDefinition/shareablevalueset but are missing the required element experimental

Lee Surprenant (Dec 10 2021 at 22:08):

opened FHIR#34449 for the former and FHIR#34450 for the latter. a lot of questionnaire examples are still invalid from FHIR#24080 as well (already marked Resolved - change required)

Gino Canessa (Dec 13 2021 at 18:26):

@Lee Surprenant , I think FHIR-34449 is covered by FHIR-31733 (and the linked FHIR-32105 ). Is that correct?

Lee Surprenant (Dec 13 2021 at 18:43):

Thanks Gino. I did search Jira for some of these but must not have searched for this one. Will close 34449 as a duplicate of 32105

Gino Canessa (Dec 13 2021 at 18:46):

No problem! I did the same thing when I missed 32105 (it's a lot easier to catch when you file the ticket =).

Lee Surprenant (Dec 13 2021 at 18:48):

in 32105 there is a "Resolution Description" of:

While this should be URI, we've lived with it as URL for quite a while and it's going to break lots of tooling to change, and we've decided it doesn't much matter. We'll never encounter a URN, so URL is ok. We will correct the values in the instance to use valueUrl.

However, there is also this comment from Lloyd:

Reverted previous resolution: Persuasive with Modification made 2021-05-24 00:00:00.0 with vote Ewout Kramer/Michael Donnelly: 22-0-1//(Impact: Non-substantive; Category: Correction; Version: null)//Will correct the extension definition to be uri rather than url

I assume the Resolution Description text is the NEW resolution and that the "Will correct the extension definition to be uri rather than url" in the comment from Lloyd was the old resolution that will be reverted...does that sound right?

Lee Surprenant (Dec 13 2021 at 18:52):

Never mind, I confirmed that understanding by looking at the issue's history (it changed 9 minutes after the original resolution was approved :-). FWIW I think its the right decision though.

Lee Surprenant (Dec 13 2021 at 19:15):

Just opened another one; hopefully not another dup: Apply eld-17 update to allow targetProfile for CodeableReference in R4B

Grahame Grieve (Dec 14 2021 at 20:40):

ok all addressed - there'll be a new R4B posted just as soon as sonatype starts working so I can release new build tools

Lee Surprenant (Dec 14 2021 at 21:03):

awesome, thanks grahame!

Lee Surprenant (Dec 16 2021 at 02:24):

The two technical corrections (from the list at https://build.fhir.org/branches/R4B/ballot-intro.html) that I've seen break tests so far are:

FHIR-28312 - Corrected type for 'profile' parameter in $validate operation to be canonical, not uri (aside: why is this listed under StructureDefinition?)
FHIR-28415 - Corrected Schematron XPath for drt-1 constraint (the description says its for the XPath but the FHIRPath constraint got updated too)

Lee Surprenant (Dec 16 2021 at 02:25):

On 28312, this is a backwards-breaking change to the $validate operation which clients must be aware of (or else they will continue passing a uri where its now expecting a canonical).

On 28415, the old expression allowed a Duration with a value and a unit (but no coded unit) whereas the new expression does not. Note that this change actually broke one of the spec examples (or helped identify a broken example...depending how you want to look at it): FHIR#34465

I think I'm OK with both of these; I just wanted to document my experience here / give others a heads up.

Lee Surprenant (Dec 16 2021 at 16:14):

This one wasn't one of mine, but I'll mention it here because I don't think the change has been applied yet (at least not fully) and it would be nice to have ClinicalUseIssue totally gone before the connectathon snapshot is made: https://jira.hl7.org/browse/FHIR-31847

Lee Surprenant (Dec 16 2021 at 16:17):

https://jira.hl7.org/browse/FHIR-34445 is a minor related issue that I opened but didn't bother mentioning above because the fix/workaround is so simple

Rik Smithies (Dec 16 2021 at 16:23):

It would be great to get rid of ClinicalUseIssue and I have tried, several times. I have removed every reference to it in a local build (grep'ed every file), deleted everything I can find and it will not build without it. A circular dependency or something strange. Maybe now that the links to it have gone and the build has happened a few times, removing it again will work.

Grahame Grieve (Dec 16 2021 at 18:54):

I have posted my release candidate to build.fhir.org at https://build.fhir.org/branches/R4B/index.html. There's a few hours to do more QA, and I'll look at the last few issues raised here

Grahame Grieve (Dec 16 2021 at 19:13):

FHIR-28312 - must clients invoke this as a simple URL parameter, so won't notice the difference. I don't know if we can require servers to continue to accept url as well as canonical?

Grahame Grieve (Dec 16 2021 at 19:28):

@Rik Smithies FHIR-34465 is a more general issue: you are not coding your example quantities, just using UCUM units in the human readable units. Please review all of your examples and make your UCUM units explicit - people are very much guided by the examples. And the area you are working in, processible units seems like a very necessary thing

Rik Smithies (Dec 17 2021 at 10:35):

done. thanks

Grahame Grieve (Dec 17 2021 at 12:45):

but it did miss my final build, so that will not be part of the snapshot

Lee Surprenant (Jan 19 2022 at 17:22):

process question: if some of my tickets are pre-applied in R4B and I've confirmed that the issues have been addressed...should I close the ticket myself or wait for some HL7 WG to review what was done?

Josh Mandel (Jan 19 2022 at 17:35):

Has the workgroup voted on these tickets? If so, we'll want to hit the "Applied" button rather than closing:
image.png

Lee Surprenant (Jan 19 2022 at 17:41):

my understanding is that they were preapplied by grahame to get a good snapshot for connectathon and HAVE NOT been voted

Josh Mandel (Jan 19 2022 at 18:58):

Okay, in this context if you are happy with the current state I don't think we need to proceed with and it seems fair to close. I will note that #fhir/infrastructure-wg is the best place for discussion on these points

Lee Surprenant (Mar 10 2022 at 02:33):

Today I hit an interesting issue that I missed in my first go-around with R4B and so I thought I'd share it here:
Most references to codesystems that are external to FHIR (and especially to v3 codesystems) have binding strength "Example" and we don't really do anything with those.
However, in at least one case, there is an Extensible binding to a v3 CodeSystem in a resource type that we care about:
http://hl7.org/fhir/r4/explanationofbenefit-definitions.html#ExplanationOfBenefit.accident.type

In R4, those v3 CodeSystems were included with the definitions from the downloads page of the FHIR spec and the hierarchy in them was modeled as a set of nested codes.
In R4B, the v3 CodeSystems are not included and so you need to get those from https://terminology.hl7.org separately.
In this particular case, the valueSet has the following include filter:

      {
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
        "filter" : [
          {
            "property" : "concept",
            "op" : "is-a",
            "value" : "_ActIncidentCode"
          }
        ]
      }

Our server has support for expanding these from CodeSystems, but for some reason it wasn't working...
it turns out that the newer v3 CodeSystem resources like this one no longer nest the concepts and now they only express the hierarchy through a property named "subsumedBy".

Lee Surprenant (Mar 10 2022 at 12:27):

Update: while the v2 and v3 ValueSet and CodeSystem resources are no longer available in the "definitions" download, I found that most of them are available in the ValueSet expansions download linked to under Code Generation Support from https://build.fhir.org/branches/R4B/downloads.html (including the v3-ActCode one mentioned above). And because they are listed in their expanded form, we might get away with not packaging the corresponding CodeSystem or being able to expand the ValueSets ourselves.

Lee Surprenant (Mar 10 2022 at 12:50):

I said most of them above because I thought we were missing a couple expansions for bindings from the Patient resource, but I looked again and the ValueSet expansions file does have those.

Lee Surprenant (Mar 10 2022 at 12:51):

Also worth mentioning that this extensions download file has validation issues: FHIR-36244

Gino Canessa (Mar 10 2022 at 15:49):

I have taken to downloading/parsing/loading the matching .expansions package for any request on a .core package by default. I did not like the initial 'feel' of doing it (feels like defeat! ;-), but it has proven to be generally easier.

Probably preaching to the choir here, but the biggest gotcha I ran into is 'partial' expansions included in the package, signified by ValueSet.expansion.parameter.name=limitedExpansion and/or extensions on ValueSet.expansion of .../valueset-toocostly and .../valueset-unclosed). Looking up the literals in ValueSet-ucum-units.json also shows that there is no constraint for repeated values in expansion.parameters, but at least they are all duplicate values that match? =)

Grahame Grieve (Mar 10 2022 at 19:41):

it turns out that the newer v3 CodeSystem resources like this one no longer nest the concepts and now they only express the hierarchy through a property named "subsumedBy".

not the newer ones, but the ones that have a poly-heirarchy, which ActCode does. So @Lee Surprenant either you can handle those, or you fall back to the .expansions package, which is provided to help code generators that do not have a terminology server to depend on. And the value sets in the .expansions are intentionally limited to required bindings

Lee Surprenant (Mar 11 2022 at 13:13):

I guess that makes sense. I just wish there was a standard property name that we could rely on...its confusing to me that the CodeSystem properties are defined via some optional URI field... how are we supposed to know that "subsumedBy" is the one to use for hierarchy in this case?

Lee Surprenant (Mar 11 2022 at 13:14):

I have taken to downloading/parsing/loading the matching .expansions package for any request on a .core package by default.

I was just starting to think this is the best option. But one aspect I didn't appreciate until our failing unit tests: we need to be able to traverse the hierarchy to support the :above and :below token parameter modifiers

Lee Surprenant (Mar 11 2022 at 13:59):

OK, now here is an interesting one: I was poking around the R4B valuesets download (trying to see how many terminology.hl7.org CodeSystems were referenced) and I noticed these two codesystem urls that don't look quite right:

FHIR-defined systems usually have a prefix like http://hl7.org/fhir and external hl7 systems are usually http://terminology.hl7.org/CodeSystem but, just for these two, there is an extra /fhir on the path. JIRA issue?

Lee Surprenant (Mar 11 2022 at 14:11):

FHIR-36259

Lee Surprenant (Mar 14 2022 at 19:49):

And the value sets in the .expansions are intentionally limited to required bindings

But not the required bindings from core spec extensions apparently. Just bumped into that while validating a couple examples that have this one: https://build.fhir.org/branches/R4B/extension-family-member-history-genetics-parent.json.html (because I didn't have the expanded http://hl7.org/fhir/ValueSet/parent-relationship-codes )

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · R4B questions / issues · implementers

Stream: implementers

Topic: R4B questions / issues

Lee Surprenant (Dec 08 2021 at 13:17):