Rafal Szczesniak wrote:
rather than new kinds of bricks. Information created according to an
archetype which has a new version created (correcting an error) will
have to be migrated, but not because the information building blocks are
wrong - because some structure or content is no longer valid.
And that's one of the technical challenges.
right. It means that if you correct an arcetype by creating a new version (an admission that there was something wrong in the previous version), you are obliged to provide an algorithm which will convert a lump of data according to the old one into the form of the new archetype. If this means adding a data field that wasn’t there before, it has to have been worked out what value this will be synthesized; this value must be legal with respect to the new arhcetype version.
We hope
that this will not happen often. This is one of the reasons why
archetypes and templates need to undergo quality assurance, both
technically and clinically.
Have you been thinking about a sort of identificator for archetype-class ?
Conceptually similiar to what OID is. As archetypes are being developed
and published on periodical basis they have to be loaded into running system,
eventually. Software could work on classes IDs rather than archetype path.
Moreover, it doesn't change the fact that such OIDs might be organised
hierarchically -- the way the archetype path is. Or perhaps there's already
something introduced, just that I've missed it (there's yet quite a few
documents to read...) ?
The attributes of the class ARCHETYPE look like:
uid[1]: OBJECT_ID
id[1]: ARCHETYPE_ID
specialisation_parent_id[1]: ARCHETYPE_ID
concept: STRING
The id is a multi-axial identifier, while the uid is an ISO OID or similar. The multi-axial id can be used to do searching for archetypes etc and is of the form:
archetype_id: archetype_originator ‘.’ qualified_rm_entity ‘.’ domain_concept ‘.’ version_id
qualified_rm_entity: rm_originator ‘:’ rm_id ‘:’ rm_entity
domain_concept: concept_name { ‘:’ specialisation }* – the domain concept name, including any specialisations;
version_id: ‘v’ NUMBER
archetype_originator: NAME – id of organisation originating this archetype;
rm_originator: NAME – organisation which created the reference model;
rm_entity: NAME – ontological level in the reference model;
domain_concept: NAME
specialisation: NAME
NUMBER: [0-9]*
NAME: [a-z][a-z0-9()/%$#&]*
Examples of archetype identifiers include:
racgp.openehr:ehr_rm:organiser.physical_examination.v2
racgp.openehr:ehr_rm:organiser.physical_examination:prenatal.v1
nictiz.hl7:rim:act.progress_note.v1
uk-nhs.openehr:ehr_rm:entry.progress_note:naturopathy.v2
Archetypes can also be created as specialisations of existing
archetypes; these will not invalidate existing data.
Naturally. If archetypes are classes, why couldn't they inherit like
the 'real' classes do it ?
they’re not quite the same as real classes, since they are constraint specifications, so the rules are somewhat different. THe primary rule of specialisation is that data created according to a more specialised archetype will also match the parent. In standard OO, subtypes can add attributes that the parent knows nothing about.
Besides, no one of currently known query
languages is able to reflect complicated structures of health records.
At least I don't know of one.
the archetype path mechanism is one of the elements that will be used to
make querying more powerful. Another is inspection of the "archetype
maps" of data, providing a "data xray" without having to read the data.
Could you elaborate on this 'archetype maps' concept a bit more ?
It is described in some detail in the original archetype paper at http://www.deepthought.com.au/it/archetypes/Output/arch_querying.html#1076511
This is a bit out of date, but is essentially the idea I am talking about.
Seriously though, it sounds like we're on the same