Stream: terminology
Topic: Terminology methodology items
Lloyd McKenzie (Jul 11 2018 at 22:45):
At the Roundtable in Cologne, we introduced two methodology items that were related to terminology. I agreed to write up some proposed formal methodology related to them. I have finally done so. Opinions/discussion welcome:
http://wiki.hl7.org/index.php?title=FHIR_Guide_to_Designing_Resources#What_coded_data_type_should_be_used.3F
http://wiki.hl7.org/index.php?title=FHIR_Guide_to_Designing_Resources#What_should_the_binding_strength_be.3F
Lloyd McKenzie (Jul 11 2018 at 22:45):
@Jay Lyle @Ioana Singureanu @Grahame Grieve
Richard Townley-O'Neill (Jul 12 2018 at 00:10):
Nice work.
Consider moving the final note, starting "The use of required and extensible bindings...", to before Preferred.
Lloyd McKenzie (Jul 12 2018 at 01:12):
Done
John Moehrke (Jul 12 2018 at 12:29):
Well done. I think you need a bit more on when Coding should be used. I don't see a distinction described, it seems to be outright discouraged completely. or is that your intent
John Moehrke (Jul 12 2018 at 12:29):
The first sentence of your binding strength section is muddled @Lloyd McKenzie
John Moehrke (Jul 12 2018 at 12:35):
Item 3 of "Required". Should you insert the word "acceptable" in the sentence -- "This mapping may involve some _acceptable_ loss of granularity." ?
Eric Haas (Jul 12 2018 at 13:47):
for CC I think this should be added to this bit... ` for non-required bindings, allows for text only representation instead when no code is available'
" also provides for text representation to convey what the data enterer actually saw/typed, which is particularly useful when more detail is required than is possible with a code."
Eric Haas (Jul 12 2018 at 13:52):
I think Coding use case was nailed. its the hardest to use maybe add Q.item.choice.valueCoding as an example?
Eric Haas (Jul 12 2018 at 14:08):
Re preferred - The only reason I make an binding preferred is because could not get consensus to make it extensible. So I would define it as a set up concepts considered for extensible binding but lacking sufficient consensus to become extensible. Since there is no way to enforce it should be noted that the extra effort to create a preferred vs example may not be justified.
Eric Haas (Jul 12 2018 at 14:13):
(People love making bindings preferred, especially if they have no skin in the game. Its a feel good binding.)
Lloyd McKenzie (Jul 12 2018 at 14:57):
@John Moehrke I've added a bit more on Coding, but yes the gist is that it's discouraged.
Revamped the first sentence
I don't want to add "acceptable" because that's hugely subjective. The "minimum" is established by the previous bullet which sets the objective of granularity for useful interoperability for most usecases
Also added something explicit for support across countries
Lloyd McKenzie (Jul 12 2018 at 15:16):
@Eric Haas added something about text only. Made it more generic as it's not just required bindings that can limit it. There are rules for extensible too.
I'm not sure that Q.item.choice.valueCoding would necessarily help people. I didn't find any examples of usage that I felt would add more clarity than confusion
In terms of preferred, I think "consensus" isn't a driving part of the definition. If you can come up with a value set that covers the space, is freely available and that everyone can reasonably map to, then from a methodology perspective it should be required/extensible. The question is whether there's consensus on whether it's reasonable to map. I did add some language about consensus in the face of multiple suitable value sets.
I disagree that Preferred is only feel good. It sets a target for those who want to maximize interoperabilty. If you map to and from the preferred value set you'll get much better interoperability than going your own way. Setting that expectation is useful for the community. I've added a note to that effect
Lloyd McKenzie (Jul 12 2018 at 15:16):
(Thanks both for the feedback)
Eric Haas (Jul 12 2018 at 15:29):
Thanks for updating this Lloyd. Methodology and real world limitation do sometimes clash. I'm not sure whether is appropriate to document, but am sharing my experience.
Lloyd McKenzie (Jul 12 2018 at 15:30):
Understand that the real world always intervenes :)
Jay Lyle (Jul 13 2018 at 16:26):
Type
Very good; case statement is a nice heuristic.
issue: "The work group does not see a likelihood for 'most' systems to need to convey alternate..."
I think it needs to be pretty well locked down for this.
"The work group believes it is extremely unlikely that other values will be required by more than a few systems, and less likely their partners will share this need."
Would an example help; e.g., "a status that tells me whether a condition should appear on an active problem list (active), a history (inactive), or only an audit report (error) seems like a good candidate for a 'code.' A status that delves into clinical distinctions of remission vs. resolution or levels of control will require more flexibility." (this example pending wg resolution, next week I hope)
Strength
I don't know if this is the place to do it, but I can't find explicit guidance around binding strength and versions. Some of this text suggests that a (normative) binding to an unversioned value set implies that the set cannot change, but the value set design says that unspecified version just means "get the latest."
Lloyd McKenzie (Jul 13 2018 at 18:56):
If the data type for a fixed binding is "code", you're locked to the version as it was published in the same release as the structure definition. However, it would be good if the tooling made that explicit - can you submit a change request?
In terms of CodeableConcept, I'd say the heuristic is "follow the 80% rule" - if most systems are going to need translations or text, make it a CodeableConcept. But if it's not that common to need to share additional granularity/alternate representations, 'code' is fine.
Jay Lyle (Jul 13 2018 at 19:25):
OK: 17480
Rob Hausam (Jul 14 2018 at 12:32):
Minor omission - need to add the word 'to':
The Coding data type should only be used when the intention is to reference a specific code from a code system ...
Robert McClure (Jul 16 2018 at 13:02):
@Lloyd McKenzie @Jay Lyle @Rob Hausam @Eric Haas Also agree this is good. It is missing one important thing that is a general item with a big impact (Jay alluded to this in his comment): We bind to value set definitions, but people actually use value set expansions. I think a section on this is really important. I don't have the text to suggest at this moment but will work on it. Perhaps in addition to a general section, we should also add a sentence in the Note section for Required and Extensible on the impact of version changes (value set definition and code system) to the usable expansion. I'm interested in what the folks on this thread already assume should be happening in this space - I suspect we are not yet all in synch.
Lloyd McKenzie (Jul 16 2018 at 23:18):
Hi @Robert McClure, I've added some wording in the data type choice section that addresses this. Special behavior around expansions is only driven by the 'code' data type. It's not influenced by binding strength.
Lloyd McKenzie (Jul 16 2018 at 23:18):
If you have a fixed binding for a CodeableConcept, the value set expansion is not locked.
Lloyd McKenzie (Jul 16 2018 at 23:18):
(One of the reasons why the use of the 'code' data type is important...)
Robert McClure (Jul 17 2018 at 16:45):
That's fine for the data type section, but we also need to make it crystal clear in the binding strength section that all bindings, including 'Required', do not lock the value set expansion to a specific member set unless both the value set definition version and the code system version are also specified somehow in the specification.
Lloyd McKenzie (Jul 17 2018 at 18:46):
Could be multiple value set versions and code system versions. But whether the value set is locked or not has no impact on the selection of binding strength or data type beyond what was added to talk about 'code'. We could add a new section on the design of the value set to be bound (which can talk about extensional vs. intensional, lockedDate, version-specific references, etc. And I don't know that we have specific methodologic guidance to offer here yet...
Last updated: Apr 12 2022 at 19:14 UTC
