Stream: IPS
Topic: Condition.code
Joel Francis (Aug 23 2021 at 13:27):
Hello @Rob Hausam and @Giorgio Cangioli
Looking for clarification on the Condition.code element (http://hl7.org/fhir/uv/ips/StructureDefinition-Condition-uv-ips.html)
-
If providing data for the element:
If a condition is present, is must be drawn from the required IPSGPCode ValueSet. Please confirm
No other free text or code from another ValueSet can be used. Please confirm -
How to use the second slice absent or unknown problem. Is is that I have to use either slice?
Thanks in advance,
Joel Francis
Yunwei Wang (Aug 25 2021 at 13:37):
My understanding is that this slice is the same as an extensible binding on a combined valueset of the two value sets in the slices.
@Rob Hausam
Rob Hausam (Aug 25 2021 at 13:49):
@Joel Francis Sorry for not getting to this until now. I basically agree with what @Yunwei Wang said - except that I think it would be better to describe it as "the slices are functionally equivalent to" (rather than "this slice is the same as"). So it would read as "My understanding is that the slices are functionally equivalent to an extensible binding on a combined valueset of the two value sets in the slices."
And I think this is pointing out further that presentation of this using slicing isn't really as clear as I have been imagining it to be. We definitely need this to be clear for the IPS implementer community, so we need to be presenting it in a simple and straightforward way.
Rob Hausam (Aug 25 2021 at 13:58):
So the answer to question #1 is no, it isn't required to draw a code from either of the value sets bound in the slices (as it functions similar to "extensible", as Yunwei said). And the answer to question #2 is not that you have to, but that you can use a code from either slice (or a code that isn't in either of the slices if you need to).
Rob Hausam (Aug 25 2021 at 14:13):
Actually, I just also realized that actually the behavior is more like a "preferred" binding (rather than "extensible"), as there are no conformance expectations that you must use a code from either of the defined slices. We're hoping to be able to tighten that when needed (e.g. the "cross border" profiles) in the STU update, but that's not the case in the published version.
Joel Francis (Aug 25 2021 at 14:13):
Rob Hausam said:
So the answer to question #1 is no, it isn't required to draw a code from either of the value sets bound in the slices (as it functions similar to "extensible", as Yunwei said). And the answer to question #2 is not that you have to, but that you can use a code from either slice (or a code that isn't in either of the slices if you need to).
Thanks @Rob Hausam and @Yunwei Wang . As per what you have clarified. Does it break FHIR compliance and Semantic compliance to have a code like "Free_text" and populate the text filed of the CodeableConcept with non-coded data?
Rob Hausam (Aug 25 2021 at 14:17):
No, that's also legal, at least technically (whether it is very good vocabulary practice is another matter). As you know we're working on determining the "best" way to do that in the updated version.
Joel Francis (Aug 25 2021 at 16:58):
Rob Hausam said:
No, that's also legal, at least technically (whether it is very good vocabulary practice is another matter). As you know we're working on determining the "best" way to do that in the updated version.
Thanks @Rob Hausam . While relaxing the bindings where "required" breaks FHIR compliance, Is is possible to add additional slices where needed?
I realize that adding extra slices may not break FHIR compliance, in certain cases additional critical data may be part of these slices and may be ignored if receiving systems require a pure IPS.
Yunwei Wang (Aug 25 2021 at 18:50):
Yes, this slicing is "open" which means new slices can be added.
Rob Hausam (Aug 25 2021 at 19:09):
Correct.
Richard Townley-O'Neill (Aug 25 2021 at 23:37):
I read the profile as also saying that implementers must support those slices, whatever "must support" is defined to mean. And there is no guidance on the need for implementers to support values of code that meet neither slice.
Richard Townley-O'Neill (Aug 25 2021 at 23:38):
Is that what is wanted?
Mareike Przysucha (Aug 26 2021 at 08:11):
In the IPS-IG, this page shows what is meant: http://hl7.org/fhir/uv/ips/design.html#must-support
Flora Chan (Dec 24 2021 at 06:57):
Rob Hausam said:
So the answer to question #1 is no, it isn't required to draw a code from either of the value sets bound in the slices (as it functions similar to "extensible", as Yunwei said). And the answer to question #2 is not that you have to, but that you can use a code from either slice (or a code that isn't in either of the slices if you need to).
Thanks @Rob Hausam . As advised, code from other ValueSet could be used. Would you please advise how we can present the codes from other ValueSet in IPS format?
Thanks a lot & Merry Christmas!
Flora Chan
Rob Hausam (Dec 24 2021 at 15:25):
@Flora Chan We're going to try to clean this up further in the specification and give a better and more complete explanation in the updated version that we are working on to publish soon (now we're targeting that for January, following the Connectathon and WGM). I'm happy to provide any further advice that you need (and others following the IPS stream here are, as well). Maybe working through a specific example would make that clearer and easier?
Flora Chan (Jan 03 2022 at 01:26):
@Rob Hausam We're glad to know that complete explanation is working out in the updated version. A specific example will be good. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
