These comments are based on the example profile at:
-
-
Save jmandel/feb111c54645a5ff7e4d to your computer and use it in GitHub Desktop.
The following snippet tries to say "the report's name must be LOINC:57698-3
.
<element>
<!-- I wonder whether this means *all* codings under "name" must now conform to the constraints below, or just *any* ? -->
<!-- If we'd allow non-primitive valueXXX, we'd need only one fixed value at DiagnosticReport.name, but then, how do we define equality for complex types? -->
<path value="DiagnosticReport.name.coding.system"/>
<definition>
<min value="1"/>
<max value="1"/>
<valueUri value="http://loinc.org/"/>
</definition>
</element>
<element>
<path value="DiagnosticReport.name.coding.version"/>
<definition>
<min value="0"/>
<max value="0"/>
</definition>
</element>
<element>
<path value="DiagnosticReport.name.coding.code"/>
<definition>
<min value="1"/>
<max value="1"/>
<valueCode value="57698-3"/>
</definition>
</element>
But does it also match (for example):
name: {
coding: [{
system: "http://loinc.org"
},{
code: "57698-3"
}]
}
If not... why not? Is this logic captured somewhere explicitly?
The following snippet declares a slicing group for a report's results, by name:
<element>
<path value="DiagnosticReport.result"/>
<slicing>
<discriminator value="name"/>
<ordered value="true"/>
<rules value="closed"/>
</slicing>
<definition>
<comments value="Cardinality 3..4, since chol, trig, hdlc are mandatory, ldlc is optional"/>
<min value="3"/>
<max value="4"/>
</definition>
</element>
But shouldn't it read:
<path value="DiagnosticReport.result.reference"/>
? Otherwise, how can a profile refer to content or extensions attached directly to the ResourceReference
itself (vs. the target of the reference)?
When a report's results on Observation.name
, how does matching occur? For example, for each of the following pairs, would the two Observation.name
s belong to the same slice or difference slices?
name: {
coding: [{
system: "a",
code: "b"
}]
}
__vs__
name: {
coding: [{
system: "a",
code: "b",
version: "c"
}]
}
name: {
coding: [{
system: "a",
code: "b"
}]
}
__vs__
name: {
coding: [{
system: "a",
code: "b"
}, {}]
}
name: {
coding: [{
system: "c",
code: "d"
}, {
system: "a",
code: "b"
}]
}
__vs__
name: {
coding: [{
system: "a",
code: "b"
}, {
system: "c",
code: "d"
}]
}
That's just a few examples -- the point being: what are the semantics here?
Same question applies to repeating elements...
Our current spec says:
the profile SHALL nominate a "discriminator" - a contained element that is used to discriminate among the different slices. The profile SHALL fix the value of the contained element for each slice, or if the contained element has a terminology binding, it SHALL be associated with a complete binding with a version specific Value Set ...
Can the discriminator be a deep path into a complex datatype, like "reference.name.coding"?
Also, "SHALL fix the value of the contained element" doesn't appear to apply in the fix-by-reference-to-a-profile technique used in the lipid panels example. Is this another special case? (e.g. it would be "fix directly", "point to a value set", or "point to a profile"?)
We see examples of "constraints" applied to a resource:
<path value="Observation"/>
<definition>
<short value="Triglyceride measurement"/>
<formal value="Triglyceride measurement"/>
<constraint>
<key value="value-or-comment"/>
<name value="Must have valueQuantity or comment"/>
<severity value="error"/>
<human value="If a value result is not available, use the comments field"/>
<!-- notice how the xpath actually refers to valueQuantity, not value[x] -->
<xpath value="exists(f:valueQuantity) or exists(f:comment)"/>
</constraint>
and then a "condition" that appears to refer to this constraint:
<element>
<path value="Observation.value[x]"/>
<definition>
<short value="Actual result"/>
<formal value="The actual value of the triglyceride measurement"/>
<comments value="If not available, a comment should be given"/>
<!-- Was already 0..1 in base, but it's good to restate it, value-or-comment controls the actual optionality -->
<min value="0"/>
<max value="1"/>
<type>
<code value="Quantity"/>
<profile value="#lipidQuantity"/>
</type>
<condition value="value-or-comment"/>
<mustSupport value="true"/>
</definition>
But :
All we get is:
The condition element is used to assert that a constraint defined on another element affects the allowed cardinality of this element.
and
Profile.structure.element.definition.condition Definition A reference to an invariant that may make additional statements about the cardinality or value in the instance. Control 0..* Type id
In the Observations profiled above, the constraint
would seem to say everything that's needed. Why are two paths (value[x]
and comment
) referring to it explicitly? Is this just so the human-readable docs can be rendered with warning icons in the right spots, or are there hard, computable semantics attached to the appearance of condition
at a sub-path?
In the examples diagnostic report, we have only four structures. Missing are:
ldlCholesterol
hdlCholesterol
lipidQuantity
- 1 - I agree, will fix
- 2 - Grahame, what does your validator currently do here? Do we need to change this before Chicago?
- 3 - I had the same kind of questions, looks like a discussion for the face to face meeting. That's why I put this question in a comment in the differential as well. Also, I wonder about what happens if we allow non-primitives as fixed values and how that will influence matching.
- 6 - Missing observation structures...
They seem to be present in https://github.com/ewoutkramer/fhir-net-api/blob/develop/src/Hl7.Fhir.Api.Tests/example-lipid-profile-testmessage.xml, where did you look?
Hmm, but do profiles have the expressivity to convey these distinctions? How would I describe these distinctions in profiles?