Orders Model & Terminology
1.Introduction
This document will describe the design of the Clinical Models and Terminology content for Orders. The Ordermodels[1] are used to store data capturedas Clinician Orders by the Physician Order Entry Application.
1.1Purpose
This document describes the design, creationand meaning of the Ordermodels and Terminology content for supporting the models.
1.2Scope
This document describes in detail the Order models and also the specific components for the Order models. It does not cover the generic components such asObserved, Verified, etc. These should be covered in separate documentation and while central to CDL, they are not central to the meaning of the Order models. Some of the terminology is dependent on the structure and content of externally imported pharmacy data (such as FDB). This being the case the final structure and content of terminology domains (value sets) is yet to be determined.
2.References
The following table lists other documents associated with the Ordersmodels and Terminology.
Document / LinkOrderTypeBreakdown.xlsx /
OrderModelDiagrams.vsd /
Orders Model.pptx /
3.Definitions, Acronyms and Abbreviations
Term / Definition4.Design Convention
The clinical model and Terminology content documentation is intended to capture the knowledge of the design and the creation of the Ordersmodels and Terminology content. The design of the models is represented with the outline of the modeland explained with design decisions and considerations.
5.Design Overview
5.1OrdersModels
The main requirements on the design of the current Orders models are from the Intermountain Physician Order Entry Application. The goal is to support both the data storage and retrieval for the new Order Application into the Qualibria CDR. The primary sources for information to construct this model are from Keith Larsen and Joey Coyle. Keith has made detailed study of existing orders structures and is the primary designer of the new orders system.
5.2Orders Terminology
In addition to the Terminology which enables the Ordersmodels, such as the Terminology for the CE types, the keys, the domain constraints and etc., external source for medications order will be utilized. The current plan is to use First Data Bank (FDB ) as a primary source for medication order terminology, although the details about such utilization have not yet materialized.
5.3Orders Model Structural Overview
Figure 1 Order Model General Structure
5.3.1Order Container:
This topmost node refers to the order in its entirety. An order is characterized by a single defined action, intervention, or diagnostic, in a single domain, that the clinician desires for the patient. This single desired action can have multiple sub-parts, but is not scoped to include multiple orders in a protocol or order set. The qualifiers at this level are qualifiers to all the Order segments within the Order Container.
The Order Container node serves as a container for multiple Orders in the traditional sense. In the vast majority of orders, such a container would be unnecessary as most orders are not complex. Most order systems fail, however, by their inability to express complex orders.
5.3.2Order:
The Order segments (there can be more than one) represent orders within the Order Container and are linked to the Order Container by a relationship between them. An example is an alternating infusion order where the alternating infusion bottles are each defined in separate Order segments and the relationship between the infusion bottle Order segment is defined in the Order Relationship qualifier of the Order Container structure.
In the vast majority of orders, there will only be one Order segment.
5.3.3Order Item:
Each Order segment can have one or more Order Item segments. Using the previous example of medication infusions, each infusion bottle can contain multiple medications.
In the vast majority of orders, there will be only one Order Item segment within an Order segment.
5.4General Model Usage
The general orders model is abstract, i.e., it cannot be instantiated itself. Its purpose is to create a parent structure for all orders. Children, or subtypes, of the order structure will be created from the Order Container structure through a pseudo-restriction process. That is, the Order Container structure defined herein is a superset of all qualifiers. In CDL, qualifiers are restricted by changing the allowed value of the cardinality attribute of an item within the allow range of cardinality defined in the general orders model. The qualifiers are not actually removed with this technique; they are ignored or not ignored, based on the value of the cardinality of the item.
Figure 2 : The instantiable children, or subtypes, of the general orders model.
5.4.1Qualifiers per subtype
5.4.1.1See Orders Type Breakdown reference spreadsheet for better detail.
Figure 3: Qualifiers that have been “restricted” out for each child or order subtype
6.Order Container glossary of objects.
6.1OrderName: Name of the Order Container. This was added so that the entire container could have a usable name for retrieval.
6.2RelatedOrder (Removed): Contains references to related orders. These related orders can be of the following types: ParentOrder, ChildOrder, SubsequentOrder or PreviousOrder. These orders are generated at order creation time. They are not created after or independently.See Semantic Links Section.
6.3OrderRelationship: This field is not related to the RelatedOrder field above. This field defines whether the order as a whole is: “Simple”, “Or”, “Alternating”, “Then”, or “Complex”. The default is “Simple”. The purpose of this model is to simplify implementation, instead of dealing with the complexity of implementing a string expression. For example, if the order model is “Or”, then the relationship among all the orders in this order container is OR.
If the clinician wants to get more complex, then the string choice is used for storage of the relationship string created by the clinician (e.g. "(A and B) or C"). For this reason the string alternate choice has been explicitly exposed in the model.
6.4OrderNumber (Removed): This is the order number generated by the Orders Service (the orders application). It is unique across all patient encounters, patients, and facilities within the enterprise. This was removed because the system is handling this id number automatically. If an ID is necessary then use ExternalOrderNumber.
6.5ExternalOrderNumber: This is the order number or numbers generated by a non-ECIS system. The purpose is to have a cross map between the OrderNumber and any number of ExternalOrderNumbers in associated contexts. One order may have multiple order numbers. "Context" refers to the particular system that generated the order number. Since the datatype is II, it is presumed at this point that the “root” of II is sufficient to contain the system information of the external order number.
This field goes beyond the HL7 specification for “sender” and “receiver” systems; any number of systems can be applied and directionality is not required.
The existence of this field should not create the assumption that this orders model is “interface ready.” The current purpose of this orders model is to provide a structure for a provider order entry application.
6.6OriginationMode: The mode the order was received (telephone, electronic, verbal, or written).
6.7OrderStatus: The purpose of this qualifier is to support workflow. The terminology domain for this qualifier is the same across all orders, but may be a constrained domain in each subtype (e.g., the workflow on a lab order may be different from the workflow for medication orders. Need to get HL7's State Diagrams for orders to inform values for this domain. (Version 3) Order being a kind of act therefore the values are: new, active, completed, held, cancelled, aborted, suspended, nullified or obsolete. In addition, a "normal" state is defined in HL7 to encompass all states of an act, but excludes "nullified" and "obsolete" which represent unusual terminal states for the life-cycle.
6.8EditFormId: Used to link back an order instance with the form to collect/edit the information.
6.9ProcessType: This links the order to a specific order fulfillment process. For example, the ProcessType of “Chemotherapy” would have a specific order fulfillment process including work lists, notification routings, etc. The ProcessType domain will be set up by each customer site as well as the mappings between specific orders and the ProcessTypes.
6.10ReadingRequest: For imaging if we want another group to read the exam. The purpose of the field is to route the order for documentation. The choices for this field are governed by contract.
6.11StartCondition: The expression of the start condition of the order. The conditions (coded, string or date/time) governing the starting of the parent order container. (See section: How conditions work)
6.12HoldCondition: The expression of the hold condition of this order. The conditions, if met, that will place the order on hold. The vast majority of order will not use this item. (See section: How conditions work)
6.13StopCondition: The conditions (coded, string or date/time) governing the stopping of the parent order container. This condition is optional; e.g., the future discontinuation of the order is not known at order time - the order will be discontinued manually by the clinician when they determine that the order is no longer needed. (See section: How conditions work)
6.14CollectionPriority: This is fulfillment priority used primarily by lab. It is the urgency for which an order must be fulfilled. Order Priority was move to the Order level from the order container level, recognizing that each segment of an order may have its own priority. For a lab draw, however, we can predict that a single collection will occur for each item in the lab order and so the collection is governed by the item with the highest priority.
6.15OrderJustification: Order Justification lists any required items to explain the "why's" of the order. This is not a semantic link because the justification is made at the time of the order by the practitioner and alterable only by the practitioner. Billing may use this justification, but billing cannot create this justification. Any justification created in the billing use cases will need to be of a different structure. Current values for the key domain are: Diagnosis, Signs and Symptoms, and Health Issue. The action in the application will occur something like this: A practitioner may choose justification from a list or from the problem list of the patient. If the practitioner chooses a problem from a list then the application will ask: do you want to add this to the patient's problem list? If yes then the problem will be create in a model structure, if no then the Ecid for the Health Issue will be stored. Because the Health Issue domain is not sub categorized we perform the categorization of the health issue via the key domain chosen. The "otherwise error" line exists because this model is meant for application use and should have an expectation of what is allowed. See Semantic Links Section.
6.16OrderedForProtocol: The protocol used to generate the order. For example, if a pneumonia protocol says to do a CBC at a given condition, then the value for this field would be “pneumonia protocol”.
6.17ReportResultsTo: This model captures the target person/organization which will receive the report on the orders outcome.
6.18RequestedFindings: This is used in radiology or lab (micro) to ask for a specific thing within the order to make note of or determine. For example, an x-ray with a note to the radiologist specifically requesting he determine the current size of a lesion.
6.19OrderSetId: If the order was placed through use of an order set, this is the identifier of the order set.
6.20LabelInstruction: Patient instructions that will appear on the label of an ambulatory medication. These are usually provided as part of a medication database. Example, "Give with food".
6.21ProviderInstruction: This field contains the ordering provider's instructions to the patient or the provider administering the drug or treatment. This is called "Directions" in Centricity Pharmacy which creates an English translation of the dose and frequency which then can be added to or changed by the pharmacist. (HL7 definition, RXE-7)
6.22SpecialHandling: Built to accommodate special conditions in execution of the order. Particularly in radiology type orders or other type of orders where transportation of the patient is necessary. Some examples of values could be: diabetes, fractures(s), fragile skin, isolation, no special handling, nurse to assist, etc...
6.23AdministrationInstruction: This field contains the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing or administering the order. This is called "MARnotes" in Centricity Pharmacy and is displayed on the MAR, not to the patient. This should be visible to all clinicians, but not to the patient. (RXE-21 definition
6.24OrderComment: A comment or a list of comments for this whole order.
6.25SessionID: Numeric identifier identifying the order session. This is used while the provider is making the order. It allows the provider to leave an ordering session either intentionally or through time out and then return to the session later to complete the ordering process. This number has no use after the ordering process is completed and, therefore, can be deleted at that point.
6.26OrderCalculationData: This model is used to store the data used to calculate the order. This is done to meet the legal requirement to retrace the thought process of the order. Values for the domain will be Weight, Height, Body Surface Area or Serum Creatinine. Some clarification needs to be drawn as to why this item should not be a reference to stored data:
6.26.1This should not affect data mining efforts because it is not technically a true patient value. We are not capturing "patient weight" - we are capturing "the weight used to calculate the order."
6.26.2This weight may or may not truly reflect the patient's own weight, but be a reasoned amount necessary to create the proper dose. And so to create a store "weight" instance based on data used here could actually corrupt the true meaning of "weight", by throwing in a new nuance of weight "weight estimated for purposed of medication or order.
6.27PerformingLocation: The location where an order is to be performed. This is not to record where a procedure actually occurred.
6.28PerformingDateTime: The date and time of appointment information after a procedure has been scheduled. This may be completed by the ordering provider, if known; otherwise the scheduling note may be used.
6.29SchedulingNote: Contains a note from the office to a scheduler outlining the patient's preference for the appointment.
6.30Discontinued (attribution): This holds the Who/When/Why/Where information about when/if the order was discontinued.
6.31CounterSigned (attribution): This holds the Who/When/Why/Where information about when/if the order was counter signed.
6.32Ordered (attribution): This holds the Who/When/Why/Where information about when/if the order was ordered.
6.33PutOnHold (attribution): This holds the Who/When/Why/Where information about when/if the order was put on hold.
6.34TakeOffHold (attribution): This holds the Who/When/Why/Where information about when/if the order was taken off hold.
7.Order segment Glossary of qualifiers
For data types and structures not specifically referenced, see the actual models and CDL reference guide:
7.1ActionVerb: For ambulatory med orders ("Take", "Apply", etc.). The primary action of administration directed at the patient.
7.2OrderSpecialRequirement: Order Special Requirements is to record any special procedures or requirements for the order, i.e., sedation for radiology orders, CVM Neg for blood products, etc.
7.3OrderPriority: This is the priority of the overall order; e.g., "STAT".
7.4RouteMethodDevice: Route or method of this order, e.g. IV, oral, chew, etc.
7.5SIG Text: Signature Text. This is for ambulatory meds to ensure the signature goes all the way into the receiving system.
7.6TotalVolume: This is the total volume of the order segment; i.e., it is the sum of all the contributing volumes of the Order Item segments. This applies to continuous infusions and intermittent infusions.
7.7Frequency: This container can hold multiple frequency definitions for the Order. The implied relationship between these is "AND". Frequency can be absent if the PRNInd is set, otherwise, there must be at least one frequency.
7.7.1Frequency Glossary of items
7.7.2Expression: Used in this case to connect two expression term ids together. In this case it will connect two or more frequency items together. “A and B or C”, etc.
7.7.3FrequencyItem: A container to hold the detail of each frequency used in the order.
7.7.3.1DailyDoseCount: Data type integer. For example, if TID is the CodedFrequency, then the daily dose count is 3. This is set by the CEM Orders Service from data stored with the CodedFrequency definitions. The purpose is to support decision support activities. If this is based on a variable frequency, it is the maximum expected doses in a 24-hour period.
7.7.3.2Expression Term ID: An id assigned by the application to identify a particular sub structure. This is used to identify a specific FrequencyItem if there are more than 1 FrequencyItems. This is used in the Expression.
7.7.3.3CodedFrequency: Specific named Frequency; e.g., BID, TID, etc. If PeriodicFrequency… is instantiated, the value of this field will be "every" or "q=". In that case, it is not clear whether choosing "every" as the frequency causes the collection of PeriodicFrequency.. or if collection of PeriodicFrequencyLowerLimit causes an automatic set of this field to "every".
7.7.3.4PeriodicFrequencyLowerLimit: E.g. q4h, q6h. If q4h, then put "q" for the CodedFrequency and "4h" in PeriodicFrequencyLowerLimit. For ranges (e.g., "q 4 to 6 hours"), use both the LowerLimit and the UpperLimit. For a single value (e.g., "q 4 hours"), put into the LowerLimit.
7.7.3.5PeriodicFrequencyUpperLimit:
7.7.3.6AdministrationTime: Actual administration times during a single day for which the order is desired to be executed.
7.7.3.7AdministrationDays: This container holds the modifiers to the daily schedule defined in fields above. If this is used, one and only one of the five sub-fields below is filled (i.e., "choice of" set).
7.7.3.7.1DaysOfWeek: Coded days of the week; e.g., "Monday", "Tuesday", etc.
7.7.3.7.2DaysOfMonth: Specific and repeating day of the month; e.g., if it is desired to give the dose the second day of each or specified month, then the value would be "2".
7.7.3.7.3Date:
7.7.3.7.4DaysOnOff: Number of days on and then days off
7.7.3.7.5DayToEvent: The number of days related to an event as the frequency of administration.
7.8PRNInd: This can be used as a modifier of the Frequency content or instead of the Frequency content. It states that the order is on an "as needed" basis. The give condition was separated out of this structure because it was recognized that something can be PRN with or without conditions and that an order may have “give” conditions without being PRN.