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

• Content
• Detailed Descriptions
• Mappings
• XML
• JSON
• TTL

Logical Model: Procedure AUCDI

Official URL: https://aehrc.csiro.au/fhir/logical-models/ProcedureAUCDI				Version: 0.0.1
Draft as of 2023-09-11				Computable Name: ProcedureAUCDI
Keywords: core

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

Usage:

• This Logical Model Profile is not used by any profiles in this Implementation Guide

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

 

​Other representations of profile: CSV, Excel