Stream: terminology
Topic: HL7 Presentation - Questions
Richard Kavanagh (Feb 09 2020 at 12:18):
Looking back at the slides from DevDay (Amster dam). I am trying to get my head around the two slides attached that show a ValueSet compose statement and subsequent expansion. How does the expansion work when the underlying CoseSystem has no definitions to support the "is-a" filter.
The CoseSystem is at http://hl7.org/fhir/STU3/codesystem-condition-ver-status.json.html
pasted image
pasted image
Rob Hausam (Feb 09 2020 at 13:29):
If you look at the code system resource in R4 you'll see 'provisional' and 'differential' nested under 'unconfirmed' - which is structurally the equivalent of an 'is-a' relationship (although I do note that 'hierarchyMeaning' isn't specified for the condition-ver-status code system - it probably should be).
Grahame Grieve (Feb 09 2020 at 19:58):
make a task to fix that?
Rob Hausam (Feb 10 2020 at 16:09):
Should we have an invariant that says something like "if concept.concept exists then hierarchyMeaning must exist" (we can work out the actual code)?
Grahame Grieve (Feb 10 2020 at 22:54):
CodeSystem.concept.concept.exists() implies hierarchyMeaning.exists()
Michael Lawley (Feb 11 2020 at 03:32):
And similarly if you define values for either of the properties parent or child?
Grahame Grieve (Feb 11 2020 at 04:03):
hmm. thats a more complicated fhirpath
Michael Lawley (Feb 11 2020 at 04:33):
Something like:
CodeSystem.concept.where(property.code = 'parent' or property.code = 'child').empty().not() implies hierarchyMeaning.exists()
?
Rob Hausam (Feb 11 2020 at 06:15):
@Grahame Grieve It seems that we could (should?) remove 'CodeSystem.' and make it:
concept.concept.exists() implies hierarchyMeaning.exists()
And @Michael Lawley, this would be a bit simpler and read more consistently:
concept.where(property.code = 'parent' or property.code = 'child').exists() implies hierarchyMeaning.exists()
Rob Hausam (Feb 11 2020 at 06:48):
Rob Hausam (Feb 13 2020 at 23:28):
We discussed this on the FHIR Tracker Issues call today. There was general support on the call for adding the invariants if we are able to do that. I think this would essentially be a technical correction, as the intent was always that hierarchyMeaning would be populated whenever a code system hierarchy was being represented. But we didn't enforce that rule, and therefore if we start enforcing it now then this non-compatible change will break some of the existing instances (as we have seen) which previously the validator would pass. Since CodeSystem is a normative resource, to be able to make this change we need to determine that "there is a high level of confidence that the change will not impact existing implementers" (or presumably we get agreement from them to make the change even if it does), which requires "broad notification, extensive community consultation and reviews by multiple levels of HL7 governance processes."
So we can start the process here by soliciting comments from the CodeSystem resource implementer community. Please review the tracker and add your comments (I will post a link to this topic on implementers, too). What other steps should we take? @Grahame Grieve @Lloyd McKenzie
Lloyd McKenzie (Feb 13 2020 at 23:37):
Reach out by the product director blog, reach out via the terminology list server, reach out to all contacts you have at organizations that might implement the operation. If you can't get an 'error' invariant approved, we could introduce a 'warning'.
Rob Hausam (Feb 13 2020 at 23:42):
Thanks, Lloyd.
Joel Schneider (Feb 14 2020 at 00:02):
How does/should hierarchyMeaning interact with code systems that have a compositional grammar (compositional = true)?
Apart from the grammar question, for one code system I have in mind the hierarchyMeaning would be grouped-by, which doesn't seem particularly useful.
Grahame Grieve (Feb 14 2020 at 02:11):
you don't have to have a heirarchy. The intent here is just that you should say what it means if you have. Which really seems reasonable
Grahame Grieve (Feb 14 2020 at 02:11):
but given the the specification itself includes code systems marked as normative that don't meet this rule, it really seems like a non-starter to survey the market to me
Rob Hausam (Feb 14 2020 at 04:00):
So what do you think is the best choice, @Grahame Grieve? Should we just target adding the invariants as warnings (which won't break anything), as Lloyd mentioned? Or leave things alone as they are because it's already normative? Or something else?
Grahame Grieve (Feb 14 2020 at 04:08):
definitely do something. definitely add the invariant. for me, as best practice, with a note that they'd be an error but for backward compatibility rules
Last updated: Apr 12 2022 at 19:14 UTC
