Stream: IG creation
Topic: slicing on a value set
Brian Reinhold (Feb 25 2019 at 11:05):
@Eric Haas Can you tell me how to slice on a value set or a binding? Can I do that in a pattern? Do I need to use a pattern to do that? Right now it appears I have to re-list the codes contained in the value set in a patternCodeableConcept for example.
Lloyd McKenzie (Feb 25 2019 at 16:18):
Slice by value. When you slice by value, the process checks for either a fixed value or a fixed value set binding on the discriminator
Brian Reinhold (Feb 25 2019 at 16:32):
Slice by value. When you slice by value, the process checks for either a fixed value or a fixed value set binding on the discriminator
@Lloyd McKenzie
So is this correct way to slice on system and value set?
<element id="Device.property">
<path value="Device.property" />
<slicing>
<!-- The type.system and the type of value (code or quantity) are needed to distinguish entrants. The BITs properties
(time capabilities and regulation status) will have a fixed system ASN1-url with a coded value. The remaining entrants
will have the same fixed 10101-url with either a single-coded, multiple-coded, or quantity entry. -->
<discriminator>
<type value="value" />
<!-- system being used in value set value set -->
<path value="system" />
</discriminator>
<discriminator>
<type value="value" />
<!-- codes specified by value set -->
<path value="code" />
</discriminator>
<rules value="open" />
</slicing>
</element>
<element id="Device.property:quantitiesProperty">
<path value="Device.property" />
<sliceName value="quantitiesProperty" />
<short value="The device properties represented by quantities such as clock resolution" />
<definition value="This element represents all those time properties that are a quantity such as the various clock resolutions and synchronization accuracy." />
<comment value="If the PHD reports that one of these given properties are unknown, this element shall not be populated for that property." />
</element>
<element id="Device.property:quantitiesProperty.type">
<path value="Device.property.type" />
<short value="The type of time quantity" />
<binding>
<strength value="required"/>
<!-- These are the codes that identify this Quantities property -->
<valueSet value="http://hl7.org/fhir/uv/phd/ValueSet/Quantity11073MDC"/>
</binding>
</element>
<element id="Device.property:quantitiesProperty.type.text">
<path value="Device.property.type.text" />
<definition value="It is recommended to display at least the MDC reference identifier for the MDC code" />
</element>
<!-- Slice the coding to allow one to express the same concept in another coding system -->
<element id="Device.property:quantitiesProperty.type.coding">
<path value="Device.property.type.coding" />
<slicing>
<discriminator>
<type value="value" />
<path value="system" />
</discriminator>
<rules value="open" />
</slicing>
<min value="1" />
</element>
<element id="Device.property:quantitiesProperty.type.coding:MDCType">
<path value="Device.property.type.coding" />
<sliceName value="MDCType" />
<short value="The 11073-10101 MDC code for the type" />
<min value="1" />
<max value="1" />
</element>
<!-- The system value is fixed -->
<element id="Device.property:quantitiesProperty.type.coding:MDCType.system">
<path value="Device.property.type.coding.system" />
<min value="1" />
<fixedUri value="urn:iso:std:iso:11073:10101" />
</element>
<!-- These code shall be from the value set -->
<element id="Device.property:quantitiesProperty.type.coding:MDCType.code">
<path value="Device.property.type.coding.code" />
<definition value="The MDC code representing the property" />
<min value="1" />
</element>
Lloyd McKenzie (Feb 25 2019 at 16:40):
The discriminator should be the CodeableConcept element or possibly a coding, not the individual system and code as the value set always deals with the combination
Brian Reinhold (Feb 25 2019 at 16:42):
The discriminator should be the CodeableConcept element or possibly a coding, not the individual system and code as the value set always deals with the combination
@Lloyd McKenzie
Oh yes, that was carelessness on my quick creation of the descriminators - and the binding is in the 'type' element
It should be like this:
<slicing>
<discriminator>
<type value="value" />
<!-- system being used in value set value set -->
<path value="type.coding.system" />
</discriminator>
<discriminator>
<type value="value" />
<!-- codes specified by value set -->
<path value="type.coding.code" />
</discriminator>
<rules value="open" />
</slicing>
Lloyd McKenzie (Feb 25 2019 at 17:10):
I'd expect it to be this:
<slicing>
<discriminator>
<type value="value"/>
<path value="type"/>
</discriminator>
</slicing>
Lloyd McKenzie (Feb 25 2019 at 17:11):
If you're slicing by value set, no reason to reach inside to .coding or .system/.code
Brian Reinhold (Feb 25 2019 at 17:12):
I'd expect it to be this:
<slicing>
<discriminator>
<type value="value"/>
<path value="type"/>
</discriminator>
</slicing>
Hmm... That's what I had to start with ... and the validator is complaining. I must have something else sick then.
Lloyd McKenzie (Feb 25 2019 at 17:16):
You have fixed value sets declared on the "type" elements in your slices?
Brian Reinhold (Feb 25 2019 at 17:18):
You have fixed value sets declared on the "type" elements in your slices?
I believe so: I have this on the first slice:
<element id="Device.property:bitProperties">
<path value="Device.property" />
<sliceName value="bitProperties" />
<short value="Properties reported in BITs fields" />
<definition value="For each bit setting reported a BITs value, a bitProperties element is used." />
<comment value="A BITs measurement is a 16 or 32-bit ASN1 BITs value where each bit means something. " />
</element>
<!-- The bitProperties type: It will contain at least one coding element using the ASN1 system with one of
the ASN1 codes. Currently the MdsTimeInfo capabilities and RegCertDataList regulation status are reported as BITS -->
<element id="Device.property:bitProperties.type">
<path value="Device.property.type" />
<short value="Tells what the BITs item is" />
<definition value="One of the capabilities reported in the Mds-Time-Info.mds-time-caps-state or Reg-Cert-Data-List.regulation-status field." />
<comment value="Only set 'event' types need be reported. Both set and cleared 'state' types need to be reported. The regulation status is as state type. All time capabilities are event types" />
<binding>
<strength value="required"/>
<valueSet value="http://hl7.org/fhir/uv/phd/ValueSet/ASN1attribute"/>
</binding>
</element>
Lloyd McKenzie (Feb 25 2019 at 17:20):
That looks right. What error are you getting?
Rob Hausam (Feb 25 2019 at 17:26):
@Lloyd McKenzie We (IPS) got errors with this approach (multiple variations of it), too. The issue that I see is that this isn't slicing by value. There is no value in the instance itself that can be used to discriminate and validate that the chosen code came from a particular value set - that is not (normally) carried in the instance. And I don't understand what the syntax '<path value="type"/>' would actually by trying to say (and I'm pretty sure I haven't seen it documented).
Lloyd McKenzie (Feb 25 2019 at 17:30):
The validator will check the instance against all of the slices, checking the value set. If only one matches, you're good. If more than one matches, it'll raise an error
Rob Hausam (Feb 25 2019 at 17:36):
I know that's what it is intended to do. That was the premise we started working on but we weren't able to get it to work. So far I haven't seen an example where it actually does work for validating instance data. Can you share or point to an example that does work?
Brian Reinhold (Feb 26 2019 at 00:12):
That looks right. What error are you getting?
The error (well warning) is
Device/phg-ecde3d4e58532d31.000000000000: Device.property[1]: This element does not match any known slice for the profile http://hl7.org/fhir/uv/phd/StructureDefinition/PhgDevice
I get this warning for every property element in the Device resource for all my Device resources; well, slight variations of course but the idea is the same.
Lloyd McKenzie (Feb 26 2019 at 04:10):
The code system and value set are both defined within the IG? May need to run that through the IG publisher in debug mode to see what's going on. (Unfortunately that's unlikely to happen until the end of the week.) Where is your stuff committed again?
Brian Reinhold (Feb 26 2019 at 09:36):
The code system and value set are both defined within the IG? May need to run that through the IG publisher in debug mode to see what's going on. (Unfortunately that's unlikely to happen until the end of the week.) Where is your stuff committed again?
Yes, the value sets are defined in the IG and contain subsets of the MDC code system and the codes are listed in the value sets. Location https://github.com/HL7/PHD
Rob Hausam (Feb 26 2019 at 16:12):
Yes, that's what we see, as well. It's not much consolation that it's a warning rather than an error, because it's indicating that it doesn't actually work.
Brian Reinhold (Feb 26 2019 at 16:13):
Yes, that's what we see, as well. It's not much consolation that it's a warning rather than an error, because it's indicating that it doesn't actually work.
@Lloyd McKenzie Any idea why that is happening?
Lloyd McKenzie (Feb 26 2019 at 16:21):
Not yet :(
Grahame Grieve (Mar 03 2019 at 20:01):
do we have a test case for this?
Last updated: Apr 12 2022 at 19:14 UTC
