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:
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
- 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
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.
openEHR-technical mailing list