0

The DSTU2 May ballot version has a StructureDefintion resource (replaces Profile) that allows for "differential" definition of structures.

It's pretty straightforward to use this to add elements to an existing structure - all elements in the differential are "adds" to the base.

However, how does one modify or reduce an existing profile? More specifically:

How can an element in a base structure be reliably matched to an element in a differential structure so that the differential can modify the base?

I can see two possibilities:

  1. Use Path. A required element that works for non-sliced elements but not for slices (extensions are always slices).
  2. Use Name. Except it's optional, so if the base didn't name their element, this won't work.

Is there another way?

Working example here: http://hl7.org/fhir/2015May/extensibility-examples.html#1.16.2.1.2

In this example, matching by path would replace any other extension, and name matching won't work because neither element is named. The only option is to treat it as an addition (which luckily is the intent here). But if I wanted to further modify this structure using this one as the base (perhaps to set max="1") I'd be unable to.

Chris Grenz
  • 161
  • 9

1 Answers1

1

Actually, adds aren't adds. Any additions would have to be slices of extension - you can't add new elements in a profile. So (unless you're defining resources - which only HL7 can do), every element you specify in a constraint StructureDefinition must specify a "path" that corresponds to an existing path in the base resource. To constrain an existing element, simply identify that path and assert your constraints. If what you want to constrain can't be identified just by a path (i.e. you want to constrain a slice defined in a parent profile), then you'll need to re-declare the slicing and assert the additional constraints on the relevant slice. Name is used to uniquely identify slices within a profile but isn't (presently) used across profiles.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • So how do I know which slice I'm replacing when "re-declare the slicing"? It appears after a careful reading of http://hl7.org/fhir/2015May/profiling.html#2.14.0.8 that one can identify a slice by either a) use of fixed[x], or b) use of a non-overlapping binding. Is that the exhaustive list? And, is it adequate to just compare the ValueSet uri, or does one have to examine the contents of the ValueSet to determine if an element is being "re-declared"? Finally, if what I wish to re-declare is the ValueSet itself, how? A change in the uri would mean I'm not "re-declaring". – Chris Grenz May 12 '15 at 02:10
  • Each slice is identified by the fixed value associated with each of the elements identified as "discriminators" in the slice declaration for that element. If the discriminators are the same in a derived profile and the fixed values are the same, it's the same slice. If there are additional discriminators introduced, then you're "slicing the slice". If the discriminators are expressed as pure text (non-computable), then you have no way to tell other than human inspection based on the slicing rules. – Lloyd McKenzie May 14 '15 at 04:20
  • From http://hl7-fhir.github.io/profiling.html#2.14.0.8 - paragraph 4: _if the element has a terminology binding, it SHALL be associated with a complete binding with a closed Value Set reference that enumerates the possible codes in the value set_. So either fixed[x] or binding.valueSet[x] can be used, correct? fixed[x] is pretty straightforward - no question there. If **binding**, is matching on valueSet[x] adequate, or do I have to $expand the ValueSet and inspect the values? – Chris Grenz May 14 '15 at 19:31
  • You'd have to expand the value set and match against the allowed codes. (Though in some cases, the value set definition is its own expansion - where the value set either defines all the codes or enumerates them all). – Lloyd McKenzie May 26 '15 at 18:46