User talk:BDennis IHC

Benefits

Archetypes enable better healthcare by lowering the cost of building and maintaining interoperable medical record systems.

They make possible a virtual unified record, and a computer-processable record which enables decision support systems to help clinicians and health workers make decisions and provide better care, and better and cheaper public health research.

Archetypes do this by representing dynamic clinical domain knowledge separately from a relatively stable underlying reference model and service infrastructure, and from the application-specific domain which uses them.

Through governance efforts the openEHR Foundation seeks to build a wide consensus in the health sector for their design and use, promoting interoperability.

History

Archetypes were first proposed by an Australian team in 1998 working on extending the Good Electronic Health Record (GEHR)

Drivers

There is an ever-increasing demand for health information from patients, practitioners, epidemiologists, planners and policy makers. And demand for medical services to interoperate to improve continuity of care and lower costs.

Why archetypes are particularly well suited to EHRs

EHR data is long-lived (for a person’s lifetime or more) over which time the format evolves to keep pace with improvements to clinical practice.

Clinical domain knowledge is complex and rapidly changing, which increases the cost and shortens the life of conventional EHR systems.

The service infrastructure allows new versions of archetypes to co-exist with old ones, so an EHR system can adapt to rapidly changing clinical knowledge without losing access to old records, and continue to interoperate with older systems.

Interoperable systems make possible a unified record, either virtually or explicitly in a central repository. This enables health sector-wide decision support system (DSS) development, which saves costs.

Not being broken by change means that DSSs don’t necessarily need to be rebuilt every time there’s a change.

Archetype System or multi-level model

Reference model and service infrastructure

The Reference Model has a small number of data types based on the clinical investigation process. These are Admin_Entry, Observation, Evaluation, Instruction, Activity, and Action. (Figure 16 “The openEHR Entry model”)

The service infrastructure provides access control, versioning, times, unique identifiers, and an Archetype Query Language (AQL.) AQL is a synthesis of SQL and well structured named paths to archetype nodes or attributes in the archetype data tree, which allows queries to be defined flexibly enough to cater for future changes to the archetypes without breaking.

Archetypes

Each archetype inherits from one of the Reference Model data types.

Archetypes consist of data elements, valid ranges, units, valid terms from internal or external terminology, and validation rules.

Archetypes are designed to contain a maximal set of attributes which can then be optionally filled in as required by the situation.

Each archetype describes a complete clinical knowledge concept such as ‘diagnosis’ or ‘test result’.

They are written by clinicians and need a broad consensus of clinicians.

They have a wide range of scope from simple observations to complex ‘family history’ or ‘care plan.’

They are intended to be used widely to allow EHR systems to share data.

Archetypes can be built by inheriting from or aggregating other archetypes, a feature which reduces complexity and duplication.

Archetypes can use externally defined terminologies as attribute values, and bind to and be queried using external terminology databases. (Chapter 12)

See for examples of archetypes.

Templates

Templates are intended to be application-specific and defined on a local system or site to display or capture screens of data corresponding to a workflow.

They may be defined by business analysts rather than clinicians.

Archetypes are the building blocks with which templates are constructed and take responsibility for validating the input.

User interfaces may be partially or fully generated automatically from templates. Some business logic may be needed to tie the archetypes together and enhance workflow.

Templates may specify loosely which archetypes to use, so that any archetype which inherits from a given parent may be used in a slot on the template. For example a “laboratory result” slot could be chosen at runtime by the user to be a “blood glucose lab result” and then filled in.

Difficulties in adopting archetype systems

The cost of developing and adopting archetypes is born disproportionately by early adopters for little upfront benefit. [Wollersheim] Archetypes diminish software vendor lock-in, disadvantaging established vendors and discouraging them from investing in archetype system development. Governments may need to mandate their use.