Use to record a request for a health-related service. This archetype has been designed as a framework that can be used as the basis for:
- a request from one healthcare provider or agency to another healthcare provider or agency for a health-related service - for example, a request for transfer of care to an emergency department, a referral for a second clinical opinion, or provision of home services from a municipal council; or
- a follow up service to be scheduled for the same healthcare provider or agency - for example, a review appointment in outpatients in 6 weeks.
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.request. 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.
Not to be used for requests which have a specific specialisation - for example:
- Laboratory test request - use the INSTRUCTION.request-laboratory_test archetype;
- Imaging examination request - use the INSTRUCTION.request-imaging_exam archetype; and
- Procedure request - use the INSTRUCTION.request-procedure archetype.
Derived from: Service request, Draft archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2017-06-14]. Available from: http://openehr.org/ckm/#showArchetype_1013.1.614
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 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.
- Custodian Organisation: Ocean Informatics
- References: Derived from:
Derived from: Service request, Draft archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2017-06-14]. Available from: http://openehr.org/ckm/#showArchetype_1013.1.614 - Current Contact: Heather Leslie, Ocean Informatics
- Original Namespace: com.oceaninformatics
- Original Publisher: Ocean Informatics
- Custodian Namespace: com.oceaninformatics
- MD5-CAM-1.0.1: B413B1530ADDA25274FC926DB3B3DAE6
- Build Uid: ef07f03c-bcf9-46a6-9e2f-bbf952b81d3d
- Revision: 2.0.2
Coding of the 'Service name' with a coding system is desirable, if available.
For example: hospital vs home care delivery.
Coding of the 'Reason for request' with a coding system is desirable, if available.
For example a referral with the intent of having specialist care take over the care of the patient, or advice on how to proceed with an investigation or treatment. This data element allows multiple occurrences to enable multiple choice selection in user interface.
Specific definitions of emergency and urgent will vary between clinical contexts, clinical systems and the nature of the request itself, so have not be 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
Include:
openEHR-EHR-CLUSTER.service_
Record as TRUE to record explicity that the request has no expiry date.
Allowed values: {true}
Example: CLUSTER archetype specifying complex timing requirements.
Include:
All not explicitly excluded archetypes
Include:
openEHR-EHR-CLUSTER.multimedia.v1 and specialisations
Include:
All not explicitly excluded archetypes
For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.
Include:
All not explicitly excluded archetypes
Include:
All not explicitly excluded archetypes
Include:
All not explicitly excluded archetypes
Include:
openEHR-EHR-CLUSTER.distribution.v1
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
Ingrid Heitmann, Oslo universitetssykehus HF, Norway
Andreas Hering, Helse Bergen HF, Haukeland universitetssjukehus, Norway
Anca Heyd, DIPS ASA, Norway
Hilde Hollås, Norway
Evelyn Hovenga, EJSH Consulting, Australia
Lars Ivar Mehlum, Helse Bergen HF, Norway
Lars Karlsen, DIPS ASA, Norway
Lars Morgan Karlsen, DIPS ASA, Norway
Shinji Kobayashi, Kyoto University, Japan
Heather Leslie, Ocean Health Systems, Australia (openEHR Editor)
Hallvard Lærum, Oslo Universitetssykehus HF, Norway
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
Rune Pedersen, Universitetssykehuset i Nord Norge, Norway
Jussara Rotzsch, UNB, Brazil
Line Sæle, Nasjonal IKT HF, Norway
John Tore Valand, Haukeland Universitetssjukehus, Norway (Editor)
Richard Townley-O'Neill, Australian Digital Health Agency, Australia
- Norwegian Bokmal: Lars Bitsch-Larsen, Haukeland University Hospital of Bergen, Norway, MD, DEAA, MBA, spec in anesthesia, spec in tropical medicine.
- Maltese: cka cka, Test Organisation, cka@test-oceaninformatics.com