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

@ 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

Coding of the specific procedure with a terminology is preferred, where possible.

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 or process-related reason for the procedure.

Considerations

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

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/or time when the entire procedure, or the last component of a multicomponent procedure, was finished.

Considerations

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.

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 activity or care pathway step not captured in other fields.

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

@ internal @

Identification of the procedure by name.

Considerations

Coding of the specific procedure with a terminology is preferred, where possible.

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 or process-related reason for the procedure.

Considerations

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

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/or time when the entire procedure, or the last component of a multicomponent procedure, was finished.

Considerations

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.

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 activity or care pathway step not captured in other fields.

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

@ 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

Coding of the specific procedure with a terminology is preferred, where possible.

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 or process-related reason for the procedure.

Considerations

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

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/or time when the entire procedure, or the last component of a multicomponent procedure, was finished.

Considerations

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.

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 activity or care pathway step not captured in other fields.

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