Artifacts Summary

Sparked Logical Models, published by CSIRO. This guide is not an authorized publication; it is the continuous build for version 0.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/aehrc/logical-model-web/ and changes regularly. See the Directory of published versions

Contents:

Structures: Logical Models

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Structures: Logical Models

These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.

Adverse Reaction Event

The Adverse Reaction Event Logical Model Mindmap is shown below.

Information about a specific adverse reaction event caused by exposure to a specific substance.

Purpose

To record information about a specific adverse reaction event caused by exposure to a specific substance.

Misuse

Not to be used to record adverse events, including failures of clinical process, interventions or products. For example: abnormal use or mistakes/errors made in maladministration of an agent or substance; incorrect dosage; mislabelling; harm or injury caused by an intervention or procedure; overdose/poisoning etc. Use a specific archetype for this purpose.

Considerations

Use to record information about a specific adverse reaction event caused by exposure to a specific substance. The substance may be recorded in the 'Specific substance' element in this archetype, or in an appropriate element in the parent archetype in which this archetype is nested. This archetype is designed to be nested within the EVALUATION.adverse_reaction_risk or the OBSERVATION.adverse_reaction_monitoring archetypes, to record details about a specific reaction event, but it could also be nested within other archetypes where clinically appropriate. The scope of this archetype has deliberately focused on identifying a pragmatic data set that are used in most clinical systems or will be suitable for most common clinical scenarios; however, it permits extension of the model when additional detail is required, using the 'Reaction details', 'Exposure details', and 'Reporting details' slots. An extension may be required if a specialist allergist or immunologist needed to record a more detailed assessment as part of a report to regulatory bodies or within the context of a clinical trial.

Adverse Reaction Event AUCDI

The Adverse Reaction Event AUCDI Logical Model Mindmap is shown below.

Information about a specific adverse reaction event caused by exposure to a specific substance.

Purpose

To record information about a specific adverse reaction event caused by exposure to a specific substance.

Misuse

Considerations

Roadmap

Adverse Reaction Risk

The Adverse Reaction Risk Logical Model Mindmap is shown below.

Clinical assessment of the propensity for an individual to experience a harmful or undesirable physiological response if exposed, or re-exposed, to a substance.

Purpose

To record the clinical assessment of the propensity for an individual to experience an adverse reaction if exposed, or re-exposed, to a specified substance or class of substances.

Misuse

Not to be used for recording physiological reactions to physical agents, such as heat, cold, sunlight, vibration, exercise activity, by infectious agents or food contaminants. Use a specific archetype for EVALUATION.problem/diagnosis or CLUSTER.symptom/sign for this purpose. Not to be used to record adverse events, including failures of clinical process, interventions or products. For example: abnormal use, incorrect dosage or maladministration of an agent or substance; mislabelling; harm or injury caused by an intervention or procedure; overdose/poisoning etc. Use a specific archetype for the purpose. Not to be used to record an adverse reaction where the substance is unknown. Use EVALUATION.problem_diagnosis or CLUSTER.symptom_sign to record as part of the health record until a possible substance is identified. Not to be used to record reactions to transfusions of blood products. Use a specific archetype for this purpose. Not to be used for recording 'alerts'. Use EVALUATION.precaution, EVALUATION.contraindication or related archetypes for this purpose. Not to be used for recording failed therapy. Not to be used for the explicit recording of an absence (or negative presence) of a reaction to 'any substances' or to identified substances, for example ‘No known allergies or adverse reactions’ or ‘No known allergies to Penicillin’. Use the EVALUATION.exclusion_global or EVALUATION.exclusion_specific archetypes to express a positive statement of adverse reaction exclusion. Not to be used for the explicit recording that no information was able to be obtained about the adverse reaction status of a patient. Use the EVALUATION.absence archetype to record that a positive statement that information was not able to be obtained, for example, if a non-cooperative patient refuses to answer questions.

Considerations

Use to record a clinical assessment of a propensity for an adverse reaction upon future exposure to a specified substance or class of substances including, but not limited to, incipients and excipients in medicinal preparations, biological products, metal salts, and organic chemical compounds. This archetype is intended to provide a single place within the health record to document the propensity for the full range of reactions, from trivial to life-threatening:

immune-mediated: Types I-IV (including allergic reactions and hypersensitivities); or
non-immune-mediated: including pseudo-allergic reactions, side effects, intolerances, and drug toxicities. In clinical practice distinguishing between immune-mediated and non-immune-mediated reactions can be difficult. Identification of the type of reaction is not a proxy for seriousness or risk of harm to the patient. Where a propensity is identified, information or evidence about one or more reaction events can be recorded using the CLUSTER.adverse_reaction_event archetype in the 'Reaction event summary' SLOT. Identification of the severity of the manifestation of the reaction, recorded in the CLUSTER.adverse_reaction_event archetype, can inform the 'Criticality' of the adverse reaction risk. For example, experiencing anaphylaxis on first exposure to a substance would warrant setting a 'Criticality' of 'high', due to the high risk that anaphylaxis is likely to recur on second and subsequent exposures. This archetype has been designed to allow the recording of information about a specific substance (amoxycillin, oysters, or bee sting venom) or, alternatively, a class of substance (e.g. Penicillins). If a class of substance is recorded, identification of the exact substance can be recorded on a per-reaction basis using the CLUSTER.adverse_reaction_event archetype. Use to record information about the positive presence of the risk of an adverse reaction:
to support the direct clinical care of an individual;
as part of a managed adverse reaction or allergy/intolerance list;
to support the exchange of information about the propensity and events related to adverse reactions;
to inform adverse reaction reporting; and
to assist with computerised knowledge-based activities such as clinical decision support and alerts. The risk of an adverse reaction event or manifestation must always propose a causative substance or class of substance. If there is a degree of uncertainty that a specific substance is the cause, the level of uncertainty can be recorded using the ‘Verification status’ data element. If more than one possible substance may have caused a reaction/manifestation, each substance should be recorded using a separate instance of this adverse reaction risk archetype with the ‘Verification status’ set to an initial state of ‘Unconfirmed’ so that adverse reaction checking can be activated in clinical systems. If the substance is later proven not to be causal then the ‘Verification status’ can be modified to ‘Refuted’ - for example, after allergy testing.

Adverse Reaction Risk AUCDI

The Adverse Reaction Risk AUCDI Logical Model Mindmap is shown below.

A summary or overview of a clinical assessment that identifies the potential for a harmful or undesirable physiological reaction unique to an individual and associated with exposure to a specific substance.

Context

This data group documents a clinician’s recommendation to avoid future exposure to a particular substance, emphasising the assessment of exposure risk and its substantiating evidence. In Release 1 the ‘Clinical evidence’ supporting the risk assessment is limited to the ‘Manifestation’ - symptoms or signs observed as part of an adverse reaction occurring on exposure to a substance. In future releases, it is anticipated that the details about the reaction event will be expanded and additional types of clinical evidence, such as immunogenetic test results can be included.

While highlighting the clinical safety driver for accurately documenting adverse reactions, it is also important to recognise that such documentation within a clinical system will not always be limited to reactions categorised as true allergies, hypersensitivities, or intolerances. In practice, clinicians may encounter situations where the underlying pathophysiology of a reaction may not be known. Despite this, they still need to document that, in their judgment, the patient should avoid a specific substance. Such an entry is vital to prompt clinical safety alerts that prevent re-exposure, with previous manifestations offering insights into the risk of potential future harm, regardless of the unknown physiological mechanisms involved.

Use cases include, but are not limited to:

'Adverse Reaction List', or similar document, containing one or more ‘Adverse reaction summary’ data groups,
Triggering clinical decision alerts when prescribing, dispensing and administering a medication, and
To exchange safety-critical adverse reaction information with other healthcare providers.

Purpose

To record:

An assessment of the risk or propensity of a future adverse reaction if exposed, or re-exposed, to an identified substance.
Evidence supporting the risk assessment, such as a summary of each exposure event or genomics test results.

Misuse

Not to be used to record a diagnosis of an adverse reaction as the conclusion of a clinical consultation or investigation – use the Problem/Diagnosis data type for this purpose.
Not to be used for recording predictable physiological reactions on exposure to physical agents or activities, such as heat, cold, sunlight, vibration, exercise, by infectious agents, or food contaminants.
Not to be used to record adverse events, including failures of clinical processes, interventions, or products. For example, abnormal use, incorrect dosage or maladministration of an agent or substance, mislabelling, overdose, or poisoning.

Supported Models

Adverse reaction risk, Published archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2024 Feb 05]. Available from: https://ckm.openehr.org/ckm/archetypes/1013.1.7022
Adverse reaction event, Published archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2024 Feb 05]. Available from: https://ckm.openehr.org/ckm/archetypes/1013.1.5795
AllergyIntolerance, HL7 FHIR Resource [Internet]. Health Level Seven International; [cited: 2024 Feb 05]. Available from: https://hl7.org/fhir/R5/allergyintolerance.html.
AllergyIntolerance, International Patient Summary Implementation Guide, [Internet]. HL7 International / Patient care; [cited: 2024 Feb 05]. Available from: https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-AllergyIntolerance-uv-ips.html.

Considerations

Substances include but are not limited to:
- A therapeutic substance administered correctly at an appropriate dosage for the individual, including medications or vaccinations,
- Food,
- Material derived from plants or animals, or
- Venom from insect stings.
Manifestations include any symptom, sign, or diagnosis.
It is also possible to record the absence of a reaction on re-exposure to a substance where an existing adverse reaction summary exists. This may trigger further investigation to confirm whether the previously assumed causal relationship to the substance is correct or mistaken.
This data group is intended to provide a single place within the health record to document the propensity for the full range of adverse reactions, from trivial to life-threatening, irrespective of the underlying physical mechanism. This includes but is not limited to:
- Immune-mediated: Types I-IV (including allergic reactions and hypersensitivities); or
- Non-immune-mediated: such as pseudo-allergic reactions, side effects, intolerances, and drug toxicities in individuals with impaired excretion.
In Release 1, all adverse reactions are assumed active in the context of a summary for exchange.
In future updates, it is anticipated this data group will be extended to incorporate additional detail.

Roadmap

Implanted Medical Device Summary

The Implanted Medical Device Summary Logical Model Mindmap is shown below.

A summary or overview detailing the history and context of use for a specified type of implantable medical device, including details about specific implantation episodes.

Purpose

To record a summary or overview detailing the history and context of use for a specified type of implantable medical device.

Misuse

Not to be used to request a medical device. Use a relevant INSTRUCTION archetype for this purpose. Not to be used to record the activities that occur in the insertion or removal of an implant. Use the ACTION.procedure archetype for this purpose.

Considerations

Use to record a summary or overview of a single implanted medical device, or category of device. The intended scope of this archetype includes, but is not limited to:

a cochlear implant;
an intracardiac pacemaker;
one or more aneurysm clips;
a femoral head prosthesis;
a coronary stent;
bone fixation devices such as screws or plates;
deep brain electrical stimulation system lead; or
deep brain electrical stimulation system pulse generator. This archetype has been specifically designed to:
support the management of implanted medical devices over time;
assist in the identification of implanted medical devices in situ that may carry health risks for imaging and other health-related activities; and
carry critical information such as device identification that will support product recalls. The repeating 'Specific implant details' CLUSTER supports documentation about each insertion of each specific medical device, including more precise identification and summary details about the device insertion and removal. This archetype can be further developed to document medical device details such as the manufacturer, batch numbers and device identifiers by nesting the CLUSTER.device_details in the 'Structured device detail' SLOT. In practice, some clinical systems will need to record specific and detailed INSTRUCTION and ACTION archetypes to reflect the request for a medical device and subsequent activities that need to be recorded as that request is carried out. There will inevitably be some overlap between this summary and these detailed archetypes. All may be necessary in different contexts however, where possible, ideally this summary should be derived from the point of care INSTRUCTION and ACTION documentation by clinicians, to prevent the need for clinicians to duplicate data input.

Implanted Medical Device Summary EREQDI

The Implanted Medical Device Summary EREQDI Logical Model Mindmap is shown below.

A summary or overview detailing the history and context of use for a specified type of implantable medical device, including details about specific implantation episodes.

Purpose

To record a summary or overview detailing the history and context of use for a specified type of implantable medical device.

Misuse

Considerations

Use to record a summary or overview of a single implanted medical device, or category of device. The intended scope of this archetype includes, but is not limited to:

a cochlear implant;
an intracardiac pacemaker;
one or more aneurysm clips;
a femoral head prosthesis;
a coronary stent;
bone fixation devices such as screws or plates;
deep brain electrical stimulation system lead; or
deep brain electrical stimulation system pulse generator. This archetype has been specifically designed to:
support the management of implanted medical devices over time;
assist in the identification of implanted medical devices in situ that may carry health risks for imaging and other health-related activities; and
carry critical information such as device identification that will support product recalls. The repeating 'Specific implant details' CLUSTER supports documentation about each insertion of each specific medical device, including more precise identification and summary details about the device insertion and removal. This archetype can be further developed to document medical device details such as the manufacturer, batch numbers and device identifiers by nesting the CLUSTER.device_details in the 'Structured device detail' SLOT. In practice, some clinical systems will need to record specific and detailed INSTRUCTION and ACTION archetypes to reflect the request for a medical device and subsequent activities that need to be recorded as that request is carried out. There will inevitably be some overlap between this summary and these detailed archetypes. All may be necessary in different contexts however, where possible, ideally this summary should be derived from the point of care INSTRUCTION and ACTION documentation by clinicians, to prevent the need for clinicians to duplicate data input.

Roadmap

Problem Diagnosis

The Problem Diagnosis Logical Model Mindmap is shown below.

Details about a single identified health condition, injury, disability or any other issue which impacts on the physical, mental and/or social well-being of an individual.

Purpose

For recording details about a single, identified health problem or diagnosis. The intended scope of a health problem is deliberately kept loose in the context of clinical documentation, so as to capture any real or perceived concerns that may adversely affect an individual's wellbeing to any degree. A health problem may be identified by the individual, a carer or a healthcare professional. However, a diagnosis is additionally defined based on objective clinical criteria, and usually determined only by a healthcare professional.

Misuse

Not to be used to record symptoms as described by the individual - use the CLUSTER.symptom archetype, usually within the OBSERVATION.story archetype. Not to be used to record examination findings - use the family of examination-related CLUSTER archetypes, usually nested within the OBSERVATION.exam archetype. Not to be used to record laboratory test results or related diagnoses, for example pathological diagnoses - use an appropriate archetype from the laboratory family of OBSERVATION archetypes. Not to be used to record imaging examination results or imaging diagnoses - use an appropriate archetype from the imaging family of OBSERVATION archetypes. Not to be used to record 'Differential Diagnoses' - use the EVALUATION.differential_diagnosis archetype. Not to be used to record 'Reason for Encounter' or 'Presenting Complaint' - use the EVALUATION.reason_for_encounter archetype. Not to be used to record procedures - use the ACTION.procedure archetype. Not to be used to record details about pregnancy - use the EVALUATION.pregnancy_bf_status and EVALUATION.pregnancy and related archetypes. Not to be used to record statements about health risk or potential problems - use the EVALUATION.health_risk archetype. Not to be used to record statements about adverse reactions, allergies or intolerances - use the EVALUATION.adverse_reaction archetype. Not to be used for the explicit recording of an absence (or negative presence) of a problem or diagnosis, for example ‘No known problem or diagnoses’ or ‘No known diabetes’. Use the EVALUATION.exclusion-problem_diagnosis archetype to express a positive statement about exclusion of a problem or diagnosis.

Considerations

Use for recording details about a single, identified health problem or diagnosis. Clear definitions that enable differentiation between a 'problem' and a 'diagnosis' are almost impossible in practice - we cannot reliably tell when a problem should be regarded as a diagnosis. When diagnostic or classification criteria are successfully met, then we can confidently call the condition a formal diagnosis, but prior to these conditions being met and while there is supportive evidence available, it can also be valid to use the term 'diagnosis'. The amount of supportive evidence required for the label of diagnosis is not easy to define and in reality probably varies from condition to condition. Many standards committees have grappled with this definitional conundrum for years without clear resolution. For the purposes of clinical documentation with this archetype, problem and diagnosis are regarded as a continuum, with increasing levels of detail and supportive evidence usually providing weight towards the label of 'diagnosis'. In this archetype it is not neccessary to classify the condition as a 'problem' or 'diagnosis'. The data requirements to support documentation of either are identical, with additional data structure required to support inclusion of the evidence if and when it becomes available. Examples of problems include: the individual's expressed desire to lose weight, but without a formal diagnosis of Obesity; or a relationship problem with a family member. Examples of formal diagnoses would include a cancer that is supported by historical information, examination findings, histopathological findings, radiological findings and meets all requirements for known diagnostic criteria. In practice, most problems or diagnoses do not sit at either end of the problem-diagnosis spectrum, but somewhere in between. This archetype can be used within many contexts. For example, recording a problem or a clinical diagnosis during a clinical consultation; populating a persistent Problem List; or to provide a summary statement within a Discharge Summary document. In practice, clinicians use many context-specific qualifiers such as past/present, primary/secondary, active/inactive, admission/discharge etc. The contexts can be location-, specialisation-, episode- or workflow-specific, and these can cause confusion or even potential safety issues if perpetuated in Problem Lists or shared in documents that are outside of the original context. These qualifiers can be archetyped separately and included in the ‘Status’ slot, because their use varies in different settings. It is expected that these will be used mostly within the appropriate context and not shared out of that context without clear understanding of potential consequences. For example, a primary diagnosis to one clinician may be a secondary one to another specialist; an active problem can become inactive (or vice versa) and this can impact the safe use of clinical decision support. In general these qualifiers should be applied locally within the context of the clinical system, and in practice these statuses should be manually curated by clinicians to ensure that lists of Current/Past, Active/Inactive or Primary/Secondary Problems are clinically accurate. This archetype will be used as a component within the Problem Oriented Medical Record as described by Larry Weed. Additional archetypes, representing clinical concepts such as condition as an overarching organiser for diagnoses etc, will need to be developed to support this approach. In some situations, it may be assumed that identification of a diagnosis fits only within the expertise of physicians, but this is not the intent for this archetype. Diagnoses can be recorded using this archetype by any healthcare professional.

Problem Diagnosis AUCDI

The Problem Diagnosis AUCDI Logical Model Mindmap is shown below.

A summary or overview of a single health condition, injury, disability, or any other issue that impacts the physical, mental and/or social well-being of an individual.

Context

This data group documents a summary or overview of a single active, inactive, or resolved problem or diagnosis, gathered and integrated from various information sources, including multiple consultations and other activities, accumulated, and updated over time. An exception is summary information about a specific pregnancy; a condition that requires a very different data structure.

Traditionally, differentiating between problems and diagnoses has been difficult because they often exist on a continuum, both conceptually and in practice. As clinical evidence accumulates, what begins as a 'problem' may develop into a definitive 'diagnosis.' Adopting a unified data group for both facilitates the collection of clinical evidence and recognises the dynamic and interconnected nature of their relationship.

Use cases include, but are not limited to:

Recording a diagnosis as the conclusion of a Consultation note,
A 'Problem List', ‘Medical history’ or similar document, containing one or more ‘Problem/Diagnosis summary’ data groups,
Triggering clinical decision support related to preventive health and chronic disease management, or
To exchange critical information about problems or diagnoses with other healthcare providers.

Purpose

To record summary information about a single problem or diagnosis.

Misuse

Not to be used to record summary information about a single pregnancy. The clinical requirements for recording summary details about a pregnancy are quite different to typical problems and diagnoses and therefore out of scope for this data group. It is anticipated that a separate ‘Pregnancy summary’ data group will be proposed for future releases of AUCDI. Note: problems or diagnoses identified during the pregnancy or as direct complications of the pregnancy may be added using this data group – for example, ‘Gestational diabetes’, ‘Pre-eclampsia’ or ‘Urinary tract infection’.

Considerations

Both problems or diagnoses can be recorded using this same data model without distinguishing and labelling them as one or the other. The recording pattern is closely aligned, and what may initially be considered a ‘soft’ problem may evolve towards a formal diagnosis as more clinical evidence is discovered.

In future updates, it is anticipated this data group will be extended to incorporate additional detail.

Roadmap

The openEHR ‘Problem/Diagnosis’ archetype and the FHIR ‘Condition’ resource are mature information models that have been used globally in a broad range of implementations over many years. They form the basis for this initial AUCDI R1 data group and provide guidance for potential future augmentation.

In addition, the 'Problem/Diagnosis name' value set can be extended to include problems identified from an allied health or Social Determinants of Health (SDOH) perspective, such as 'Food insecurity' and 'Financial insecurity'.

The mind map below demonstrates a proposed roadmap for developing the ‘Problem/Diagnosis summary’ data group based on the published openEHR ‘Problem/Diagnosis’ archetype.

Potential candidate data elements for Release 2:

Date/Time clinically recognised – this equates to the ‘Date of diagnosis’ for a formal diagnosis but is deliberately framed more loosely to support a date related to a softer problem.
Last updated – the timestamp indicates whether the information is current or outdated, serving as a critical marker of its timeliness.

Procedure

The Procedure Logical Model Mindmap is shown below.

A clinical activity carried out for screening, investigative, diagnostic, curative, therapeutic, evaluative or palliative purposes.

Purpose

To record information about the activities required to carry out a procedure, including the planning, scheduling, performance, suspension, cancellation, documentation and completion.

Misuse

Not to be used to record details about the anaesthetic - use a separate ACTION archetype for this purpose. Not to be used to record details about imaging investigations - use ACTION.imaging_exam for this purpose. Not to be used to record details about laboratory investigations - use ACTION.laboratory_test for this purpose. Not to be used to record details about education delivered - use ACTION.health_education for this purpose. Not to be used to record details about administrative activities - use specific ADMIN archetypes for this purpose. Not to be used to record details about related activities such as the use of frozen sections taken during an operation, medication administered as part of the procedure or when imaging guidance is used during the procedure - use separate and specific ACTION archetypes within the same template for this purpose . Not to be used to record a whole operation or procedure report - use a template in which this archetype is only one component of the full report.

Considerations

Use to record information about the activities required to carry out a procedure, including the planning, scheduling, performance, suspension, cancellation, documentation and completion. This is done by the recording of data against specific activities, as defined by the 'Pathway' careflow steps in this archetype. The scope of this archetype encompasses activities for a broad range of clinical procedures performed for evaluative, investigative, screening, diagnostic, curative, therapeutic or palliative purposes. Examples range from the relatively simple activities, such as insertion of an intravenous cannula, through to complex surgical operations. Additional structured and detailed information about the procedure can be captured using purpose-specific archetypes inserted into the 'Procedure detail' slot, where required. Timings related to a procedure can be managed in one of two ways:

Using the reference model - the time for performance of any pathway step will use the ACTION time attribute for each step.
Archetyped data elements: — the 'Scheduled date/time' data element is intended to record the precise time when the procedure is planned. Note: the corresponding ACTION time attribute for the Scheduled pathway step will record the time that the procedure was scheduled into a system, not the intended date/time on which the procedure is intended to be carried out; and — the 'Final end date/time' is intended to record the precise time when the procedure was ended. It can be used to document the complex procedures with multiple components. Note: the corresponding ACTION time attribute for the 'Procedure performed' will document the time each component performed was commenced. This 'Final end date/time' data element will record the date/time of the final active component of the procedure. This will enable a full duration of the active procedure to be calculated. Within the context of an Operation Report, this archetype will be used to record only what was done during the procedure. Separate archetypes will be used to record the other required components of the Operation Report, including the taking of tissue specimen samples, use of imaging guidance, operation findings, post-operative instructions and plans for follow up. Within the context of a Problem list or summary, this archetype may be used to represent procedures that have been performed. The EVALUATION.problem_diagnosis will be used to represent the patient's problems and diagnoses. In practice, many procedures (for example, in ambulatory care) will occur once and not be ordered in advance. The details about the procedure will be added against the pathway step, 'Procedure completed'. In some cases a recurring procedure will be ordered, and in this situation data against the 'Procedure performed' step will be recorded on each occasion, leaving the instruction in the active state. When the last occurrence is recorded the 'Procedure completed' action is recorded showing that this order is now in the completed state. In other situations, such as secondary care, there may be a formal order for a procedure using a corresponding INSTRUCTION archetype. This ACTION archetype can then be used to record the workflow of when and how the order has been carried out. Recording information using this ACTION archetype indicates that some sort of activity has actually occurred; this will usually be the procedure itself but may be a failed attempt or another activity such as postponing the procedure. If there is a formal order for the procedure, the state of this order is represented by the Pathway step against which the data is recorded. For example, using this archetype the progressing state of a Gastroscopy order may be recorded through separate entries in the EHR progress notes at each 'Pathway' step:
record the scheduled Start date/time for the gastroscopy (Procedure scheduled); and
record that the gastroscopy procedure has been completed, including information about the procedure details (Procedure completed). Please note that in the openEHR Reference Model there is a 'Time' attribute, which is intended to record the date and time at which each pathway step of the Action was performed. This is the attribute to use to record the start of the procedure (using the 'Procedure performed' pathway step) or the time that the procedure was aborted (using the 'Procedure aborted' pathway step).

Procedure AUCDI

The Procedure AUCDI Logical Model Mindmap is shown below.

A clinical procedure is an intentional intervention to diagnose, treat or manage a health condition, often involving invasive or potentially harmful techniques requiring skin or mucosal penetration or tissue manipulation.

Context

This data group documents details about a single procedure event that has been performed and/or completed.

The definition of procedures can be challenging. In clinical terminologies such as SNOMED CT, the scope of a procedure can be extremely broad, including clinical activities such as patient transportation, day care services, home modification, or exercise. However, the data structure for the ‘Procedure completed data group’ is specifically designed to capture activities performed on an individual to diagnose, treat, or manage a health condition, usually involving invasive or potentially harmful techniques. In this context, there is no precise definition of what exactly is and is not a procedure; there will likely be some ‘grey zones’ that require clinical documentary discretion, depending on the clinical context – for example, procedures related to diagnostic investigations or proctoscopy.

The structure for documenting a procedure markedly differs from that necessary to capture details about a medication condition. This distinction becomes more apparent when comparing the ‘Procedure completed’ data group to the ‘Problem/Diagnosis summary’, and the divergence is even more apparent on reviewing the extended, future roadmap models. It is noted that some clinical systems currently use a generic data structure to record both completed procedures and manage active and inactive problems or diagnoses. Vendors of clinical systems will need to consider the shift towards the separated modelling patterns. The differentiation of models is necessary because of the inherent differences in each type of data; the ‘Problem/Diagnosis summary’ serves as an evolving overview of an ongoing condition, whereas the Procedure data represents a historical account of a past event. Implementing this separation of models will not only improve the accuracy and clarity of electronic health records but also significantly support more accurate clinical decision support systems. Use cases include, but are not limited to:

Recording a procedure completed as part of a Consultation note or Operation note, for example:
- Taking a blood sample,
- Repair of a laceration or suture removal,
- Intubation,
- ECG,
- Skin prick test
- Insertion of an intravenous cannula or a urinary catheter,
- Endoscopy or laparoscopy,
- Biopsy of a skin lesion,
- Manual manipulation of a fracture or dislocation,
- External version of a foetus,
- Electrical cardioversion, or
- Coronary artery bypass graft operation.
A ‘Procedure list', ‘Surgical history’ or similar document containing one or more ‘Procedure completed’ data groups, or
To exchange critical information about past operations or procedures with other healthcare providers.

Purpose

To record details about a procedure that has been performed or carried out.

Misuse

Not to be used to record vaccination administration – use the ‘Vaccination administration’ data group for this purpose.
Not to be used to record problem/diagnosis – use the ‘Problem/Diagnosis Summary’ data group for this purpose.
Not to be used to record information about imaging service events – a specific data model for this purpose will be developed in a future release of AUCDI.
Not to be used to record non-invasive procedure events found in some terminology coding hierarchies, such as patient transportation, day care services, home modification or exercise.

Considerations

Significant procedures can be persisted within a curated Procedure or Surgical History list (or similar).
In future updates, it is anticipated this data group will be extended to incorporate additional detail.

Roadmap

Service Request

The Service Request Logical Model Mindmap is shown below.

Request for a health-related service or activity to be delivered by a clinician, organisation or agency.

Purpose

A generic framework for a request for a health-related service or activity to be delivered by a clinician, organisation or agency.

Considerations

Use to record a request for a health-related service or activity to be delivered by a clinician, organisation or agency. This generic data group has been designed as a framework that can be used as the basis for a wide range of requests:

a request from one clinician, organisation or agency to another clinician, organisation or agency for a health-related service. For example: a referral to a specialist clinician for treatment or a second clinical opinion; transfer of care to an emergency department; four hourly vital signs monitoring; diagnostic investigations; and provision of home services from a municipal council; or
a request for a follow-up service to be scheduled for the same clinician, organisation or agency. For example: an outpatient appointment for review in 6 weeks. It can be used to represent a request for one or more services, in one of two ways:
If multiple services need to be requested and the information recorded in the 'protocol' (for example 'Receiver') is the same - use a separate 'Activity' instance within this data group for each request.
If multiple services need to be requested and the information recorded in the 'protocol' (for example 'Receiver') is different - use a separate instance of this data group for each request. The 'Service due' data element supports common use cases for stipulating the simple timing for delivery of the request on a single occasion. For situations with more complicated timing requirements or a series of services, use other attributes of the 'Timing data type in 'Complex timing' SLOT. Implementation examples:
Consider a clinician referring a patient to an Endocrinologist for diabetes treatment advice - the 'Service name will be 'Referral'; the 'Clinical indication' will be 'Type 1 Diabetes Mellitus'; the 'Reason for request' may be 'Difficulty controlling early evening hyperglycaemia; the 'Clinical context' may contain a narrative about the duration and previous management of their diabetes, current treatment, plus recent weight gain and information about the recent death of their spouse; current treatment; 'Intent' may be 'Second opinion' or 'Handover of care'.
Consider a clinician ordering diabetes education - The 'Service name' will be 'Diabetes education'; the 'Clinical indication' will be 'Type 1 Diabetes Mellitus'; the 'Reason for request' may be 'New diagnosis' and 'Prevention of ketoacidosis'; and 'Clinical context' may be 'Newly diagnosed diabetic for initial education and instruction in insulin administration'. If delivery of the complete service requires more than one activity, such as 'four sessions at fortnightly intervals, commencing one week after discharge from hospital', use the CLUSTER.service_direction and associated CLUSTER.timing_nondaily data group, nested within the 'Complex timing' SLOT.
Consider a clinician ordering a meal home-delivery service from the municipal council - the 'Service name' may be 'Meals on wheels program'; the 'Clinical indication' may be 'Emphysema'; the 'Reason for request' may be 'Unable to shop or cook independently'. The complex timing for this requires the use of the CLUSTER.service_direction and associated CLUSTER.timing_nondaily data group nested within the 'Complex timing' SLOT to define the delivery requirements such as 'daily for 6 months'.
Consider a clinician ordering a follow-up appointment in 6 weeks. 'Follow-up appointment' will be the 'Service name'. If they enter '6 weeks' as the proposed timing for the appointment in the User Interface, the clinical system will record the date six weeks from today in the 'Service due' data element.
Consider a clinician ordering an ultrasound of the left leg to exclude a deep venous thrombosis - use the more specific ' Medical imaging request' data group.
Consider a clinician ordering a recurring blood test, such as an INR - use the more specific 'Pathology test request' data group.

Service Request EREQDI

The Service Request EREQDI Logical Model Mindmap is shown below.

Request for a health-related service or activity to be delivered by a clinician, organisation or agency.

Context

The 'Service request' data group is a generic framework intended for any service request or referral a health-related service or activity which will be fulfilled by a clinician, organisation or agency. It comprises the common data elements that form the basis of most of the common types of requests used in healthcare. As a result it has a broad range of use, for both clinical and social care purposes.

In the context of eRequesting, this generic data group has been specialised for two very specific purposes - to request a Pathology test and a Medical imaging test. The underlying data elements for all three data groups, Service request and the two specialisations is in common. It is anticipated that additional specializations may be added to AUCDI in the same way as part of future releases.

Purpose

A generic framework for a request for a health-related service or activity to be delivered by a clinician, organisation or agency.

Supported Models

Service request, Published archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2024-04-24]. Available from: https://ckm.openehr.org/ckm/archetypes/1013.1.614.
ServiceRequest, HL7 FHIR Resource [Internet]. Health Level Seven International; [cited: 2024-Apr- 24]. Available from: https://hl7.org/fhir//R5/servicerequest.html.

Considerations

Use to record a request for a health-related service or activity to be delivered by a clinician, organisation or agency.

This generic data group has been designed as a framework that can be used as the basis for a wide range of requests:

a request from one clinician, organisation or agency to another clinician, organisation or agency for a health-related service. For example: a referral to a specialist clinician for treatment or a second clinical opinion; transfer of care to an emergency department; four hourly vital signs monitoring; diagnostic investigations; and provision of home services from a municipal council; or
a request for a follow-up service to be scheduled for the same clinician, organisation or agency. For example: an outpatient appointment for review in 6 weeks.

It can be used to represent a request for one or more services, in one of two ways:

If multiple services need to be requested and the information recorded in the 'protocol' (for example 'Receiver') is the same - use a separate 'Activity' instance within this data group for each request.
If multiple services need to be requested and the information recorded in the 'protocol' (for example 'Receiver') is different - use a separate instance of this data group for each request.

Implementation examples:

Consider a clinician referring a patient to an Endocrinologist for diabetes treatment advice - the 'Service name will be 'Referral'; the 'Clinical indication' will be 'Type 1 Diabetes Mellitus'; the 'Reason for request' may be 'Difficulty controlling early evening hyperglycaemia; the 'Clinical context' may contain a narrative about the duration and previous management of their diabetes, current treatment, plus recent weight gain and information about the recent death of their spouse; current treatment; 'Intent' may be 'Second opinion' or 'Handover of care'.
Consider a clinician ordering diabetes education - The 'Service name' will be 'Diabetes education'; the 'Clinical indication' will be 'Type 1 Diabetes Mellitus'; the 'Reason for request' may be 'New diagnosis' and 'Prevention of ketoacidosis'; and 'Clinical context' may be 'Newly diagnosed diabetic for initial education and instruction in insulin administration'. If delivery of the complete service requires more than one activity, such as 'four sessions at fortnightly intervals, commencing one week after discharge from hospital', use the CLUSTER.service_direction and associated CLUSTER.timing_nondaily data group, nested within the 'Complex timing' SLOT.
Consider a clinician ordering a meal home-delivery service from the municipal council - the 'Service name' may be 'Meals on wheels program'; the 'Clinical indication' may be 'Emphysema'; the 'Reason for request' may be 'Unable to shop or cook independently'. The complex timing for this requires the use of the CLUSTER.service_direction and associated CLUSTER.timing_nondaily data group nested within the 'Complex timing' SLOT to define the delivery requirements such as 'daily for 6 months'.
Consider a clinician ordering a follow-up appointment in 6 weeks. 'Follow-up appointment' will be the 'Service name'. If they enter '6 weeks' as the proposed timing for the appointment in the User Interface, the clinical system will record the date six weeks from today in the 'Service due' data element.
Consider a clinician ordering an ultrasound of the left leg to exclude a deep venous thrombosis - use the more specific ' Medical imaging request' data group.
Consider a clinician ordering a recurring blood test, such as an INR - use the more specific 'Pathology test request' data group.

Roadmap