FHIR-like terminology 'binding strengths'?
thomas.beale at openehr.org
Wed Apr 17 04:49:36 EDT 2019
On 16/04/2019 23:37, Grahame Grieve wrote:
> hi Tom
> well we need to be precise about what 'extended' means. If you add
> first level siblings to the previous version of your value set, it
> means your value set was incomplete when published.
> yes. and that's the point. The world gets by on incomplete agreements
well specifying and publishing an incomplete value set in a model
intended as some sort of standard means the authors don't understand
terminology. Consider: if new top-level codes are later found, they
really should be children of an 'other' top-level category in the
original value set.
Nevertheless, I take your point that much of the e-health world doesn't
really know what it is talking about...
> If you want to add children (by far the most common case in
> hierarchical terminologies like SNOMED and ICDx) there's no
> problem, you are just adding more specific choices of a more
> general category you already had.
> actually, that *is* the problem. You're taking an agreement and
> varying from it for no good reason. In a world where everyone has a
> terminology server and time to consult it, that may be harmless. But
> only may (there's deep subtleties there). And that's not a world we
> live in.
there are usually very good reasons: non-A-non-B-hepatitis became half
an alphabet in the last 20y.
>> To be honest, I am not sure that using required at an archetype
>> level would be wise, it may be something that can be used at a
>> template level.
> probably true; any 'required' or other setting should probably
> only be applied at template level.
> I think that's a silly rule. Sometimes, the code is inherent to the
> meaning of the structure. Let people say what they need to where they
> need to.
well I wasn't thinking it should be a rule. What Heath meant (I think)
was that in reality, the 'required' assertion would be most likely at
local / template level, not at central level. But we should not prevent
it being used at any level.
> yep. it's a mess. Only human review can establish if there was a code
> that should have been used. I completely understand why you dislike
> this as a systems engineer. But reality doesn't go away.
> btw, in all my code, I don't treat preferred and example differently
> in code. the only meaningful difference is in the message you give to
> people making templates up, and it's subtle. It was me who invented
> example, and it's proven a very useful way to get designers to be
> concrete about their meaning when they are making designs that are
> about capabilities rather than actual solutions.
It still seems to me that the right model for this concept is more like:
* /conformance/: required | extensible | optional
* /usage/: recommended | example
With only the /conformance /attribute being machine processable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-technical