openEHR

Some of the key classes in the EHR component are the ENTRY classes, whose subtypes include OBSERVATION, EVALUATION, INSTRUCTION, ACTION and ADMIN_ENTRY, as well as the Instruction State Machine, a state machine defining a standard model of the lifecycle of interventions, including medication orders, surgery and other therapies.

This is justified by the need to deal scalably with the generic problem in health of a very large, growing, and ever-changing set of information types.

The second kind of artefact is known in openEHR as a "template", and is used to logically represent a use case-specific data-set, such as the data items making up a patient discharge summary, or a radiology report.

Without the archetype "library" level, every data set (i.e. chunk of operational content) is uniquely defined and a standard approach to querying is difficult.

[10] While individual health records may be vastly different in content, the core information in openEHR data instances always complies to archetypes.

[18] For example, a set of openEHR archetypes needs to be quality managed to conform to a number of axioms such as being mutually exclusive.

The archetypes can be managed independently from software implementations and infrastructure, in the hands of clinician groups to ensure they meet the real needs on the ground.

[citation needed] In the field of Electronic health records there are a number of existing information models with overlaps in their scope which are difficult to manage, such as between HL7 V3 and SNOMED CT.

This approach also means the actual data models used by any EHR are flexible, given that new archetypes may be defined to meet future needs of clinical record keeping.

One of the outcomes of openEHR modelling approach is the open development of archetypes, templates and terminology subsets to represent health data.

Community users are able to share, discuss and approve these structures in a collaborative repository known as the Clinical Knowledge Manager (CKM).