What are commonly called 'context' attributes in health informatics usually refer to attributes that document situational context of clinical events, i.e. the 'who', 'when', 'where' etc. They may also refer to audit information captured when clinical notes are made in an EHR system, although this usage is arguably misleading. Some people think of context and attribution data as meta-data of focal acts.
To make things clear, a distinction should always be drawn between real world actions and system interactions. The first is documented with 'situation' context information - i.e. who, when, where, which may be modelled by various kinds of 'participations', time and place information and so on. The latter is documented with audit trailing and versioning. A fundamental need of all EHR architectures is to support the idea of 'stating', 'saying', 'requesting' etc in the real world separately from 'authoring' and 'committing' data to a shared information system.
The time at which doctor A determined that patient B had to be taken off a chemo drug C might not have been the time when that fact was recorded in the EHR. So times become very important.
The openEHR approach is as follows.
EHR system interaction attribution data, i.e. the audit data related to entering, committing, and attesting data is modelled explicitly using a model of change control. Every item committed to the EHR is contained in an ORIGINAL_VERSION as the 'data'. The AUDIT_DETAILS and optional ATTESTATION capture details of interaction with the EHR system. Every commit causes a CONTRIBUTION object (think 'change set') to be committed as the owner of one or more 'versions' making up a logical change set.
All of the EHR system interaction attribution information is knowable and captured at runtime, and rather than being in content-carrying objects, is in the container objects (VERSION classes), so the modeller doesn't see them at all.
Situation context of real world activities is described by the openEHR context model that distinguishes 2 levels of context inside any EHR commit: COMPOSITION and ENTRY.
The COMPOSITION class is a commit container that includes various context information, including composer, context/start_time, context/location, .... etc, relating to a health system event, e.g. an encounter, lab analysis etc.
The ENTRY level (OBSERVATION and other subtypes) corresponds to a single 'clinical statement'. Within the ENTRY and CARE_ENTRY classes, there are context attributes subject, provider (of information), other_participations, guideline_id, workflow_id and so on.
Fine-grained time information is found in lower classes inside OBSERVATION, INSTRUCTION, ACTION. The following diagram shows how time works in the openEHR EHR.
For the real world context information captured in content (COMPOSITION and ENTRY level), these are commonly only determined at runtime, but sometimes are partially constrained in archetypes. Examples:
If you are in the AWB, you can see these attributes by turning on the right view, and constraining them if needed.
The red-marked item is actually ENTRY.subject inherited into OBSERVATION, being constrained for fetal heart rate to 'foetus' (US = 'fetus'). The yellow highlighted items are not archetyped, but are made visible by the highlighted checkbox on the right.
In CKM, there is an equivalent (but friendlier to clinicians) system of separating out these 'RM' attributes, using a dedicated tab:
Important takeaway: openEHR provides all/most of the standard context items needed in the RM, so they never need to be added to clinical models; occasionally they are constrained.