FHIR Chat · Forge profile failing constraint key schematron rule · conformance

Stream: conformance

Topic: Forge profile failing constraint key schematron rule


view this post on Zulip Rob Eastwood (Jun 05 2017 at 00:12):

Hello, we have created a number of profiles using Forge (and have the snapshot generation turned on) and are working on ensuring it is valid against the STU3 published schema and schematrons.

However, validating against STU3 structuredefinition.sch results in the error:
eld-14: Constraints must be unique by key
Which is located in the structuredefinition.sch's rule context of f:StructureDefinition/f:snapshot/f:element

Looking for instances of /StructureDefinition/snapshot/element/constraint/key/@value returns many instances of keys that are indeed not unique, such as:

  • "dom-1", "dom-2", "dom-3" & "dom-4" all of which are constraints of DomainResource
  • "ele-1" which is a constraint of Element
  • "ext-1" which is a constraint of Extension
  • "per-1" which is a constraint of Period

So it appears that these low level constraints are 'inherited' from their various predecessor types. However, as each (e.g.) element in the profile snapshot section has the 'ele-1' constraint, the schematron rule enforcing key uniqueness cannot be passed.

Alternatively, this may be an error in the schematron. Any poking in the right direction would be appreciated.

view this post on Zulip Michel Rutten (Jun 05 2017 at 14:13):

Hi @Rob Eastwood, interesting finding. Unfortunately I don't have a quick solution, as I think this needs to be resolved in the FHIR standard first. My reasoning would be:
- Constraints defined by a certain profile should also apply to derived/referencing profiles.
- So we want the snapshot to merge all the inherited (externally defined) constraints.
- Inevitably, snapshots are then expected to contain duplicate instances of the same common constraint(s).
I think the proper solution would be to update the eld-14 validation rule to only apply to the differential component; i.e. constraints should be unique by key in the differential component of the defining profile.

view this post on Zulip Rob Eastwood (Jun 05 2017 at 23:00):

Thank you @Michel Rutten - that makes sense.
May I ask, what would be the proper way to have the eld-14 validation update raised up?

view this post on Zulip Lloyd McKenzie (Jun 05 2017 at 23:39):

Keys only have to be unique within the scope of a single element (whether in snapshot or differential), so there should be no need to update the spec. If there's a single element anywhere in a StructureDefinition with multiple constraints with the same key, that would be a problem.

view this post on Zulip Rob Eastwood (Jun 06 2017 at 01:16):

Apologies for the noise @Michel Rutten and @Lloyd McKenzie - please scratch that.
On closer examination it turns out that it was a local issue in content that we fed into Forge, which had the constraint key duplication.
But also thank you both for your explanations.


Last updated: Apr 12 2022 at 19:14 UTC