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.

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

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.

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).

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.

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.

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|

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.

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|

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.

Urgency of the procedure.

Considerations

Coding with a terminology is preferred, where possible.

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.

Structured information about the procedure.

Considerations

Use to capture detailed, structured information about anatomical location, method & technique, equipment used, devices implanted, results, findings etc.

Outcome of procedure performed.

Considerations

Coding with a terminology is preferred, where possible.

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.

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.

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.

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.

The type of procedure.

Considerations

This pragmatic data element may be used to support organisation within the user interface.

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.

Considerations

None

Identification of the body site for the procedure.

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|

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

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.

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).

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.

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.

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.

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.

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.

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.

@ internal @

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|

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.

Identification of the body site for the procedure.

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|

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|

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.

Urgency of the procedure.

Considerations

Coding with a terminology is preferred, where possible.

Structured information about the procedure.

Considerations

Use to capture detailed, structured information about anatomical location, method & technique, equipment used, devices implanted, results, findings etc.

Outcome of procedure performed.

Considerations

Coding with a terminology is preferred, where possible.

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.

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.

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.

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.

The type of procedure.

Considerations

This pragmatic data element may be used to support organisation within the user interface.

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.

Considerations

None

@ internal @

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.

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.

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.

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.

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

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.

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).

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.

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.

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|

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.

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|

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.

Urgency of the procedure.

Considerations

Coding with a terminology is preferred, where possible.

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.

Structured information about the procedure.

Considerations

Use to capture detailed, structured information about anatomical location, method & technique, equipment used, devices implanted, results, findings etc.

Outcome of procedure performed.

Considerations

Coding with a terminology is preferred, where possible.

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.

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.

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.

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.

The type of procedure.

Considerations

This pragmatic data element may be used to support organisation within the user interface.

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.

Considerations

None

Identification of the body site for the procedure.

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|

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

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.

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).

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.

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.

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.

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.

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.