Stream: terminology
Topic: code system "fragments" not published by the cs authority
Rob Hausam (Mar 09 2021 at 13:58):
I'm linking this topic on Incomplete expansion of IPS ATC value set from the IPS stream for further discussion here on the question of code system "fragments" that are being used for various purposes but which are not published by the code system authority and therefore violate our current rules: "Fragments can only be published by the code system authority, or according to a process defined by the authority, if they have defined one". Sometimes we have reasons to use partial representations of code systems that we (not the code system publisher) control, possibly for convenience (as in the LIVD IG) or because the full source of the code system content isn't readily available or usable (as for code systems like ATC that are published but only partially on tx.fhir.org). It seems to me that rather than disallowing these usages entirely, or entirely losing the control over what is a code system 'fragment' by broadening its scope to be essentially "any subset" of a code system, maybe what we should do is add a new code to codesystem-content-mode, such as 'partial' or 'subset' for this purpose? It would also seem desirable that the IG publisher/validator would take into account that the code system representation on the terminology server is 'fragment'/'partial'/'subset' (as per @Morten Ernebjerg's initial concern).
Michael Lawley (Mar 09 2021 at 20:50):
Rather than add a new content type, I'd be happier if the rule for fragments was just relaxed a little.
I think the intent of the rule was to avoid fragments that lead to wildly inconsistent/misleading/dangerous(?) behaviour (for example, of $expand). It might instead be better to attempt to define some more specific rules around "valid fragments".
Michael Lawley (Mar 09 2021 at 20:53):
But first, we should probably look at the motivating use-cases people have for using fragments to determine whether they are reasonable or not. As examples: "pragmatism for coping with infinite, grammar-based codes", and "because we only need this much smaller set of codes".
Rob Hausam (Mar 09 2021 at 20:59):
@Michael Lawley Right. That makes sense. I was just going to ask if you have any suggestions for what the rules for "valid fragments" might be? The default, I think, is the existing set of rules (4 bullets) in the bottom part of 4.8.8, minus the second bullet (which restricts to the fragment being published or at least sanctioned by the code system authority)? Is that sufficient? Or would more be needed?
Michael Lawley (Mar 09 2021 at 21:04):
I'm suggesting that the fourth item (... be careful and communicate their intent clearly) probably needs to be expanded upon. Either with some "do not" rules, or at least some specific "beware of X because Y" rules because the people creating may not be aware of potential gotchas, and we do NOT want proliferation of fragments just because "my valueset in my IG only uses these few codes" or similar.
Rob Hausam (Mar 09 2021 at 21:06):
Yes, we could probably do something with that. But at the moment I'm not thinking of anything that seems necessarily hard and fast.
Robert McClure (Mar 10 2021 at 19:03):
I agree that removing the authority publication requirement is a good change. I also agree that some rules helps, particularly we should expect the author to describe the scope of the fragment.
Rob Hausam (Mar 11 2021 at 01:10):
That seems quite reasonable.
Last updated: Apr 12 2022 at 19:14 UTC
