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

Purpose

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

Supporting Model(s)

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

Considerations

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

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

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

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

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

Implementation examples:

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

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.

@ 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 name of the service requested.

Considerations

Coding of the 'Service name' with an external terminology is strongly recommended, if available.

Category of service requested.

Considerations

Coding of the 'Service type' with an external terminology is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code.

Narrative description about the service requested.

Considerations

This data point should be used to describe the requested service in more detail.

The symptom, sign or diagnosis that prompts the need for the requested test.

Considerations

Coding of the 'Clinical indication' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.​

Narrative information about the individual and their situation, providing relevant background for the request.

Considerations

Also known as 'Clinical notes', although this name has intentionally been avoided to clearly differentiate from the 'Notes' attribute in many FHIR resources.

The concern or clinical question that needs to be addressed or resolved by the requested test.

Considerations

Coding of the 'Reason for request' with an external terminology is desirable, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.

Narrative description about the concern or clinical question that needs resolution.

Description of the intended outcome of the request.

Considerations

Coding of the 'Intent' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.​

Additional details and instructions about how the services are to be delivered.

Considerations

Coding of the 'Order detail' with an external terminology is desirable, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required.

The urgency of the request for service.

Considerations

Specific definitions of emergency and urgent will vary between clinical contexts, clinical systems and the nature of the request itself, so have not been defined in this data group. If more precise timing is required, use the 'Service due' data element.

The timing for provision of the requested service.

Considerations

This data element enables the recording of the intended timing for the service in various formats, including precise timing details such as specific dates and times, or through textual descriptors like ‘Next available’. Additionally, the Timing data type is designed to accommodate more complex timing scenarios if needed.

Details about more complex timing than available from 'Service due' or if a sequence of events is required to carry out this request 'Activity'.

Considerations

For example: 'hourly vital signs observations for 4 hours, then 4 hourly for 20 hours' or 'every third Wednesday for 3 visits' or 'Day 14-16 of the menstrual cycle'. Use other attributes of the 'Timing data type in 'Complex timing' SLOT.

Additional detail about the service requested.

Digital document, image, video or diagram supplied as additional information to support or clarify the context of the requested service.

Description of the supplementary information.

Details about requirements that are specific to the patient that need to be considered to support their attendance or participation in the provision of the service.

Considerations

For example: requirement for language translation; transport provision; or other personal factors.

Additional narrative about the service request 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 identifier assigned by the requesting clinical system.

Details about the clinician or organisation requesting the service.

The local identifier assigned to the request by the clinician or organisation receiving the request for service.

Details about the clinician or organisation receiving the request for service.

The status of the request for service as indicated by the requester.

Considerations

Status is used to denote whether this is the initial request, or a follow-up request to change or provide supplementary information. Coding with a terminology is preferred, where possible.

Details of additional clinicians, organisations or agencies that need to be informed of the outcome of this service request.

Considerations

For example: specialists or allied health providers who need to be notified of test results or available reports.

Details about a designated contact person or organisation and their preferred method of communication for urgent or emergency notifications concerning this request.

Considerations

For example: if the outcome of the request requires an urgent or emergency response by the requester or requesting organisation.

Advice from the requester to the receiver regarding the individual's qualification for the requested service.

Considerations

For example: meeting eligibility criteria for a specific funded service.

A recommendation from the requester to the receiver regarding the payment method for the service.

Considerations

For example: 'Private'; 'Government insurance scheme'; or 'Private insurance'.

Details about the identified individual or organisation assuming responsibility for payment of the service.

Considerations

This SLOT will only be used if a known payer has been identified. For example: an individual, such as a parent on behalf of a child; or an organisation such as a workplace, traffic accident, or government insurance scheme.

Additional information required to extend the model with local content or to align with other reference models or formalisms.

Considerations

For example: local information requirements; or additional metadata to align with FHIR.

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

Purpose

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

Supporting Model(s)

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

Considerations

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

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

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

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

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

Implementation examples:

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

@ internal @

The name of the service requested.

Considerations

Coding of the 'Service name' with an external terminology is strongly recommended, if available.

Category of service requested.

Considerations

Coding of the 'Service type' with an external terminology is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code.

Narrative description about the service requested.

Considerations

This data point should be used to describe the requested service in more detail.

The symptom, sign or diagnosis that prompts the need for the requested test.

Considerations

Coding of the 'Clinical indication' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.​

Narrative information about the individual and their situation, providing relevant background for the request.

Considerations

Also known as 'Clinical notes', although this name has intentionally been avoided to clearly differentiate from the 'Notes' attribute in many FHIR resources.

The concern or clinical question that needs to be addressed or resolved by the requested test.

Considerations

Coding of the 'Reason for request' with an external terminology is desirable, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.

Narrative description about the concern or clinical question that needs resolution.

Description of the intended outcome of the request.

Considerations

Coding of the 'Intent' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.​

Additional details and instructions about how the services are to be delivered.

Considerations

Coding of the 'Order detail' with an external terminology is desirable, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required.

The urgency of the request for service.

Considerations

Specific definitions of emergency and urgent will vary between clinical contexts, clinical systems and the nature of the request itself, so have not been defined in this data group. If more precise timing is required, use the 'Service due' data element.

The timing for provision of the requested service.

Considerations

This data element enables the recording of the intended timing for the service in various formats, including precise timing details such as specific dates and times, or through textual descriptors like ‘Next available’. Additionally, the Timing data type is designed to accommodate more complex timing scenarios if needed.

Details about more complex timing than available from 'Service due' or if a sequence of events is required to carry out this request 'Activity'.

Considerations

For example: 'hourly vital signs observations for 4 hours, then 4 hourly for 20 hours' or 'every third Wednesday for 3 visits' or 'Day 14-16 of the menstrual cycle'. Use other attributes of the 'Timing data type in 'Complex timing' SLOT.

Additional detail about the service requested.

Digital document, image, video or diagram supplied as additional information to support or clarify the context of the requested service.

Description of the supplementary information.

Details about requirements that are specific to the patient that need to be considered to support their attendance or participation in the provision of the service.

Considerations

For example: requirement for language translation; transport provision; or other personal factors.

Additional narrative about the service request not captured in other fields.

@ internal @

The local identifier assigned by the requesting clinical system.

Details about the clinician or organisation requesting the service.

The local identifier assigned to the request by the clinician or organisation receiving the request for service.

Details about the clinician or organisation receiving the request for service.

The status of the request for service as indicated by the requester.

Considerations

Status is used to denote whether this is the initial request, or a follow-up request to change or provide supplementary information. Coding with a terminology is preferred, where possible.

Details of additional clinicians, organisations or agencies that need to be informed of the outcome of this service request.

Considerations

For example: specialists or allied health providers who need to be notified of test results or available reports.

Details about a designated contact person or organisation and their preferred method of communication for urgent or emergency notifications concerning this request.

Considerations

For example: if the outcome of the request requires an urgent or emergency response by the requester or requesting organisation.

Advice from the requester to the receiver regarding the individual's qualification for the requested service.

Considerations

For example: meeting eligibility criteria for a specific funded service.

A recommendation from the requester to the receiver regarding the payment method for the service.

Considerations

For example: 'Private'; 'Government insurance scheme'; or 'Private insurance'.

Details about the identified individual or organisation assuming responsibility for payment of the service.

Considerations

This SLOT will only be used if a known payer has been identified. For example: an individual, such as a parent on behalf of a child; or an organisation such as a workplace, traffic accident, or government insurance scheme.

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

Purpose

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

Supporting Model(s)

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

Considerations

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

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

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

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

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

Implementation examples:

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

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.

@ 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 name of the service requested.

Considerations

Coding of the 'Service name' with an external terminology is strongly recommended, if available.

Category of service requested.

Considerations

Coding of the 'Service type' with an external terminology is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code.

Narrative description about the service requested.

Considerations

This data point should be used to describe the requested service in more detail.

The symptom, sign or diagnosis that prompts the need for the requested test.

Considerations

Coding of the 'Clinical indication' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.​

Narrative information about the individual and their situation, providing relevant background for the request.

Considerations

Also known as 'Clinical notes', although this name has intentionally been avoided to clearly differentiate from the 'Notes' attribute in many FHIR resources.

The concern or clinical question that needs to be addressed or resolved by the requested test.

Considerations

Coding of the 'Reason for request' with an external terminology is desirable, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.

Narrative description about the concern or clinical question that needs resolution.

Description of the intended outcome of the request.

Considerations

Coding of the 'Intent' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record more than one response if required.​

Additional details and instructions about how the services are to be delivered.

Considerations

Coding of the 'Order detail' with an external terminology is desirable, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required.

The urgency of the request for service.

Considerations

Specific definitions of emergency and urgent will vary between clinical contexts, clinical systems and the nature of the request itself, so have not been defined in this data group. If more precise timing is required, use the 'Service due' data element.

The timing for provision of the requested service.

Considerations

This data element enables the recording of the intended timing for the service in various formats, including precise timing details such as specific dates and times, or through textual descriptors like ‘Next available’. Additionally, the Timing data type is designed to accommodate more complex timing scenarios if needed.

Details about more complex timing than available from 'Service due' or if a sequence of events is required to carry out this request 'Activity'.

Considerations

For example: 'hourly vital signs observations for 4 hours, then 4 hourly for 20 hours' or 'every third Wednesday for 3 visits' or 'Day 14-16 of the menstrual cycle'. Use other attributes of the 'Timing data type in 'Complex timing' SLOT.

Additional detail about the service requested.

Digital document, image, video or diagram supplied as additional information to support or clarify the context of the requested service.

Description of the supplementary information.

Details about requirements that are specific to the patient that need to be considered to support their attendance or participation in the provision of the service.

Considerations

For example: requirement for language translation; transport provision; or other personal factors.

Additional narrative about the service request 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 identifier assigned by the requesting clinical system.

Details about the clinician or organisation requesting the service.

The local identifier assigned to the request by the clinician or organisation receiving the request for service.

Details about the clinician or organisation receiving the request for service.

The status of the request for service as indicated by the requester.

Considerations

Status is used to denote whether this is the initial request, or a follow-up request to change or provide supplementary information. Coding with a terminology is preferred, where possible.

Details of additional clinicians, organisations or agencies that need to be informed of the outcome of this service request.

Considerations

For example: specialists or allied health providers who need to be notified of test results or available reports.

Details about a designated contact person or organisation and their preferred method of communication for urgent or emergency notifications concerning this request.

Considerations

For example: if the outcome of the request requires an urgent or emergency response by the requester or requesting organisation.

Advice from the requester to the receiver regarding the individual's qualification for the requested service.

Considerations

For example: meeting eligibility criteria for a specific funded service.

A recommendation from the requester to the receiver regarding the payment method for the service.

Considerations

For example: 'Private'; 'Government insurance scheme'; or 'Private insurance'.

Details about the identified individual or organisation assuming responsibility for payment of the service.

Considerations

This SLOT will only be used if a known payer has been identified. For example: an individual, such as a parent on behalf of a child; or an organisation such as a workplace, traffic accident, or government insurance scheme.

Additional information required to extend the model with local content or to align with other reference models or formalisms.

Considerations

For example: local information requirements; or additional metadata to align with FHIR.