Interventions approach

Modelling approach

Following the Sparked CDG’s guidance, design of a single data group to represent all ‘interventions’ was considered but ultimately dismissed. While the notion of a generic, reusable data group had broad appeal and the potential to simplify implementation, it also lacked the necessary specificity required to accurately document and track the diverse range of interventions. Experience gained from modelling Procedure and Vaccination reinforced this conclusion.

An analysis of documentation patterns across a broad range of interventions revealed that, while mature and complete ‘intervention’ data groups vary in their specific documentation requirements, a common underlying pattern was identified as the starting point for each new intervention-related data group. The proposed initial Intervention pattern is represented in the mind map below, and it is expected that each new intervention-related data group will evolve and expand as specific new requirements are identified.

Proposed concept representation for a common pattern to initiate each new Intervention data group.

AUCDI R2 includes 6 data groups in the ‘Interventions’ collection:

  • Procedure
  • Vaccination
  • Health education
  • Medical equipment supply
  • Psychosocial therapy
  • Physical assistance

In future AUCDI releases, it is anticipated that a more comprehensive library of intervention-related data groups will gradually be developed, including medication-related interventions, such as medication administration and dispensing.

Structure of the ‘Intervention’ data groups

The ‘Intervention’ collection of data groups follow a standard structure to allow the detailed tracking of clinical activities throughout their lifecycle, extending beyond a simple status attribute by introducing a new category of state-related ‘careflow steps’ designed to support the detailed tracking of a single intervention’s progress. Each careflow step represents key events or activities that clinicians have identified as critical points in the clinical workflow where documentation should take place.

The comprehensive set of state-related attributes included in the data groupsare, organised into two levels of detail: the first introduces a standardised set of universal state categories, known as ‘ISM states’, while the second level provides more granular details specific to each clinical activity necessary for carrying out an intervention, known as ‘careflow steps’. This addition will support the documentation and tracking of data-related events relevant for any clinical intervention or activity along a clinical pathway, from initiation thought to completion. The resulting health record will contain essential information against each clinically or medicolegally relevant event along a clinical pathway, including the capacity to document deviations from the expected pathway and the reasons for these deviations.

  1. ISM states (universal categories) – a standardised set of states which draws from, and closely aligned to, openEHR’s Standard Instruction State Machine (ISM)[1].
    The ISM states define an agnostic model for documenting clinically relevant data in an electronic health record and tracking progress transitions from state to state along an anticipated care pathway. For example, the ISM state transitions support tracking a procedure from the initial ‘Planned’ state to ‘Scheduled’, then on through ‘Active’, eventually marking the procedure as ‘completed’. It also supports documentation of any deviation from the anticipated workflow which is common in clinical practice. For example: a ‘Planned’ and ‘Scheduled’ procedure for insertion of ear grommets in a child with chronic otitis media may diverge to a different and more significant actual procedure performed after examination of the child’s ear under anaesthesia, so the actual procedure ‘Completed’ is varied or adjusted as necessary as part of clinical workflow. 
    Within the FHIR specifications, this ISM approach is echoed in the ‘Procedure.status’ attribute of the Procedure FHIR resource.
  2. Careflow steps – identify events along a clinical pathway’. Each ‘careflow step[2] is associated with a relevant ISM state. A single ISM state may comprise multiple careflow steps. These steps are customised for each data group, representing events that are significant from a clinical or medicolegal perspective, where clinicians and other contributors are required to document data in the health record. The data captured at each careflow step enables subsequent querying to monitor progression along the clinical pathway.

The openEHR technical ISM states can be viewed within the openEHR Procedure archetype[3] and the status data element can be viewed in the FHIR Procedure profile[4]. As an example, an expanded version of the proposed Procedure roadmap featured below, now includes the generic ISM states along with the related Procedure-specific careflow steps. Note that in some instances more than one careflow step may be necessary per ISM state.

The ISM states are depicted in grey hexagonal shapes and will be consistent across all Intervention data groups that are based on the openEHR ACTION class of archetypes. Procedure-specific careflow steps have been assigned to each ISM state. By default, the ‘Date/time’ and ‘Reason’ for transitioning to a new state will be available for recording against each careflow step, along with any or all of the relevant data elements from the ‘data’ grouping in the mind map.    

Proposed Procedure Road Map including ISM states.

Changes from AUCDI R1 to AUCDI R2 and onwards

A Procedure completed and a Vaccination administered data group were included in AUCDI R1. For the purposes of the initial AUCDI R1, they were intentionally limited to record single events that have occurred specifically whether a procedure has been performed, or a vaccine has been administered, effectively allowing the recording the completion of a specific event only. To support future use cases, structural enhancements were necessary, to allow the documentation of intervention-related activities in electronic health records and to support detailed tracking of their progression, especially within a shared or distributed care plan.

These enhancements include the introduction of the set of state-related attributes that both incorporate and expand upon the initial ‘completed’ state established in the initial AUCDI R1 Procedure and Vaccination data groups and their names updated. Any new ‘Intervention’ data groups will align with the enhanced structure outlined above.

[1] openEHR Standard Instruction State Machine [Internet]. EHR Information Model (2020); openEHR International. Available from: https://specifications.openehr.org/releases/RM/latest/ehr.html#_the_standard_instruction_state_machine_ism

[2] Careflow Process to State Machine Mapping Machine [Internet]. EHR Information Model (2020); openEHR International. Available from: https://specifications.openehr.org/releases/RM/latest/ehr.html#_careflow_process_to_state_machine_mapping

[3] https://ckm.openehr.org/ckm/archetypes/1013.1.204

[4] https://hl7.org.au/fhir/core/0.2.1-preview/StructureDefinition-au-core-procedure.html