search

Nictiz / Nictiz-R4-zib2020

NL package of FHIR R4 conformance resources for zib (Zorginformatiebouwstenen, Clinical Information Models) release 2020.
Creative Commons Zero v1.0 Universal
4 stars 3 forks source link

Are zib components actually mustSupport? #72

Closed pieter-edelman-nictiz closed 1 year ago

pieter-edelman-nictiz commented 3 years ago

It is expected that a zib compliant system is able to handle all zib components which are profiled in a FHIR profile. Doesn't that actually make the zib components mustSupport? And in addition, should the profiles be explicit about this?

mmsmits commented 3 years ago

I've been thinking about this a lot. And changed my mind a couple of times, but I think you shouldn't put any mustSupport flag on such general profiles like zibs of nl-core. This is because profiles that are derived from those automatically inherit such flags, and can't remove them, while in practice probably not all elements from a zib "must be supported" for all use cases. So if you put must support flags on these profiles, you would force them on any derived profile as well.

pieter-edelman-nictiz commented 3 years ago

@mmsmits that's a good point; all cardinalities in the zibs are in fact expected to be "conceptual" -- they do exist, but they might not be known during the exchange of information. So it would be counterproductive to then add mustSupport on these elements.

If you zoom out a bit, would it make sense for an implementer to have all elements which are of interest for an implementation marked as mustSupport? It is still possible and maybe useful to add this information in information standard specific profiles.

mmsmits commented 3 years ago

I totally agree with that, it would be very helpful to mark "elements that are part of the zibs" with some sort of flag. But mustSupport feels a bit off for that, because it is usually used like US Core defines it, and I don't know if that actually fits our need. "Required but may be empty" https://www.hl7.org/fhir/us/core/general-guidance.html#must-support The problem is that there is no better alternative I can think off.

pieter-edelman-nictiz commented 2 years ago

TODO: document the conclusion in the profiling guidelines

pieter-edelman-nictiz commented 2 years ago

Proposal for text: https://informatiestandaarden.nictiz.nl/wiki/FHIR:Vissue-72_FHIR_Profiling_Guidelines_R4

niekvangalen commented 2 years ago

I like the text. Maybe add something at the end like "... transactions for Nictiz information standards are typically defined in ART-DECOR and are specified in the functional design ..." or something similar.

pieter-edelman-nictiz commented 1 year ago

Integrated the text to the prepub environment.