Generated Narrative: StructureDefinition ServiceRequestEREQDI Name Flags Card. Type Description & Constraints ServiceRequest S 0..* ServiceRequest Service Request EREQDI Elements defined in Ancestors:Activities, Protocol #xD; Activities 0..1 BackboneElement Activities #xD; CurrentActivity 0..1 BackboneElement Activity #xD; Servicename S 1..1 CodeableConcept Service name #xD; Servicetype 0..1 CodeableConcept Service type #xD; Description 0..1 string Description #xD; Clinicalindication S 0..* CodeableConcept Clinical indication #xD; Clinicalcontext S 0..1 string Clinical context #xD; Reasonforrequest 0..* CodeableConcept Reason for request #xD; Reasondescription 0..1 string Reason description #xD; Intent 0..* string Intent #xD; Orderdetail 0..* string Order detail #xD; Urgency S 0..1 Coding Urgency #xD; Servicedue S 0..1 Service due #xD; Servicedue string #xD; <span title="Base StructureDefinition for Timing Type: Specifies an event that may occur multiple times. Timing schedules are used to record when things are planned, expected or requested to occur. The most common usage is in dosage instructions for medications. They are also used when planning care of various kinds, and may be used for reporting the schedule to which past regular activities were carried out.">Servicedue Timing #xD; Complextiming 0..1 Reference() Complex timing #xD; Specificdetails 0..1 Reference() Specific details #xD; Supportinginformation 0..1 Reference() Supporting information #xD; Informationdescription 0..1 string Information description #xD; Patientrequirements 0..1 Reference() Patient requirements #xD; Comment S 0..1 string Comment #xD; Protocol 0..1 BackboneElement Protocol #xD; Requesterorderidentifier 0..1 string Requester order identifier #xD; Requester 0..1 Reference() Requester #xD; Receiverorderidentifier 0..1 string Receiver order identifier #xD; Receiver 0..1 Reference() Receiver #xD; Requeststatus 0..1 string Request status #xD; Distributionlist S 0..1 Reference() Distribution list #xD; Urgentcontact S 0..1 Reference() Urgent contact #xD; Eligibilityguidance 0..1 string Eligibility guidance #xD; Billingguidance S 0..1 string Billing guidance #xD; Responsiblepayer 0..1 Reference() Responsible payer #xD; Documentation for this format
The Service Request EREQDI Logical Model Mindmap is shown below. Request for a health-related service or activity to be delivered by a clinician, organisation or agency. **Context** The 'Service request' data group is a generic framework intended for any service request or referral a health-related service or activity which will be fulfilled by a clinician, organisation or agency. It comprises the common data elements that form the basis of most of the common types of requests used in healthcare. As a result it has a broad range of use, for both clinical and social care purposes. In the context of eRequesting, this generic data group has been specialised for two very specific purposes - to request a Pathology test and a Medical imaging test. The underlying data elements for all three data groups, Service request and the two specialisations is in common. It is anticipated that additional specializations may be added to AUCDI in the same way as part of future releases. **Purpose** A generic framework for a request for a health-related service or activity to be delivered by a clinician, organisation or agency. **Supported Models** - 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. **Roadmap**
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. The 'Service due' data element supports common use cases for stipulating the simple timing for delivery of the request on a single occasion. For situations with more complicated timing requirements or a series of services, use other attributes of the 'Timing data type in 'Complex timing' SLOT. 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.
A generic framework for a request for a health-related service or activity to be delivered by a clinician, organisation or agency.
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.
The 'Service request' data group is a generic framework intended for any service request or referral a health-related service or activity which will be fulfilled by a clinician, organisation or agency. It comprises the common data elements that form the basis of most of the common types of requests used in healthcare. As a result it has a broad range of use, for both clinical and social care purposes. In the context of eRequesting, this generic data group has been specialised for two very specific purposes - to request a Pathology test and a Medical imaging test. The underlying data elements for all three data groups, Service request and the two specialisations is in common. It is anticipated that additional specializations may be added to AUCDI in the same way as part of future releases.
- 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.
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.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
Extensions that cannot be ignored even if unrecognized
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R4/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Coding of the 'Service name' with an external terminology is strongly recommended, if available.
**Considerations** Coding of the 'Service name' with an external terminology is strongly recommended, if available.
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.
**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.
This data point should be used to describe the requested service in more detail.
Narrative description about the service requested.
**Considerations** This data point should be used to describe the requested service in more detail.
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.​
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.​
Also known as 'Clinical notes', although this name has intentionally been avoided to clearly differentiate from the 'Notes' attribute in many FHIR resources.
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.
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.
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.
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.​
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.​
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.
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.
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 or other attributes of the 'Timing data type in 'Complex timing' SLOT. If more complex timing or a sequence of event is required to carry out the requested service, use other attributes of the 'Timing data type in 'Complex timing' SLOT.
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.
Proposed value set: - Emergency [The request requires immediate attention.] - Urgent [The request requires prioritised attention.] - Routine [The request does not require prioritised scheduling.]
**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.
This data element allows for simple recording of the timing for the service in one of three ways - either as a date and/or time, an interval of date and/or time, or as a text descriptor. For example:​ 'April 23, 2024​'; 'April 23, 2024 – April 30, 2024​'; or 'Next available'​. If more complex timing or a sequence of events is required to carry out this request 'Activity', use other attributes of the 'Timing data type in 'Complex timing' SLOT.
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.
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.
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.
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.
For example: requirement for language translation; transport provision; or other personal factors.
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.
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.
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.
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.
For example: specialists or allied health providers who need to be notified of test results or available reports.
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.
For example: if the outcome of the request requires an urgent or emergency response by the requester or requesting organisation.
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.
For example: meeting eligibility criteria for a specific funded service.
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.
For example: 'Private'; 'Government insurance scheme'; or 'Private insurance'.
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'.
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.
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.
For example: local information requirements; or additional metadata to align with FHIR.
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.