FHIR-like terminology 'binding strengths'?
thomas.beale at openehr.org
Tue Apr 16 05:42:36 EDT 2019
I meant to say, in the previous post:
For large domain value sets (anything beyond ?200), I assume the value
set sits in a terminology service, and the archetype just has a binding
straight to that. /So there is no problem with the changing contents of
this kind of value set/, from the archetype point of view, i.e. it's
always the same value set, even if specific codes change in its usage.
/We are only talking about literally inline-included value sets/.
On 15/04/2019 22:32, Grahame Grieve wrote:
> hi Tom
> We did not define extensible bindings because we like it. Using it
> creates many issues and it's problematic. We defined it because it's a
> very real world requirement, in spite of it's apparent 'unreliability'.
> The use cases arises naturally when
> - the approval cycle of changes to the value set is slower than
> operational requirements
> - the value set is large, and a community can only get partial
> agreement in the space. This is actually pretty common - typically,
> clinical code sets may need to contain 5000-50000 concepts, but most
> of that is a very loooong tail, and 95%+ of the use comes from 200-400
> common codes. There's plenty of clinical communities investing time in
> requiring common agreed codes with fixed granularity for the head of
> the distribution.
> Neither of these things are an issue if openEHR is just targeting
> single application functionality. But as soon as the community that
> maintains the value set is wider than the users of a single system,
> then extensible bindings are inevitable.
> You can consider it bad... but that doesn't make it go away. Nor does
> it reduce the value of the agreements that do exist.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-technical