ARCHETYPE Therapeutic activity (openEHR-EHR-INSTRUCTION.therapeutic_activity_order.v0)

ARCHETYPE IDopenEHR-EHR-INSTRUCTION.therapeutic_activity_order.v0
ConceptTherapeutic activity
DescriptionAn order or instruction for a health-related therapy or activity to be carried out.
UseUse to record an order or instruction for a health-related therapy or activity to be carried out. This archetype has been designed as a framework that can be used as the basis for an order for a health-related therapy or activity within the same department, organisation or agency, or self-care by the individual. For example: four hourly vital signs monitoring; bed rest; daily dressings. The default assumption for this archetype is that it is a request for a single therapeutic activity. If a series of activities are required, use the CLUSTER.service_direction or CLUSTER.therapeutic_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.
MisuseNot to be used for a medication order. Use INSTRUCTION.medication_order for this purpose.
PurposeGeneric request framework for an order for a health-related therapy or activity to be carried out.
References
Copyright© openEHR Foundation, Nasjonal IKT HF, openEHR Foundation
AuthorsAuthor name: Dr Heather Leslie
Organisation: Atomica Informatics, Australia
Email: heather.leslie@atomicainformatics.com
Date originally authored: 2020-03-26
Other Details LanguageAuthor name: Dr Heather Leslie
Organisation: Atomica Informatics, Australia
Email: heather.leslie@atomicainformatics.com
Date originally authored: 2020-03-26
Other Details (Language Independent)
  • 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: F73BABA6192202A6981F3A0E77AAEB92
  • Build Uid: 175d6541-58bb-4ea9-83cf-1bfbedd06ffd
  • Revision: 0.0.1-alpha
Keywordsrequest, order, therapy, provide, referral
Lifecyclein_development
UIDc31fafb6-eaf1-4171-8be9-0212093b127f
Language useden
Citeable Identifier1013.1.4588
Revision Number0.0.1-alpha
protocol
Requester order identifierRequester order identifier: The local identifier assigned by the requesting clinical system.
Usually equivalent to the HL7 Placer Order Identifier.
Choice of:
  •  Text
  •  Identifier
RequesterRequester: Details about the clinician or organisation requesting the therapy.
Include:
All not explicitly excluded archetypes
Receiver order identifierReceiver order identifier: The local identifier assigned to the request by the clinician or organisation receiving the request for therapy.
Usually equivalent to the HL7 Filler Order Identifier.
Choice of:
  •  Text
  •  Identifier
ReceiverReceiver: Details about the clinician or organisation receiving the request for therapy.
Include:
All not explicitly excluded archetypes
Order statusOrder status: The status of the order for the activity 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. Coding with a terminology is preferred, where possible.
Distribution listDistribution list: Details of additional clinicians, organisations or agencies who require copies of any communication.
Include:
openEHR-EHR-CLUSTER.distribution.v1
ExtensionExtension: Additional information required to extend the model with local content or to align with other reference models or formalisms.
For example: local information requirements; or additional metadata to align with FHIR.
Include:
All not explicitly excluded archetypes
activities
Current ActivityCurrent Activity: Current Activity.
Activity nameActivity name: The name of the single therapy or activity requested.
Coding of the 'Activity name' with a coding system is desirable, if available. For example: 'recommendation to rest in bed'; 'apply ice for 20 minutes every 2 hours'.
Activity typeActivity type: Category of therapy or activity ordered.
Coding of the 'Activity type' with a coding system is desirable, if available. If the 'Therapy name' was coded, it is possible for this data point to be derived from the code. For example: 'Self-care intervention'.
DescriptionDescription: Narrative description about the activity ordered.
This data point should be used to describe the named activity in more detail, including how it should be delivered, individual concerns and issues that might be encountered in carrying out the activity.
Reason for orderReason for order: A short phrase describing the reason for the order.
Coding of the 'Reason for order' 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.
Reason descriptionReason description: Narrative description about the reason for request.
Clinical indicationClinical indication: The clinical reason for the ordered therapy.
Coding of the clinical indication with a terminology is preferred, where possible. This data element allows multiple occurrences. For example: 'Sprained ankle' or 'Type 1 Diabetes mellitus'.
IntentIntent: Description of the intent for the order.
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.
UrgencyUrgency: Urgency of the order.
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 Activity 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
Activityy dueActivityy due: The date/time, or acceptable interval of date/time, for provision of the therapy.
This data element allows for recording of the timing for a single therapy, 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 therapys 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
Complex timingComplex timing: Details about a complex order requiring a sequence of timings.
Include:
openEHR-EHR-CLUSTER.service_direction.v0 and specialisations or
openEHR-EHR-CLUSTER.therapeutic_direction.v1
Activity period startActivity period start: The date/time that marks the beginning of the valid period of time for delivery of this activity.
This date/time is the equivalent to the earliest possible date for carrying out the activity. For example: sometimes a certain amount of time must pass before an activity can be carried out. For example: 'start mobilisation 2 days post surgery'.
Activity period expiryActivity period expiry: The date/time that marks the conclusion of the clinically valid period of time for carrying out this activity.
This date/time is the equivalent to the latest possible date for carrying out the activity or to the date of expiry for this order. For example: an activity may be required to be completed before another event, such as scheduled surgery.
Indefinite?Indefinite?: The valid period for this order is open ended and has no date of expiry.
Record as TRUE to record explicity that the order has no expiry date. For example: required for a lifelong activity.
Allowed values: {true}
Specific detailsSpecific details: Additional detail about the activity ordered.
Include:
All not explicitly excluded archetypes
Supporting informationSupporting information: Digital document, image, video or diagram supplied as additional information to support or inform the order.
Include:
openEHR-EHR-CLUSTER.multimedia.v1 and specialisations or
openEHR-EHR-CLUSTER.multimedia.v0 and specialisations
Supplementary informationSupplementary information: Supplementary information will be following the order.
Record as TRUE if additional information has been identified and will be forwarded when available. For example: pending test results.
Allowed values: {true}
Information descriptionInformation description: Description of the supplementary information.
Patient requirementsPatient requirements: Language, transport or other personal requirements to support the patient's attendance or participation in carrying out the activity.
Include:
All not explicitly excluded archetypes
CommentComment: Additional narrative about the activity order not captured in other fields.
Other contributorsFatima 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
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
Translators
  • Norwegian Bokmål: Silje Ljosland Bakke, Nasjonal IKT HF, Norway
  • Italian: Francesca Frexia, CRS4 - Center for advanced studies, research and development in Sardinia, Pula (Cagliari), Italy, francesca.frexia@crs4.it