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 EREQDI

Official URL: https://aehrc.csiro.au/fhir/logical-models/ServiceRequestEREQDI				Version: 0.0.1
Draft as of 2023-09-11				Computable Name: ServiceRequestEREQDI
Keywords: erequest

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

Usage:

• This Logical Model Profile is not used by any profiles in this Implementation Guide

Formal Views of Profile Content

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

 

​Other representations of profile: CSV, Excel