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
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
