Use to record a request for a health-related service or activity to be delivered by a clinician, organisation or agency.
This archetype has been designed as a framework that can be used as the basis for:
- 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; 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: a review appointment in outpatients in 6 weeks.
Clinical use cases:
- 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 Diabetes Education as the 'Service name'. The values for 'Reason for request' may be 'New diagnosis' and 'Prevention of ketoacidosis'. The 'Clinical indication' will be 'Diabetes Type 1', which may be linked to the Problem Diagnosis and/or Laboratory test results. If a 4 week course is required, with sessions organised at weekly intervals on 4 separate occasions, then the complex timing requires use of the CLUSTER.service_direction and associated CLUSTER.timing_nondaily archetype.
- consider a clinician ordering a recurring blood test, such as an INR. The complex timing for this requires use of the CLUSTER.service_direction and associated CLUSTER.timing_nondaily archetype to define each timing in a sequence of tests, such as 'daily for one week, weekly for 4 weeks, monthly for 6 months'.
The default assumption for this archetype is that it's a request for a single service. If a series of services are required, use the CLUSTER.service_direction archetype within the 'Complex timing' SLOT.
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.
Organisation: Ocean Informatics, United Kingdom
Email: ian.mcnicoll@oceaninformatics.com
Date originally authored: 2009-12-08
Organisation: Ocean Informatics, United Kingdom
Email: ian.mcnicoll@oceaninformatics.com
Date originally authored: 2009-12-08
- 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: 6175B5DE04E6302E3DEB0C8EB876BE34
- Build Uid: f677a213-73df-4275-92b5-a583d17ceee7
- Revision: 1.1.2
Coding of the 'Service name' with a coding system is desirable, if available. For example: 'referral' to an endocrinologist for diabetes management.
Coding of the 'Service type' with a coding system is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code. For example: biochemistry or microbiology laboratory, ultrasound or CT imaging.
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.
Coding of the order detail with a terminology is preferred, where possible. This data element allows multiple occurrences.
Coding of the 'Reason for request' with a coding system is desirable, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required. For example: 'manage diabetes complications'.
For example: 'The patient's diabetes has recently become more difficult to stabilise and renal function is deteriorating'.
Coding of the clinical indication with a terminology is preferred, where possible. This data element allows multiple occurrences. For example: 'Angina' or 'Type 1 Diabetes mellitus'.
For example: a referral to a specialist may have the intent of the specialist taking over responsibility for care of the patient, or it may be to provide a second opinion on treatment options. Coding of the 'Intent' with a coding system 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 archetype. If explicit timing is required then the Service period should be clearly stated.
Choice of:
Coded Text- Emergency [The request requires immediate attention.]
- Urgent [The request requires prioritised attention.]
- Routine [The request does not require prioritised scheduling.]
Text
This data element allows for recording of the timing for a single service, either as a date and time, a date ranges or a text descriptor which can allow for 'next available. In practice, clinicians will often think in terms of ordering services as approximate timing, for example: review in 3 months, 6 months or 12 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
Interval of Date/Time
- Text
For example: 'hourly vital signs observations for 4 hours, then 4 hourly for 20 hours' or 'every third Wednesday for 3 visits'.
Include:
openEHR-EHR-CLUSTER.service_
This date/time is the equivalent to the earliest possible date for service delivery. For example: sometimes a certain amount of time must pass before a service can be performed, for example some procedures can only be performed once the patient has stopped taking medications for a specific amount of time.
This date/time is the equivalent to the latest possible date for service delivery or to the date of expiry for this request. For example: a service may be required to be completed before another event, such as scheduled surgery.
Record as TRUE to record explicity that the request has no expiry date. For example: commonly required for a referral to a specialist for long-term or lifelong care.
Allowed values: {true}
For example: Specimen details for a laboratory test request, or anatomical location for a procedure request.
Include:
All not explicitly excluded archetypes
Include:
openEHR-EHR-CLUSTER.multimedia.v1 and specialisations or
openEHR-EHR-CLUSTER.multimedia.v0 and specialisations
Record as TRUE if additional information has been identified and will be forwarded when available. For example: pending test results.
Allowed values: {true}
Include:
All not explicitly excluded archetypes
Usually equivalent to the HL7 Placer Order Identifier.
Choice of:
- Text
Identifier
Include:
All not explicitly excluded archetypes
Usually equivalent to the HL7 Filler Order Identifier.
Choice of:
- Text
- Identifier
Include:
All not explicitly excluded archetypes
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.
Include:
openEHR-EHR-CLUSTER.distribution.v1
For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.
Include:
All not explicitly excluded archetypes
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
- German: Alina Rehberg, Natalia Strauch, Medizinische Hochschule Hannover, rehberg.alina@mh-hannover.de, Strauch.Natalia@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