| ARCHETYPE ID | openEHR-EHR-INSTRUCTION.service_request_test.v1 |
|---|---|
| Concept | Service request |
| Description | Request for a health-related service to be supplied by a healthcare provider or agency. |
| Use | 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:
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. |
| Misuse | Not to be used for requests which have a specific specialisation - for example:
|
| Purpose | Generic framework for a request for a health-related service to be supplied by a healthcare provider or agency. |
| References | Derived from: <Add reference to original resource here> 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 |
| Copyright | © openEHR Foundation, Nasjonal IKT HF, Alberta Health Services (Canada), Alberta Health Services (Canada), openEHR Foundation |
| 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) |
|
| Keywords | request, order, service, provide, referral |
| Lifecycle | published |
| UID | cc273dd0-0991-46e1-9938-64b18a292109 |
| Language used | en |
| Citeable Identifier | 1013.1.1983 |
| Revision Number | 1.0.0 |
| Archetype Concept Comment | For example equipment request. |
| activities | |
| Order Elements | Order Elements: Description of the requested service. |
| Order elements | Order elements: Additional detail about the service requested. Example: CLUSTER archetype specifying complex timing requirements. Include: All not explicitly excluded archetypes |
| Supporting Context | Supporting Context: Additional information needed for the order to be actioned or reported. |
| Supporting context | Supporting context: Expansion slot for additional information needed for the order to be actioned or reported. Include: All not explicitly excluded archetypes |
| protocol | |
| Extension | Extension: Additional information required to capture local content or to align with other reference models/formalisms. For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents. Include: All not explicitly excluded archetypes |
| Requestor Identifier | Requestor Identifier: The local ID assigned to the order by the healthcare provider or organisation requesting the service. This is also referred to as Placer Order Identifier. |
| Requestor | Requestor: Details about the healthcare provider or organisation requesting the service. Include: All not explicitly excluded archetypes |
| Receiver identifier | Receiver identifier: The ID assigned to the order by the healthcare provider or organisation receiving the request for service. This is also referred to as Filler Order Identifier. |
| Receiver | Receiver: Details about the healthcare provider or organisation receiving the request for service. Include: All not explicitly excluded archetypes |
| 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. |
| Distribution list for response | Distribution list for response: A list of person's or organisation who should receive copies of any communication. Include: openEHR-EHR-CLUSTER.distribution.v1 |
| 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 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 |
| Translators |