Closed markkramerus closed 6 years ago
So... this is as designed. Here are the relevant CIMPL definitions and mapping rules:
(1)
BreastCancerHistologicGrade
is (eventually) based on EvaluationResultRecorded
, from which it inherits the EvaluationResultTopic
field.
Element: EvaluationResultRecorded
// Snipped out fields not pertinent to this issue
StatementTopic is type EvaluationResultTopic
(2)
EvaluationResultTopic
has the following Value
:
Element: EvaluationResultTopic
Value: 0..1 (Quantity or CodeableConcept or string or boolean or Range or Ratio or time or dateTime or TimePeriod)
// Snipped out fields not pertinent to this issue
Note that it is a choice of many types.
(3)
In BreastCancerHistologicGrade
the CodeableConcept
choice of the value is constrained to the NottinghamCombinedGradeVS
value set:
EntryElement: BreastCancerHistologicGrade
// Snipped out fields not pertinent to this issue
EvaluationResultTopic.CodeableConcept from NottinghamCombinedGradeVS
This is the key point. This constraint is applied to the CodeableConcept
in the choice. It doesn't say the choice can ONLY be CodeableConcept
. Instead, it says that if you choose a CodeableConcept
, it better be from the NottinghamCombinedGradeVS
value set.
(4)
EvaluationResultTopic.Value
is mapped to value[x]
here:
EvaluationResultRecorded maps to http://hl7.org/fhir/us/core/StructureDefinition/us-core-observationresults:
// Snipped out mappings not pertinent to this issue
EvaluationResultTopic.Value maps to value[x]
So, the entire choice gets mapped to value[x]
, one of which is the CodeableConcept
with a VS binding. This results in a slice in the profile because that's how we constrain an element in a choice without disallowing the other choice options.
(5)
If you don't want this, then I think you need to add the following additional constraint to BreastCancerHistologicGrade
(or one of its parents):
EvaluationResultTopic value is type CodeableConcept
Solution is then to have "EvaluationResultTopic value is type CodeableConcept" where the value should be constrained to a CodeableConcept. I'll do that where needed.
Fixed in Oncology observations. Should be free of slicing now. I hope!
Leaving open until this is confirmed in the IG.
Confirmed free of slicing on build.fhir.org.
http://build.fhir.org/ig/HL7/us-breastcancer/StructureDefinition-oncology-BreastCancerHistologicGrade.html
I wonder why I see value[x] as a sliced array, and also right below it, valueCodeableConcept. I would think only the latter is necessary. See illustration.