FHIR Chat · Closed slicing and cardinality restrictions

Stream: implementers

Topic: Closed slicing and cardinality restrictions

Morten Ernebjerg (Jul 04 2018 at 09:45):

I am working on a profile of Observation. I have restricted the cardinality of code.coding to "1...*" and also sliced this field (discriminating on system and code). I have set the slicing to be closed and have defined a single slice (with cardinality 1...1). I was under the impression that this latter combination (closed slicing + defining only a single slice, of which only one instance is allowed) should implicitly restrict the cardinality of code.coding to "1...1" (no undefined elements allowed + 1 required element defined -> exactly 1 element required). However, when I run the validator on an example Observation in which the element defined by the slice AND a further element (different code & system) is present in code.coding, it goes through without errors (but it does catch if the slice element occurs twice). Have I misunderstood the way closed slicings work?

For the future: Insofar as closed slicing does actually restrict cardinality, are there any best-practice rules for how to set the cardinality of a field with a closed slicing? E.g. should it also be set to reflect the min and max no. of element the slicing allows or rather not be changed at all?

Martijn Harthoorn (Jul 04 2018 at 11:16):

As far as I can see, your assumption is correct. Which validator are you using?

Morten Ernebjerg (Jul 04 2018 at 11:56):

I am using the standard Java JAR validator, org.hl7.fhir.validator.jar (retrieved the latest version today).

Lloyd McKenzie (Jul 04 2018 at 13:20):

Sounds like a bug in the validator. Please submit a change request. If you can submit a minimal instance that demonstrates the issue, that'd be good too.

On a separate note, restricting the number of codings in a CodeableConcept is generally not a good idea unless you're just documenting what your system will currently do. One of the objectives of FHIR is to allow systems to design a single external interface that satisfies the needs of all of their interaction partners. So you might spit out a local code, an ICD9 code, an ICD10 code and a SNOMED code as different codings because different consumers expect different systems. As a consumer, you should always be prepared to handle the possibility that there are additional codings present you don't care about and support - and when that happens, you should ignore the extra codings, not raise an error. Otherwise you're forcing your communication partner to have a special interface just for talking to your system, and that significantly raises costs.

Martijn Harthoorn (Jul 04 2018 at 13:30):

As a comparison, you can upload your resources (profile + instance) to your Simplifier project, and validate there. It uses the C# Validator.

Morten Ernebjerg (Jul 05 2018 at 09:20):

Thanks for the input! @Lloyd McKenzie I will try to boil the issue down to a minimal version. Where should I submit the change request (will be my first one)? Also thanks for the tip on the cardinality restriction, I will give that some more thought.

Lloyd McKenzie (Jul 05 2018 at 13:32):

There's a link at the bottom of each page in the specification that says "propose a change". There's a one time (free) registration process where we try to confirm you're a human. After that, you can submit changes to your heart's content :)