What is an archetype?
An archetype is a re-usable, formal definition of domain level information. The formal concept was originally described in detail in a paper by Thomas Beale. The key feature of the archetype approach to computing is a complete separation of information models (such as object models of software, models of database schemas) from domain models. Thus, archetypes are not part of the software or database of a system. A short document on archetype principles is here. Technical specifications: ADL 1.4; ADL 1.5 draft.
Archetypes have a number of key purposes:
- they allow domain experts such as clinicians to create the definitions which will define the data structuring in their information systems
- they provide runtime validation of data input via GUI or any batch process
- they provide a basis for intelligent querying of data.
In health, information, or 'content' that can be modelled using archetypes includes things like:
- Observations: weight measurement, blood pressure, microbiology results
- Reports: discharge referral
- Orders: prescription
- Assessments: diagnosis
and many others. From the user's point of view, these are the kinds of data which occur in health information systems. Each archetype is a text file, expressed in either ADL syntax or its XML derivative.
What about existing data?
There are two kinds of archetypes the community needs:
- 'designed' archetypes, which clinicians design from scratch. There are many examples in Australia, and a growing library in Europe. These kind of archetypes are based on what we have called the "Domain Base Concept Model" (presentation about this). This sounds complicated, but in fact it just means "the UML model of invariant concepts in the domain, on which archetypes can be safely based". Currently this is the openEHR Reference Model, since it is the openEHR community doing most of this work at the moment. But in the future, we hope that this model will be adopted by others for this purpose, possibly with some additions, simplifications and so on. For example, the Danish Board of Health might want to propose some G-EPJ concepts should go in there. But note: this model is not meant to be large at all; our experience is that the openEHR model of Observation and Evaluation is about right for all archetypes so far developed as observations and diagnoses etc. We are redeveloping the Instruction Entry subtype in openEHR, which will provide a very powerful basis for archetypes for medication, interventions, orders etc.
- 'legacy' archetypes. These are archetypes which are designed to mimic legacy data, which itself does not follow any ontologica design - typically is is flat, or else tree-like. This could be data from a hospital database, HL7v2 messages etc. The GENERIC_ENTRY type was added to the openEHR Reference Model to provide a basis for legacy archetypes (technical specification of GENERIC_ENTRY type).
Data processing in an openEHR-enabled context can now be done as follows:
- export or convert data from original source, e.g. RDBMS, HL7v2 messages to an intermediate XML or comma-separated value format
- import this data into an openEHR system, as instances of GENERIC_ENTRY, according to archetypes based on 13606
- convert the data to a form based on desired archetypes, and openEHR ENTRY subtypes, i.e. OBSERVATION, ACTION, EVALUATION, INSTRUCTION. This conversion can be done based on the use of "archetype interfaces", i.e. definitions of the interfaces of archetypes, regardless of their internal structures.
Data can also be easily accepted into such a system in the form of EN13606 Extracts, and output in the form of EN13606 Extracts. A simple presentation shows this graphically.