0

When declaring a differential element in a StructureDefinition, does the differential element replace ALL the properties of the base element, or only the specified properties?

Example:

<StructureDefinition>
...
  <differential>
     ...
    <element>
      <path value="Patient.gender" />
      <min value="1" />
    </element>
    ... 
  </differential>
</snapshot>

What's the proper value of the label property in a generated snapshot after applying this differential? If from the base, how would one remove the property if desired?

Chris Grenz
  • 161
  • 9

2 Answers2

0

It appears that the standard here says that the label would come from the base. However, there is no method for removing a base property?

Also, the standard is silent (I think) about how to deal with lists of properties (e.g. constraints, types, etc) - should they be replaced en masse?

Finally, the "primary key" of the element list is a little fuzzy...we assume COALESCE(name, path) - if this is available, it's re-defining the base of the same key rather than editing these fields. However, this prevents the re-naming of slices UNLESS the system must use the fixed discriminators + bindings (+ constraints??) to match.

Chris Grenz
  • 161
  • 9
  • There is no method for removing a property from the base, no. I think we're clear about constraints: they cannot be removed. Types are trickier, because this is driven by the semantics of typing. The differential types list replaces the types list in the base. And yes, path+name is the primary key. And yes, slices cannot be renamed. But since the name is only used in slicing, that's reasonable – Grahame Grieve Sep 21 '15 at 20:26
0

Properties not specified are presumed to be the same as the base. Removal of properties isn't possible. If a set of aliases are provided, you can't remove all of them, but you can replace the list. Content declared in the differential always replaces content in the base. The exception is text content where if the differential content starts with "...", the new content appends to the parent content.

The most recent DSTU spec has an explanation of how to interpret the linkage between the name of a structure definition and the base structure definition.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • So name has a couple required formatting items: base/differential navigation using slash and parent.child navigation with dot, correct? – Chris Grenz Sep 21 '15 at 17:58
  • Also, it appears from the linked page that validation of a resource either requires: a) creating a snapshot where constraints would need to be appended (base constraints couldn't be removed/altered), OR b) validating against the differential and all base profiles up the lineage. Is this the intent? – Chris Grenz Sep 21 '15 at 18:02
  • that's what snapshot is for. All the validators use the snapshot. I'll be putting up a service to generate snapshots shortly – Grahame Grieve Sep 21 '15 at 20:23
  • Hi Grahame - so in the snapshot, the constraints will always be a super-set (append rather than replace) of the base constraints? What about bindings? – Chris Grenz Sep 21 '15 at 20:32
  • Bindings in a child profile will replace bindings in a parent profile. Depending on the binding strength, there may be limitations on what the child binding can do. For example, if the base value set is "required", then the child value set can't include any concepts not from the parent value set. – Lloyd McKenzie Sep 21 '15 at 21:26