Stream: conformance
Topic: Uniqueness of constraint keys
Chris Moesel (Oct 12 2020 at 20:21):
Somewhere along the line, I got the idea that constraint keys should be globally unique across an IG. But I noticed in US Core that us-core-1 is defined differently in multiple profiles -- so it obviously is not globally unique within the IG. Looking at the doc, I see that it only guarantees uniqueness within a single Structure Definition.
Because FSH treats invariants as 1st-class objects, however, their names (which correspond to ElementDefinition.constraint.key) are globally unique. So in FSH right now, it is impossible to re-use the same constraint key across multiple profiles (except when you also want the definition of the constraint to be the same -- which is actually a good feature for re-use).
Is it a best practice to have globally unique constraint keys (with different definitions), or is this something that we shouldn't care about and should allow to happen easily in FSH?
Lloyd McKenzie (Oct 12 2020 at 21:41):
The key is referring to something within the StructureDefinition. There's no ability to point to a constraint independent of model, so enforcing uniqueness wouldn't accomplish much. Also note that if a model inherits an invariant from a StructureDefinition defined in another IG, you can't use that key in your refined model, even though it might not appear elsewhere in the current IG.
Grahame Grieve (Oct 12 2020 at 22:37):
I think it's fine if FSH doesn't support that
Eric Haas (Oct 13 2020 at 23:20):
From an authoring perspective since there is no global invariant index (that I know of). The simplest approach was to increment within an SD.
Lloyd McKenzie (Oct 14 2020 at 01:25):
Incrementing within an SD isn't terribly future-proof. (If a new invariant gets added in the base, you're faced with renumbering your invariants.) It's better if you use a different prefix in the derived model than the parent model. You only have to worry about being unique within the inheritance tree.
Chris Moesel (Oct 14 2020 at 12:32):
BTW -- after further review, I see I mis-spoke above. I said that keys need only be unique within the SD, but actually, eld-14 (constraint.select(key).isDistinct()) only enforces uniqueness within the constraint array of an element. So it's even possible to have duplicate keys within an SD as long as they're not in the same element. Seems like a bad idea to me, but technically it is allowed.
Last updated: Apr 12 2022 at 19:14 UTC
