Details
-
Change Request
-
Resolution: Persuasive
-
Medium
-
FHIR Core (FHIR)
-
DSTU2
-
FHIR Infrastructure
-
ElementDefinition
Profiling -
-
Chris Grenz/Grahame Grieve: 14-0-18
-
Clarification
-
Non-compatible
-
DSTU2
Description
Today, the behavior of profiles with type-specific constriants on type-choice elements is inconsistent and unclear. The full text of my proposal and justification is here:
https://github.com/chrisgrenz/FHIR-Primer/wiki/Implicit-Type-Slicing
For direct consideration, I propose the following:
1. A type choice element must remain in the profile snapshot as-is and will be interpreted as applying to all instances of the element regardless of type.
2. Constraints limiting the acceptable list of types must be applied to the original "[x]" element as this is where the list of acceptable types is defined. The inclusion of a type specific path (such as "Patient.deceasedBoolean" shall not be interpreted as constraining allowed types).
3. Type choice elements are treated as being implicitly sliced by type with the slice names that are displayed in the standard documentation (e.g. deceasedBoolean is the boolean slice of deceased[x]).
4. Constraints applied to a named type slice apply only to instances of that type. For instance, an element in a profile with name "deceasedBoolean" constrains only boolean instances of the deceased[x] element. Note that this is simply the normal behavior of a slice.
5. Paths to the type slices may directly use the type slice name (path="Patient.deceasedBoolean") or may use the slice form (path="Patient.deceased[x]", name="deceasedBoolean").