My ideas about this are:
- coding systems never will be stable.
- the way to handle change in OpenEHR (and CEN En13606) is via
archetypes.
- select a coding system and produce a 'ancestor archetype' that uses
codes from a specific coding system.
- over time a new 'ancestor-archetype' will be produced using a new
version of the specific coding system or a new coding system altogether.
- the question now is how to handle interoperability. The answer is
the use for an 'archetype ontology'. One we miss at this moment.
- having this 'archetype ontology' makes it possible to define
synonyms, anti-nyms, etc, and make semantic interoperability possible.
- for it to work properly we need:
'ancestor archetypes', that can be inserted in Templates
an archetype ontology
an 'archetype editor' that is able to not only produce
archetypes and templates but also assemble ancestor archetypes and
normal archetypes into templates but also constrain each of them
further.
Gerard Freriks
ps: I use sometimes the term 'proto-archetype' for the 'ancestor-
archetype'
--
--
Gerard Freriks, MD
Convenor CEN/TC251 WG1
TNO Quality of Life
Wassenaarseweg 56
Leiden
PostBox 2215
22301CE Leiden
The Netherlands
T: +31 71 5181388
M: +31 654 792800
On 20-aug-2005, at 22:45, Rong Chen wrote:
> I agree. We need to have this indirection to handle changes.
>
> Even if we are certain that these codes will not change in the
> future and we feel the need to hardcode them in the software, some
> enumeration type instead of string type should be used to implement
> them since string is not type safe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050821/464c26a4/attachment.html>
