FHIR-like terminology 'binding strengths'?

Thomas Beale 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.

- t



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20190417/03a37d82/attachment.html>


More information about the openEHR-technical mailing list