6. EHR and composition

Requirement prefix: E6.

Where these invariants come from#

As in §3, the rendered RM page omits its class-definition tables. They were read from the Release 1.0.2 publication (EHR Information Model, Rev 5.1.1, 16 Aug 2008, §4.7, §5.4, §8.3) and the EHR amendment record checked for every change since: releases 5.1.2 through 5.2.1 changed documentation, added EHR.folders, and added tags. None altered the invariants below.

EHR#

• E6.1 EHR MUST hold OBJECT_REFs to its status, access settings, compositions, contributions, and folders — not the objects themselves. A composition is a versioned object, and an EHR that embedded them would embed the whole record.
• E6.2 EHR.directory MUST be the first element of folders, and setting folders from an empty list MUST be refused rather than leaving the two disagreeing.

EHR_STATUS#

• E6.3 is_modifiable and is_queryable MUST be independent flags.
• E6.3a An EHR_STATUS MUST be an archetype root (Is_archetype_root). One without archetype_details cannot say which archetype shaped it, so nothing downstream can validate it against one.
• E6.4 Documentation MUST state that deactivation — is_modifiable = false, on death, merge, migration, or opt-out — normally leaves the record queryable, because the history stays clinically and legally live. Code that treats deactivation as deletion removes a record law requires be retained.
• E6.5 EHR_STATUS.subject MUST be a PARTY_SELF, permitting an anonymous record (M5.16).

COMPOSITION#

• E6.6 category MUST come from the openEHR composition_category group, and the constructor MUST take a code rather than a DV_CODED_TEXT.
• E6.6a A COMPOSITION MUST be an archetype root (Is_archetype_root), for the reason given in E6.3a.
• E6.6b A persistent composition MUST NOT carry an EVENT_CONTEXT (Is_persistent_validity: is_persistent implies context = Void). A persistent composition is a running summary across many encounters — a problem list, a medication list — so attaching one encounter's context asserts that the whole list belongs to that visit. The specification states this twice: as a formal invariant, and in prose as "Persistent Compositions do not have an Event context."
• E6.7 language and territory MUST be required. A composition that does not say what language it was recorded in cannot be safely rendered or translated.
• E6.7a openEHR additionally requires language and territory to be drawn from the languages and countries code sets (Language_valid, Territory_valid). This crate does not enforce either: both are external code sets, and resolving them is out of scope (S1.10). The codes are carried opaquely and checked only for CODE_PHRASE well-formedness. Declared here rather than left as a silent gap (C0.12).
• E6.8 content MUST admit both SECTION and every ENTRY subclass, and the serialized form MUST be one flat _type dispatch rather than a nested one. A nested encoding makes a reader buffer the whole subtree per level.
• E6.9 A traversal reaching every ENTRY however deeply nested in sections MUST be provided. An entry three sections deep is exactly as clinically significant as one at the top.
• E6.10 SECTION MUST be documented as navigational: moving an entry between sections must not change what it says, and software deriving meaning from section membership breaks at the next template revision.

EVENT_CONTEXT#

• E6.11 setting MUST come from the openEHR setting group.
• E6.12 end_time MUST be refused when it is established to be before start_time, and MUST be accepted when the two are not comparable (D3.14), with validation reporting rather than the constructor guessing.
• E6.12a location MUST be absent or non-empty (location_valid). A present-but-empty location is indistinguishable from an absent one to every reader.

Entries#

• E6.13 The five entry classes — OBSERVATION, EVALUATION, INSTRUCTION, ACTION, ADMIN_ENTRY — MUST be modelled, with the ENTRY attributes shared and the CARE_ENTRY attributes shared among the four clinical ones.
• E6.14 An entry's subject MUST be explicit at construction. An entry that is about a family member and does not say so reads as a finding about the patient, and that error is invisible in every rendering.
• E6.15 ADMIN_ENTRY MUST be distinguishable from the CARE_ENTRY subclasses, because a research extract that keeps clinical entries and drops administrative ones is making a defensible cut and one that cannot tell them apart is not.
• E6.16 OBSERVATION.data MUST be a HISTORY even for a single reading, as openEHR requires. That is what makes a one-off blood pressure and a continuous arterial trace the same shape.
• E6.17 EVALUATION MUST NOT have a HISTORY. An evaluation is an opinion held at the moment of recording; superseding it is a new version, not a new event.

Instructions and actions#

• E6.18 INSTRUCTION.narrative MUST be required, and MUST be documented as the human-readable order rather than a summary of the activities. A narrative generated from structured activities records what the software understood, not what the prescriber meant.
• E6.19 INSTRUCTION.activities MUST be non-empty.
• E6.20 ACTIVITY.action_archetype_id MUST be carried as a pattern, not parsed as an archetype id: openEHR writes /.*/ when any action will do, and validating it as an id would reject the commonest value there is.
• E6.21 ISM_TRANSITION.current_state MUST come from the openEHR instruction_states group and transition from instruction_transitions.
• E6.22 Terminal states MUST be identifiable, so that an ACTION recorded against an already-completed order can be flagged.
• E6.23 INSTRUCTION_DETAILS.activity_id MUST be non-empty: an action that names the instruction but not the activity cannot say which step of a three-times-daily order it fulfilled.

Folders#

• E6.24 FOLDER MUST hold references, so that more than one folder tree can classify the same composition without duplicating it.