Generated Narrative: StructureDefinition ProcedureAUCDI Name Flags Card. Type Description & Constraints Procedure S 0..* Procedure Procedure AUCDI Elements defined in Ancestors:Description, Protocol #xD; Description 0..1 BackboneElement Description #xD; Procedurename S 1..1 CodeableConcept Procedure name #xD; ProcedureDescription 0..1 string Procedure Description #xD; Bodysite S 0..* CodeableConcept Body site #xD; Indication S 0..* CodeableConcept Indication #xD; Method 0..* string Method #xD; Urgency 0..1 string Urgency #xD; Proceduredetail 0..* Reference() Procedure detail #xD; Outcome 0..* string Outcome #xD; Proceduraldifficulty 0..* string Procedural difficulty #xD; Complication 0..* string Complication #xD; Scheduleddatetime 0..1 dateTime Scheduled date time #xD; Finalenddatetime S 0..1 dateTime Date performed #xD; Multimedia 0..* Reference() Multimedia #xD; Proceduretype 0..1 string Procedure type #xD; Reason 0..* string Reason #xD; Comment S 0..1 string Comment #xD; Protocol 0..1 BackboneElement Protocol #xD; Requestororderidentifier 0..1 string Requestor order identifier #xD; Requestor 0..1 Reference() Requestor #xD; Receiverorderidentifier 0..1 string Receiver order identifier #xD; Receiver 0..* Reference() Receiver #xD; Extension 0..* Reference() Extension #xD; Documentation for this format
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**
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).
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.
To record information about the activities required to carry out a procedure, including the planning, scheduling, performance, suspension, cancellation, documentation and completion.
* 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.
* 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.
To record details about a procedure that has been performed or carried out.
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.
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.
**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.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
Extensions that cannot be ignored even if unrecognized
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R4/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Coding of the specific procedure with a terminology is preferred, where possible.
It is strongly recommended that ‘Procedure name’ be coded with a terminology capable of triggering decision support, where possible. Free text entry should only be permitted if no appropriate coded value is available.
The [Procedure value set](https://healthterminologies.gov.au/fhir/ValueSet/procedure-1) published by the NCTS currently includes all Procedure concepts within SNOMED CT-AU.
SNOMED CT-AU: * 232722009|Coronary artery bypass grafts x 4| * 312681000|Bone density scan| * 239592001|Forefoot amputation| * 34309001|Drainage of tonsil| * 307998000|Excision of pigmented skin lesion| * 428923005|Radiotherapy to breast|
Identification of the procedure by name.
**Considerations** It is strongly recommended that ‘Procedure name’ be coded with a terminology capable of triggering decision support, where possible. Free text entry should only be permitted if no appropriate coded value is available. **Example** SNOMED CT-AU: * 232722009|Coronary artery bypass grafts x 4| * 312681000|Bone density scan| * 239592001|Forefoot amputation| * 34309001|Drainage of tonsil| * 307998000|Excision of pigmented skin lesion| * 428923005|Radiotherapy to breast|
For example: description about the performance and findings from the the procedure, the aborted attempt or the cancellation of the procedure.
Narrative description about the procedure, as appropriate for the pathway step.
**Considerations** For example: description about the performance and findings from the the procedure, the aborted attempt or the cancellation of the procedure.
Coding of the indication with a terminology is preferred, where possible. This data element allows multiple occurrences. For example: 'Failed bowel preparation' or 'Bowel cancer screening'.
It is recommended that ‘Clinical indication’ be coded, where possible. Free text entry should only be permitted if no appropriate coded value is available. This data element has multiple occurrences to allow the recording of more than one clinical indication per procedure.
SNOMED CT-AU: * 4557003|Unstable angina| * 59848001|Obstructive jaundice| * 46635009|Diabetes Mellitus Type 1| * 33261009|Abscess of tonsil| * 80201000119103|Atypical pigmented lesion| * 289916006|Family history of kidney disease| * 772150003|Diphtheria suspected| * 422181004|Antibiotic prophylaxis| * 274920002|Jellyfish sting|
The [Reason for Procedure value set](https://healthterminologies.gov.au/fhir/ValueSet/reason-for-procedure-1) published by the NCTS is a broad reference set including (most) clinical findings, situation with explicit context, and event concepts.
The clinical symptom, sign or diagnosis that necessitates the procedure.
**Considerations** It is recommended that ‘Clinical indication’ be coded, where possible. Free text entry should only be permitted if no appropriate coded value is available. This data element has multiple occurrences to allow the recording of more than one clinical indication per procedure. **Example** SNOMED CT-AU: * 4557003|Unstable angina| * 59848001|Obstructive jaundice| * 46635009|Diabetes Mellitus Type 1| * 33261009|Abscess of tonsil| * 80201000119103|Atypical pigmented lesion| * 289916006|Family history of kidney disease| * 772150003|Diphtheria suspected| * 422181004|Antibiotic prophylaxis| * 274920002|Jellyfish sting|
Use this data element to record simple terms or a narrative description. If the requirements for recording the method require more complex modelling then this can be represented by additional archetypes within the 'Procedure detail' SLOT in this archetype. If the method is included in the 'Procedure name' via precoordinated codes, this data element becomes redundant.
Identification of specific method or technique for the procedure.
**Considerations** Use this data element to record simple terms or a narrative description. If the requirements for recording the method require more complex modelling then this can be represented by additional archetypes within the 'Procedure detail' SLOT in this archetype. If the method is included in the 'Procedure name' via precoordinated codes, this data element becomes redundant.
Coding with a terminology is preferred, where possible.
**Considerations** Coding with a terminology is preferred, where possible.
Occurrences for this data element are unbounded to allow for clinical scenarios such as removing multiple skin lesions in different places, but where all of the other attributes are identical. Use this data element to record simple terms or precoordinated anatomical locations. If the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations then use the CLUSTER.anatomical_location or CLUSTER.relative_location within the 'Procedure detail' SLOT in this archetype. If the anatomical location is included in the 'Procedure name' via precoordinated codes, this data element becomes redundant.
Identification of the body site for the procedure.
**Considerations** Occurrences for this data element are unbounded to allow for clinical scenarios such as removing multiple skin lesions in different places, but where all of the other attributes are identical. Use this data element to record simple terms or precoordinated anatomical locations. If the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations then use the CLUSTER.anatomical_location or CLUSTER.relative_location within the 'Procedure detail' SLOT in this archetype. If the anatomical location is included in the 'Procedure name' via precoordinated codes, this data element becomes redundant.
Use to capture detailed, structured information about anatomical location, method & technique, equipment used, devices implanted, results, findings etc.
Structured information about the procedure.
**Considerations** Use to capture detailed, structured information about anatomical location, method & technique, equipment used, devices implanted, results, findings etc.
Examples: The patient was agitated, insufficient emptying of the stomach before gastroscopy, a tumour in the bile ducts made it impossible to pass the scope through.
Difficulties or issues encountered during performance of the procedure.
**Considerations** Examples: The patient was agitated, insufficient emptying of the stomach before gastroscopy, a tumour in the bile ducts made it impossible to pass the scope through.
Use this data element to record simple terms or precoordinated complications. If the requirements for recording complication are more complex then use of a specific CLUSTER archetype within the 'Procedure detail' SLOT in this archetype is advised and this data element becomes redundant. Examples: Hematuria after a kidney biopsy, tissue irritation after insertion of intravenous catheter.
Details about any complication arising from the procedure.
**Considerations** Use this data element to record simple terms or precoordinated complications. If the requirements for recording complication are more complex then use of a specific CLUSTER archetype within the 'Procedure detail' SLOT in this archetype is advised and this data element becomes redundant. Examples: Hematuria after a kidney biopsy, tissue irritation after insertion of intravenous catheter.
Only for use in association with the 'Procedure scheduled' pathway step.
The date and/or time on which the procedure is intended to be performed.
**Considerations** Only for use in association with the 'Procedure scheduled' pathway step.
Only for use in association with the 'Procedure performed' pathway step, and in situations where the procedure is repeated on multiple occasions before being completed or there are multiple components to the whole procedure. This may be the same as the RM time attribute for the 'Procedure completed' pathway step.
* Partial dates are permitted. * For example: * 2015 * February 2015 * 7 February 2015 * 7 February 2015, 1:28 pm * 2015-02-07T13:28:17-05:00
The date, and optional time, when the procedure was performed.
**Considerations** * Partial dates are permitted. * For example: * 2015 * February 2015 * 7 February 2015 * 7 February 2015, 1:28 pm * 2015-02-07T13:28:17-05:00
Mulitimedia representation of a performed procedure.
This pragmatic data element may be used to support organisation within the user interface.
**Considerations** This pragmatic data element may be used to support organisation within the user interface.
For example: the reason for the cancellation or suspension of the procedure.
Reason that the activity or care pathway step for the identified procedure was carried out.
**Considerations** For example: the reason for the cancellation or suspension of the procedure.
Additional narrative about the procedure not captured in other fields.
* Specification of ‘Body site/laterality’ is recommended when it is necessary to provide additional clarity about the Procedure and the ‘Procedure name’ does not include or imply a specific body site. * This data element has multiple occurrences to allow the recording of more than one body site for each named procedure – for example, to record multiple related skin sites requiring excision of pigmented lesions in one procedure. * It is strongly recommended that the ‘Body site/laterality’ be coded with a terminology, where possible. Free text entry should only be permitted if no appropriate coded value is available.
SNOMED CT-AU: * 761920005|Bone structure of shaft of right humerus| * 51636004|Left ankle| * 38033009|Amputation stump| * 110501003|Upper outer quadrant of left breast|
The [Body Site value set](https://healthterminologies.gov.au/fhir/ValueSet/body-site-1) published by the NCTS is a subset of the SNOMED CT-AU Body structure hierarchy. It includes anatomical structures (including acquired structures) with laterality but excludes morphologic abnormalities and cellular/intercellular structures.
**Considerations** * Specification of ‘Body site/laterality’ is recommended when it is necessary to provide additional clarity about the Procedure and the ‘Procedure name’ does not include or imply a specific body site. * This data element has multiple occurrences to allow the recording of more than one body site for each named procedure – for example, to record multiple related skin sites requiring excision of pigmented lesions in one procedure. * It is strongly recommended that the ‘Body site/laterality’ be coded with a terminology, where possible. Free text entry should only be permitted if no appropriate coded value is available. **Example** SNOMED CT-AU: * 761920005|Bone structure of shaft of right humerus| * 51636004|Left ankle| * 38033009|Amputation stump| * 110501003|Upper outer quadrant of left breast|
This is equivalent to Placer Order Number in HL7 v2 specifications.
The local ID assigned to the order by the healthcare provider or organisation requesting the service.
**Considerations** This is equivalent to Placer Order Number in HL7 v2 specifications.
Details about the healthcare provider or organisation requesting the service.
This is equivalent to Filler Order Number in HL7 v2 specifications.
The ID assigned to the order by the healthcare provider or organisation receiving the request for service. This is also referred to as Filler Order Identifier.
**Considerations** This is equivalent to Filler Order Number in HL7 v2 specifications.
Details about the healthcare provider or organisation receiving the request for service.
For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.
Additional information required to capture local content or to align with other reference models/formalisms.
**Considerations** For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.