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/.

- thomas

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.


_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to