0

I'm trying to figure out how to fully specify a sliced element. If I'm reading the spec right, nameReference is the only place where a "sub element" of a slice can declare which slice it's "on".

So, if telecom is sliced by use and system and I want to specify a constraint on home phone, I have to fix use and system to those values and then add my constraints on that slice.

Consider:

Resource Example                  ElementDefinition attributes
================================  =====================================================================
<Patient>                         name="Patient"
... snip ...
  <telecom>                       name="HomePhone"
    <system value="phone" />      name="HomePhone.system", nameReference="HomePhone", fixedCode="phone"
    <use value="home" />          name="HomePhone.use"   , nameReference="HomePhone", fixedCode="home"
    <value value="5551234567" />  name="HomePhone.value" , nameReference="HomePhone"
  </telecom>
... snip ...
</Patient>

In most examples, it appears that a dotted notation of Name has been used (as I've placed in the example). But the specification doesn't require this and provides no format that could be reliably parsed.

The problem is: nameReference and fixed[x] are mutually exclusive. What's the correct way to handle this??

Chris Grenz
  • 161
  • 9

1 Answers1

0

Repetitions in an instance don't "declare" what slice they're part of. They simply declare the appropriate value for what ever element(s) are the discriminator for the slicing process. nameReference isn't involved at all. On the definition side, association is simply handled by name. So HomePhone.system is associated with HomePhone simply by the name and by sequential proximity. The dot-notation is required. We could probably be a bit more explicit about that though, so feel free to submit a change request.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • It sure would be nice to have a "full name" attribute of some kind. The current model requires a combination of path (XML/JSON navigation) and name to determine the StructureDefinition element for a particular resource element. We are (at run time) generating XPath expressions for this taking into account path, name, and fixed discriminators to meet this need... – Chris Grenz May 04 '15 at 14:47
  • So a name for every element in every slice? How would you deal with recursion? Given the data we capture in the definitions, the full names would end up looking like what you've got now anyhow. (Also keep in mind that a single instance might be valid against multiple structure definitions.) – Lloyd McKenzie May 10 '15 at 05:59
  • I was thinking more along the lines of an absolute or relative XPath for the element. But you're right that it would make multiple contexts or data type extension difficult. It's computationally expensive to create an XPath like `/Patient/address/extension[@url="..."]/valueCodeableConcept/Coding[system/@value="..."]/code` at run time by assembling StructureDefinition elements. – Chris Grenz May 12 '15 at 02:15