Stream: conformance
Topic: Limitations for slices
Aleksi Aho (Dec 09 2019 at 14:19):
Hello, I have problem where I would like to set limitations to some slices. I looking solution, where it is possible to use either one slice, but not both at the same time. For nowI have done this by limiting cardinality but now I have use case, where I need to increase the cardinality from 1..2 to 1..*. Is this possible to do?
Slices.png Here is picture from slices
Lloyd McKenzie (Dec 09 2019 at 14:30):
Your design looks a bit 'unusual'.
- First, are you aware that all codes sent in CodeableConcept.coding need to be translations of each other? I.e. you can't have codes for different types of Observations in the same coding. Every distinct Observation type needs to be captured as a separate Observation.
- Second, if you're wanting to create a profile that covers multiple observation types, the normal way to do that is to list all of the allowed observation codes in a value set and have a required binding to that value set.
- Third, you generally don't want to constrain CodeableConcept.coding to prevent implementers from sending additional codings. Doing so creates unnecessary costs in the implementation space. As a receiver, just look through the codings provided and expect to see exactly one that covers your space (presuming that the codes in your value set are mutually exclusive)
- Fourth, it's similarly bad practice to constrain out things like 'version' and 'userSelected'. If you don't care about them and will ignore them, just don't mark them as 'mustSupport', but don't treat their presence as an error. Even if you're defining a profile that reflects what you're sending, marking the cardinality as 0..0 precludes you from introducing them in the future in a backward-compatible way.
Last updated: Apr 12 2022 at 19:14 UTC
