To record details about a simple health-related service or activity delivered by a clinician, organisation or agency. This includes tracking progress from planning, via scheduling and delivery to completion, as well as deviations from the intended care path such as postponement or cancellation. This is achieved by the recording of relevant data elements about specific activities, each of which are described as the 'Pathway' careflow steps in this archetype.
The scope of this archetype deliberately encompasses activities for a broad range of clinical services, to act as a non-specific archetype for all non-complex use cases. Examples include, but are not limited to:
- self-referral by a patient for a check-up visit to a dentist for preventive care
- a series of visits to a physiotherapist for management of a musculoskeletal strain; and
- a referral from a requesting healthcare provider, such as a primary care clinician, to a receiving healthcare provider, such as a specialist, for the patient to receive a specific service, advice or care.
Additional structured and detailed information about the service can be captured using purpose-specific archetypes inserted into the 'Service detail' slot, where required.
This archetype may only be used in two ways:
- as a full record of the service that was delivered; or
- as a framework to record primarily the state of the requested service, with separate OBSERVATION archetypes used to record the actual test results for the delivered service - for example OBSERVATION.hearing_screening_result.
Timings related to service management can be managed in one of two ways:
- Using the reference model - the time for performance of any pathway step will use the ACTION time attribute for each step.
- Archetyped data elements - the 'Scheduled date/time' data element is intended to record the time when the service was intended to be carried out. Note: the corresponding ACTION time attribute for the Scheduled pathway step will record the time that the clinical activity was scheduled into a system, not the intended date/time on which the activity is intended to be carried out.
In practice, some services (for example, in ambulatory care) will occur once and not be ordered in advance. The details about the service will be added against the pathway step, 'Service completed'. In some cases a recurring service will be ordered, and in this situation data against the 'Service delivered' step will be recorded on each occasion, leaving the instruction in the active state. When the last delivery of the service is recorded, the 'Service completed' action is recorded showing that this order is now in the completed state.
In other situations, such as secondary care, there may be a formal order for a service using a corresponding INSTRUCTION.request archetype. This ACTION archetype can then be used to record the workflow of when and how the order has been carried out.
Recording information using this ACTION archetype indicates that some sort of activity has actually occurred; this will usually be the service delivery itself but may be a failed attempt or another activity such as postponement of the service delivery. If there is a formal order for the service, the state of this order is represented by the Pathway step against which the data is recorded. For example, using this archetype the progressing state of a referral request may be recorded through separate entries in the EHR progress notes at each 'Pathway' step:
- record the scheduled Start date/time for the referral (Service scheduled); and
- record that the referral has been completed, potentially including information about the service delivered (Service completed).
When the activities follow the usual Planned > Scheduled > Active > Completed states, recording a 'Reason' is not usually necessary - rather, it is usually used to record the reason for deviation from the typical care pathway.
Please note that in the openEHR Reference Model there is a 'Time' attribute, which is intended to record the date and time at which each pathway step of the Action was performed. This is the attribute to use to record the start of the service (using the 'Service delivered' pathway step) or the time that the service was aborted (using the 'Service abandoned' pathway step).
Organisation: Atomica Informatics, Australia
Email: heather.leslie@atomicainformatics.com
Date originally authored: 2015-12-21
Organisation: Atomica Informatics, Australia
Email: heather.leslie@atomicainformatics.com
Date originally authored: 2015-12-21
- 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
- References: Derived from: Service, Draft archetype [Internet]. Australian Digital Health Agency (NEHTA), ADHA Clinical Knowledge Manager. Authored: 2015 Dec 21. Available at: http://dcm.nehta.org.au/ckm#showArchetype_1013.1.1395_2 (discontinued)
- Current Contact: Heather Leslie, Atomica Informatics, Australia
- Original Namespace: org.openehr
- Original Publisher: openEHR Foundation
- Custodian Namespace: org.openehr
- MD5-CAM-1.0.1: 910577A40659C9665D96E1AFAD01AD44
- Build Uid: 69057fa2-9ad3-493e-817a-218f3b8d07f3
- Revision: 1.0.3
For example: 'Sarcoma MDT meeting' or 'Physiotherapy referral'. Coding of the specific service name with a terminology is preferred, where possible.
For example: 'MDT meeting' or 'Referral'
Use to capture detailed, structured information about specified aspects of the service.
Include:
All not explicitly excluded archetypes
The planned date/time can be expressed as a date/time, interval of date/time, duration or interval of duration from the time of planning, or free or coded text. Only for use in association with the 'Service planned' pathway step.
Choice of:
Date/Time
Interval of Date/Time
Duration
Interval of Duration
Text
Only for use in association with the 'Service scheduled' pathway step.
Only for use in association with the 'Service delivered' pathway step. For example: record that this is the 3rd physiotherapy appointment in a planned sequence.
min: >=1
Include:
openEHR-EHR-CLUSTER.media_
For example: the reason for the cancellation or suspension of the service. It is not necessary to record the reason for each pathway step that is expected. Rather this data element is intended to capture the reason for any divergence from a typical service provision process, such as 'Postponed' due to 'Patient had a fever', or a scheduled provision as part of a series may be 'Cancelled' due to 'Patient changed their mind'. Note: The clinical indication for triggering the service provision process may be recorded using the INSTRUCTION.service_request archetype.
Include:
All not explicitly excluded archetypes
This is equivalent to Placer Identifier in FHIR.
Choice of:
Identifier- Text
Include:
openEHR-EHR-CLUSTER.person.v1 and specialisations or
openEHR-EHR-CLUSTER.organisation.v1 and specialisations
This is equivalent to Filler Identifier in FHIR.
Choice of:
- Identifier
- Text
Include:
openEHR-EHR-CLUSTER.person.v1 and specialisations or
openEHR-EHR-CLUSTER.organisation.v1 and specialisations
For example: local information requirements or additional metadata to align with FHIR equivalents.
Include:
All not explicitly excluded archetypes
Current state: planned
Current state: planned
Current state: planned
Current state: postponed
Current state: cancelled
Current state: scheduled
Current state: active
Current state: suspended
Current state: aborted
Current state: expired
Current state: completed
Silje Ljosland Bakke, Helse Vest IKT AS, Norway (openEHR Editor)
Maria Berggren, Region Uppsala, Sweden
SB Bhattacharyya, Bhattacharyyas Clinical Records Research & Informatics LLP, India
Hanne Marte Bårholm, Helse Vest IKT, Norway (openEHR Editor)
Gunn Elin Blakkisrud, DIPS ASA, Norway
Kåre Flø, DIPS ASA, Norway
Heather Grain, Llewelyn Grain Informatics, Australia
Mikkel Johan Gaup Grønmo, Regional forvaltning EPJ, Helse Nord, Norway (openEHR Editor)
Evelyn Hovenga, EJSH Consulting, Australia
Gunnar Jårvik, Helse Vest IKT AS, Norway
Mika Kiviaho, Tietoevry, Finland
Kanika Kuwelker, Helse Vest IKT, Norway (openEHR Editor)
Liv Laugen, Oslo University Hospital, Norway, Norway (openEHR Editor)
Heather Leslie, Atomica Informatics, Australia (openEHR Editor)
Mikael Nyström, Cambio Healthcare Systems AB, Sweden
Bjørn Næss, DIPS ASA, Norway
Marte Rime Bø, Direktoratet for e-helse, Norway
Terje Sagmyr, Helse Vest IKT, Norway (openEHR Editor)
Andre Smitt-Ingebretsen, Sørlandet sykehus HF, Norway
Norwegian Review Summary, Norwegian Public Hospitals, Norway
John Tore Valand, Helse Bergen, Norway (openEHR Editor)
Marit Alice Venheim, Helse Vest IKT, Norway (openEHR Editor)
Ina Wille, Helse-Vest RHF, Norway
- German: Eva-Maria Rieß, Natalia Strauch, Universitätsmedizin Göttingen, Medizinische Hochschule Hannover, eva-maria.riess@med.uni-goettingen.de, Strauch.Natalia@mh-hannover.de
- Norwegian Bokmål: Silje Ljosland Bakke, John Tore Valand, Terje Sagmyr, Helse Vest IKT AS, silje.ljosland.bakke@helse-vest-ikt.no, john.tore.valand@helse-vest-ikt.no, terje.sagmyr@helse-vest-ikt.no
- Portuguese (Brazil): Ana Paula Pannuti, Débora Farage, Adriana Kitajima, Fernanda Maia e Clóvis Puttini., Core Consulting, ana.andrade@coreconsulting.com.br
- Chinese (PRC): Lin Zhang, Freelancer, linforest@163.com
- Dutch: Mattijs Kuhlmann, Nedap, mattijs.kuhlmann@nedap.com