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.
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 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/.
- Custodian Organisation: Ocean Informatics
- Current Contact: Heather Leslie, Ocean Informatics
- Original Namespace: com.oceaninformatics
- Original Publisher: Ocean Informatics
- Custodian Namespace: com.oceaninformatics
- MD5-CAM-1.0.1: 2C5D4970419873CE7B9172B1FAF3499E
- Build Uid: a266d88c-c58f-4eeb-b214-964ef117f51c
- Revision: 0.0.1-alpha
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
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.
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.
Allowed values: {true}
Example: CLUSTER archetype specifying complex timing requirements.
Include:
All not explicitly excluded archetypes
Include:
openEHR-EHR-CLUSTER.multimedia.v1 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
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
Include:
openEHR-EHR-CLUSTER.organisation.v1
Tomas Alme, DIPS ASA, Norway
Vebjoern Arntzen, Oslo university hospital, Norway
Koray Atalag, University of Auckland, New Zealand
Silje Ljosland Bakke, National ICT Norway, 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
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
Lars Ivar Mehlum, Helse Bergen HF, Norway
Lars Karlsen, DIPS ASA, Norway
Heather Leslie, Ocean Informatics, Australia (openEHR Editor)
Hallvard Lærum, Oslo Universitetssykehus HF, Norway
Ian McNicoll, freshEHR Clinical Informatics, United Kingdom (openEHR Editor)
Lars Morgan Karlsen, DIPS ASA, Norway
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)