Diego,
I think this is the same as
* extending the current openEHR null_flavour code set, and making it
hierarchical OR
* allowing other local code-sets to be used in that slot.
o if these codes were understood as proper local extensions of the
openEHR code-set, i.e. any new code asserted an IS-A
relationship to one of the 4 existing openEHR null codes, then
it would work properly. But we have no way to do that.
The first I think gets into the place HL7 is with this field - you can
never design a terminology for 'null flavour reason' that works for
everyone.
The second has the problem that the field becomes non-interoperable -
today, applications can assume one of 4 known values; if any code set
can be used, this assumption will break. Unless the 'extension' idea
could be achieved somehow, which would be kind of nice.
Whenever I think through this problem I come back to the idea of a
second field, which is more or less the design concept, as Ian says, or
the state machine state + careflow step in ACTIONs.
- thomas
On 25/01/2017 11:54, Diego Boscá wrote:
If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
specialized archetype (directly from an rm class) that has the texts
(+ codes) needed in a given country/use case?
This probably should work even if set of null_flavour codes is fixed.
I don't know if this would be enough, but in theory it provides a
workaround for all issues (except the cluster one)
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
