ARCHETYPE Service request (openEHR-EHR-INSTRUCTION.service_request.v1)

Name: Service request
License: http://creativecommons.org/licenses/by-sa/4.0/

ARCHETYPE ID	openEHR-EHR-INSTRUCTION.service_request.v1
Concept	Service request
Description	Request for a health-related service or activity to be delivered by a clinician, organisation or agency.
Use	Use to record a request for a health-related service or activity to be delivered by a clinician, organisation or agency. This generic archetype 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 archetype 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 archetype for each request. The 'Service due' data element supports common use cases for stipulating the simple timing for delivery of the request/s on a single occasion. For situations with more complicated timing requirements or a series of services, use the CLUSTER.service_direction archetype within the '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 archetype, 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 archetype nested within the 'Complex timing' SLOT to define the delivery requirements such as 'daily for 6 months'. Consider a clinician ordering an ultrasound of the left leg to exclude a deep venous thrombosis - the 'Service name' will be 'Ultrasound left lower leg'; the 'Clinical indication' may be 'swollen left ankle'; the 'Reason for request' may be 'exclude DVT'; the 'Clinical context' may be 'gradually increasing pitting oedema to mid-calf in the left leg over the past 3 days'. Consider a clinician ordering a recurring blood test, such as an INR. The complex timing for this requires the use of the CLUSTER.service_direction and associated CLUSTER.timing_nondaily archetype nested within the 'Complex timing' SLOT to clearly define the frequency and timing for each sequence in a series of tests, such as 'daily for one week, weekly for 4 weeks, monthly 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. In many situations, it will be possible to record the steps that occur as part of this request being carried out using the corresponding generic ACTION.service. However, there will be many occasions where the required ACTION archetype will be very specific for purpose, as the data requirements for recording provision of many health-related services will need quite unique data elements, recording patterns or pathway steps. For example: ACTION.screening or ACTION.health_education.
Misuse	Not to be used to record details about the activities that document how an order or request has been carried out - use an ACTION archetype for this purpose. For example ACTION.service archetype or a more purpose-specific archetype from the ACTION class for this purpose.
Purpose	A generic framework for a request for a health-related service or activity to be delivered by a clinician, organisation or agency.
References
Copyright	© openEHR Foundation, Nasjonal IKT HF
Authors	Author name: Dr Ian McNicoll Organisation: Ocean Informatics, United Kingdom Email: ian.mcnicoll@oceaninformatics.com Date originally authored: 2009-12-08
Other Details Language	Author name: Dr Ian McNicoll Organisation: Ocean Informatics, United Kingdom Email: ian.mcnicoll@oceaninformatics.com Date originally authored: 2009-12-08
Other Details (Language Independent)	Licence: This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/. Custodian Organisation: openEHR Foundation Current Contact: Heather Leslie, Atomica Informatics Original Namespace: org.openehr Original Publisher: openEHR Foundation Custodian Namespace: org.openehr MD5-CAM-1.0.1: 552568349490A2FA815607DD29B53F55 Build Uid: 424d508f-afca-44c2-97fc-b45116d9bef4 Revision: 1.1.3-alpha
Keywords	request, order, service, provide, referral
Lifecycle	in_development
UID	d7cf88fd-5324-4005-9f1b-d0f4f8e112ba
Language used	en
Citeable Identifier	1013.1.614
Revision Number	1.1.3-alpha
activities
Current Activity	Current Activity: Current Activity.
Service name	Service name: The name of the service/s requested. Coding of the 'Service name' with an external terminology is strongly recommended, if available. This data element allows multiple occurrences to enable the user to record a multiple services as part of a single request, if required.
Service type	Service type: Category of service requested. 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.
Description	Description: Narrative description about the service requested. This data point should be used to describe the named service in more detail, including how it should be delivered, patient concerns and issues that might be encountered in delivering the service.
Clinical indication	Clinical indication: The symptom, sign or diagnosis that necessitates the requested service. 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 a multiple responses, if required.
Clinical context	Clinical context: Narrative information about the individual and their situation, providing relevant context for the request.
Reason for request	Reason for request: The specific problem needing attention or the clinical question that requires investigation. 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 a multiple responses, if required.
Reason description	Reason description: Narrative description about the issue or clinical query that needs resolution.
Intent	Intent: Description of the intended outcome of the request. Coding of the 'Intent' with an external terminology is recommended, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required.
Order detail	Order detail: Additional details and instructions about how the services are to be delivered. 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.
Urgency	Urgency: Urgency of the request for service. 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 archetype. More precise timing requirements should be specified using the 'Service due' data element or the CLUSTER.service_direction archetype within the 'Complex timing' SLOT. Choice of: Coded Text at0136::Emergency [The request requires immediate attention.] at0137::Urgent [The request requires prioritised attention.] at0138::Routine [The request does not require prioritised scheduling.] Text
Service due	Service due: The date/time or description about timing for provision of the requested service/s. This data element allows for recording of the timing for the service/s, either as a date and time, an interval of date and time, or a text descriptor. In practice, clinicians will often think in terms of ordering services as relative or approximate timing, for example: 'next available', or in '3 months'. As clinical systems need more exact parameters to operate on, this '3 months' will usually be converted to an exact date 3 months from the date of recording and stored using this data element. If complex timing or sequences of timings are required, use the CLUSTER.service_direction archetype within the 'Complex timing' SLOT and this data element becomes redundant. Choice of: Date/Time Text Interval of Date/Time
Complex timing	Complex timing: Details about a complex service request requiring a sequence of timings. 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'. If complex timing or sequences of timings are required using the CLUSTER.service_direction archetype in this SLOT, the 'Service due' data element becomes redundant. Include: openEHR-EHR-CLUSTER.service_direction.v1 and specialisations or openEHR-EHR-CLUSTER.timing_daily.v1 and specialisations or openEHR-EHR-CLUSTER.timing_nondaily.v1 and specialisations
Specific details	Specific details: Additional detail about the service requested. Include: All not explicitly excluded archetypes
Supporting information	Supporting information: Digital document, image, video or diagram supplied as additional information to support or inform the request. Include: openEHR-EHR-CLUSTER.media_file.v1 and specialisations
Supplementary information	Supplementary information: Supplementary information will be following request. Record as TRUE if additional information has been identified and will be forwarded when available. For example: pending test results. Allowed values: {true}
Information description	Information description: Description of the supplementary information.
Patient requirements	Patient requirements: Language, transport or other personal requirements to support the patient's attendance or participation in provision of the service. Include: All not explicitly excluded archetypes
Comment	Comment: Additional narrative about the service request not captured in other fields.
protocol
Requester order identifier	Requester order identifier: The local identifier assigned by the requesting clinical system. Usually equivalent to the HL7 Placer Order Identifier. Choice of: Text Identifier
Requester	Requester: Details about the clinician or organisation requesting the service. Include: openEHR-EHR-CLUSTER.person.v1 and specialisations
Receiver order identifier	Receiver order identifier: The local identifier assigned to the request by the clinician or organisation receiving the request for service. Usually equivalent to the HL7 Filler Order Identifier. Choice of: Text Identifier
Receiver	Receiver: Details about the clinician or organisation receiving the request for service. Include: openEHR-EHR-CLUSTER.person.v1 and specialisations or openEHR-EHR-CLUSTER.organisation.v1 and specialisations
Request status	Request status: The status of the request for service as indicated by the requester. 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.
Distribution list	Distribution list: Details of additional clinicians, organisations or agencies who require copies of any communication. Include: openEHR-EHR-CLUSTER.organisation.v1 and specialisations or openEHR-EHR-CLUSTER.person.v1 and specialisations
Urgent contact	Urgent contact: Details about the designated contact person or organisation and preferred mode of contact for urgent or emergency notifications related to this request. For example: if the outcome of the request requires an urgent or emergency response by the requester. Include: openEHR-EHR-CLUSTER.person.v1 and specialisations or openEHR-EHR-CLUSTER.organisation.v1 and specialisations
Eligibility guidance	Eligibility guidance: Advice from the requester to the receiver about the individual's eligibility for the requested service.
Billing guidance	Billing guidance: A recommendation from the requester to the receiver about the method of payment for the service. For example: 'Private'; 'Government insurance scheme'; or 'Private insurance'.
Responsible payer	Responsible payer: Details about the individual or organisation who will assume responsibility for payment of the service. This data element 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 or government insurance scheme. Include: openEHR-EHR-CLUSTER.organisation.v1 and specialisations or openEHR-EHR-CLUSTER.person.v1 and specialisations
Extension	Extension: Additional information required to extend the model with local content or to align with other reference models or formalisms. For example: local information requirements; or additional metadata to align with FHIR. Include: All not explicitly excluded archetypes
Other contributors	Fatima Almeida, Critical SW, Portugal Tomas Alme, DIPS ASA, Norway Vebjørn Arntzen, Oslo University Hospital, Norway Koray Atalag, University of Auckland, New Zealand Silje Ljosland Bakke, Nasjonal IKT HF, Norway (openEHR Editor) Lars Bitsch-Larsen, Haukeland University hospital, Norway Anita Bjørnnes, Helse Bergen, Norway Lisbeth Dahlhaug, Helse Midt - Norge IT, Norway Einar Fosse, UNN HF, Norwegian Centre for Integrated Care and Telemedicine, Norway Hildegard Franke, freshEHR Clinical Informatics Ltd., United Kingdom Heather Grain, Llewelyn Grain Informatics, Australia Knut Harboe, Stavanger Universitetssjukehus, Norway Sam Heard, Ocean Informatics, Australia Ingrid Heitmann, Oslo universitetssykehus HF, Norway Andreas Hering, Helse Bergen HF, Haukeland universitetssjukehus, Norway Anca Heyd, DIPS ASA, Norway Hilde Hollås, DIPS AS, Norway Evelyn Hovenga, EJSH Consulting, Australia Lars Ivar Mehlum, Helse Bergen HF, Norway Lars Morgan Karlsen, DIPS ASA, Norway Shinji Kobayashi, Kyoto University, Japan Heather Leslie, Atomica Informatics, Australia (openEHR Editor) Hallvard Lærum, Direktoratet for e-helse, Norway Rose Mari Eikås, Helse Bergen, Norway Ole Martin Sand, DIPS ASA, Norway Hildegard McNicoll, freshEHR Clinical Informatics Ltd., United Kingdom Ian McNicoll, freshEHR Clinical Informatics, United Kingdom (openEHR Editor) Bjørn Næss, DIPS ASA, Norway Andrej Orel, Marand d.o.o., Slovenia Anne Pauline Anderssen, Helse Nord RHF, Norway Pablo Pazos, CaboLabs.com Health Informatics, Uruguay Rune Pedersen, Universitetssykehuset i Nord Norge, Norway Jussara Rotzsch, Hospital Alemão Oswaldo Cruz, Brazil Line Silsand, Universitetssykehuset i Nord-Norge, Norway Norwegian Review Summary, Nasjonal IKT HF, Norway Line Sæle, Nasjonal IKT HF, Norway Nyree Taylor, Ocean Informatics, Australia John Tore Valand, Haukeland Universitetssjukehus, Norway (Nasjonal IKT redaktør) Richard Townley-O'Neill, Australian Digital Health Agency, Australia Gro-Hilde Ulriksen, Norwegian center for ehealthresearch, Norway
Translators	German: Alina Rehberg, Natalia Strauch, Darin Leonhardt, Medizinische Hochschule Hannover, PLRI für medizinische Informatik/ Medizinische Hochschule, rehberg.alina@mh-hannover.de, Strauch.Natalia@mh-hannover.de, leonhardt.darin@mh-hannover.de Swedish: Sofia Janstad, SLL, sofia.lang-janstad@sll.se Norwegian Bokmål: Silje Ljosland Bakke, Marit Alice Venheim, Nasjonal IKT HF, Norway, Helse Vest IKT, marit.alice.venheim@helse-vest-ikt.no Portuguese (Brazil): Vladimir Pizzo, Clínica Parente Pizzo, vrppizzo@gmail.com Italian: Francesca Frexia, CRS4 - Center for advanced studies, research and development in Sardinia, Pula (Cagliari), Italy, francesca.frexia@crs4.it Dutch: Mattijs Kuhlmann, Joost Holslag, Nedap, mattijs.kuhlmann@nedap.com, joost.holslag@nedap.com