Sparked Logical Models, published by CSIRO. This guide is not an authorized publication; it is the continuous build for version 0.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/aehrc/logical-model-web/ and changes regularly. See the Directory of published versions

• Content
• Detailed Descriptions
• Mappings
• XML
• JSON
• TTL

Logical Model: Service Request

Official URL: https://aehrc.csiro.au/fhir/logical-models/ServiceRequest				Version: 0.0.1
Draft as of 2023-09-11				Computable Name: ServiceRequest
Other Identifiers: https://aehrc.csiro.au/id/archetype_id#openEHR-EHR-INSTRUCTION.service_request_hl.v0
Keywords: openehr

The Service Request Logical Model Mindmap is shown below.

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.

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.

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.

Usage:

• Derived from this Logical Model Profile: Service Request EREQDI

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

 

​Other representations of profile: CSV, Excel