Orders and Requests Pattern

Back to Orders & Observations TC main page

Orders and Requests Pattern DMIM Walkthrough Author: Patrick E. Loyd (O&O Modeling, Publishing Facilitator) Last Revised: January 4, 2006

Orders and Requests Pattern DMIM (POOO_DM100000)

Model Overview The Orders and Requests Pattern Domain Messaging Information Model (DMIM) captures the information needed to support messaging related to all orders. Specifically, it includes those objects that should be present in all orders.

Focal Classes Exposed

The model is focused on the generic Act. This is not meant to represent that classCode=”ACT” but instead to allow for any value from the classCode value set.

Moods

The model currently represents only transactions related to orders (mood = RQO). However, future ballot materials will also support transactions related to (a) promises (mood = PRMS), and (b) events (mood = EVN). That is to say, future models will show an Act in several moods. These moods distinguish the different aspects of the lifecycle of an observation. These moods, which are central concepts for the D-MIM, are defined as followed.

RQO (Request): An order is a request for the performance of a healthcare service. Many times, the request is made by a clinician and recorded within one computer system, and then transmitted to a second system for performance.

PRMS (Promise): A promise is the statement of commitment to perform a healthcare service as specified in the promise. A promise could be triggered by the receipt of an order message across a messaging interface, or it could be triggered by a phone call or verbal request from the ordering clinician, or could be triggered spontaneously based on certain business rules or other decisions made by a performer of another act.

EVN (Event): An event records the performance of a healthcare service including any obtained results.

Components

It is important to note that an act is not always an atomic thing. An act can be composed of components. This is a general principle, which allows composite acts to be constructed with any desired and appropriate sub-component structure. This structure accommodates a number of functionally relevant situations. For example, a hospital may define a test, such as VS (Vital Signs), that is a combination of several individual tests. This allows several related tests to be initiated with a single order or intent. Composite tests, or batteries are created to support several different functional situations. It is also possible to create tests that require a series of acts extending over a period of time for their completion, and for the creation of a meaningful result, for example a glucose tolerance test. In this case, an individual test is ordered, and broken down into components each of which is performed at a particular time, by particular participants.

An act can be composed of multiple steps. Each step is treated as an order, promise or event in its own right. For example, when an order is defined for communication to another system, that order could be composed of several steps and the sending system might want to communicate this structure to the receiving system. That is done by associating each component with its composite via the ActRelationship of type component. A promise might be broken into components in response to a simple order to reflect the need to schedule the different steps with separate resources. Events are split into components to report individual results.

Replacements

The Act, whether ordered, promised or performed, can be the replacement for another Act that was originally ordered, promised or performed. For example, a clinician might order one test, but a supervising clinician could replace that order with a more appropriate test.

Trigger Events and Control Acts

It is important to realize that messaging related to observations draws on common control structures particularly the ControlAct. For a discussion of these structures, please refer to discussion of the trigger event control act in the Message Control Act Infrastructure Domain within Infrastructure Management. When an Observation-Act (event, order, or promise, and any Act in general) is created, it will include information such as who is responsible for creating the Act, who is responsible for entering Act related information, etc, which is captured as Participations of the Observation-Act (Participations are discussed below.) However, subsequent transactions on that same Act, such as cancellations, holds, suspensions, etc., will show the responsibilities for those transactions as participations in the ControlAct which represents the transaction (e.g., the cancellation.) At the same time, the responsibilities associated with the original Observation-Act will continue to be maintained as participations of that Observation-Act.

Core Orders Domain Information Model Classes

Entry into the DMIM is through the RequestChoice choice box. There are two classes within the choice box, Observation and Entry. The Entry class is present to support order sets such as clusters and batteries. The need for the Observation class is obvious, general orders and results are observations.

The RequestChoice has the following Acts: Entry The entry class captures information pertinent to a Battery or Cluster Act (order set). An act of Entry classCode will normally have one or more component act relationships to one or more child acts.

Attributes in the Entry Act classCode: A code specifying the major type of Act that this Act-instance represents. moodCode: A code distinguishing whether an Act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc. In general the orders and observations domain deals with request (RQO), promise (PRMS) and event (EVN) moods. For this ballot, moodCode is constrained to RQO. id: A unique identifier for the Act. code: A code specifying the particular kind of Act that the Act-instance represents within its class. text: A textual or multimedia description (or reference to a description) of the Act. statusCode: A code specifying the state of the Act. effectiveTime: A time expression specifying the focal or operative time of the Act, the primary time for which the Act holds, the time of interest from the perspective of the Act's intention. Effective time can be used to define the frequency at which a repeating Act should be performed. If the effective time is used as a repeating frequency, the number of repeats is constrained by Act.repeatNumber. priorityCode: A code (e.g., for routine, emergency), specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. confidentialityCode: A code that controls the disclosure of information about this Act, regardless of mood. repeatNumber: An interval of integer numbers stating the minimal and maximal number of repetitions of the Act. The number of repeats is additionally constrained by time. The Act will repeat at least the minimal number of times and at most, the maximal number of times. Repetitions will also terminate when the time exceeds the maximal Act.effectiveTime, whichever comes first. On an Act in Request mood, a repeat numbers greater than 1 indicate multiple occurrences of the order are being requested. In promise mood repeat number indicates the number of occurrence Acts the filler is promising to perform. On an Act in Event mood, the repeatNumber is usually 1. If greater than 1, the Act is representing a summary of several event occurrences occurring over the time interval described by effectiveTime. interruptibleInd: An indicator specifying whether Act is interruptible by asynchronous events. independentInd: An indicator specifying whether the Act can be manipulated independently of other Acts or whether manipulation of the Act can only be through a super-ordinate composite Act that has this Act as a component. languageCode: The primary language in which this Act statement is specified, particularly the language of the Act.text.

ActRequest

The generic act class captures information pertinent to acts in order mood. This is the central concept of the DMIM, and all the other classes shown are only interesting and relevant in relationship to this focal act. The relevant information items, the attributes and associations have a consistent meaning for observation definitions, for orders, for promises, and for events.

Attributes in the ActRequest

classCode: A code specifying the major type of act that this act-instance represents. This is constrained to the classCode value set. moodCode: A code distinguishing whether an act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc. In general the orders and observations domain deals with request (RQO), promise (PRMS) and event (EVN) moods. For this section, the moodCode is constrained to RQO. id: A unique identifier which identifies this particular ActRequest instance. code: A code specifying the particular kind of act that the ActRequest-instance represents within its class. The coding strength for the field is CWE, meaning that local codes can be used here. negationInd: An indicator specifying that the ActRequest statement is a negation of the ActRequest as described by the descriptive attributes. text: A textual or multimedia description (or reference to a description) of the ActRequest. statusCode: A code specifying the state of the ActRequest. effectiveTime: A time expression specifying the focal or operative time of the ActRequest, the primary time for which the ActRequest holds, the time of interest from the perspective of the ActRequest's intention. Effective time is the physiologically relevant time being aimed for. In the case of Laboratory specimen based ActRequests it is the time of specimen collection. Effective time can be used to define the frequency at which a repeating ActRequest should be performed. If the effective time is used as a repeating frequency, the number of repeats is constrained by ActRequest.repeatNumber. Normally, this is the only time attribute included in an ActRequest Act. priorityCode: A code (e.g., for routine, emergency), specifying the urgency under which the ActRequest happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. confidentialityCode: A code that controls the disclosure of information about this ActRequest, regardless of mood. repeatNumber: An interval of integer numbers stating the minimal and maximal number of repetitions of the ActRequest. The number of repeats is additionally constrained by time. The ActRequest will repeat at least the minimal number of times and at most, the maximal number of times. Repetitions will also terminate when the time exceeds the maximal ActRequest.effectiveTime, whichever comes first. On an act in Request mood, a repeat numbers greater than 1 indicate multiple occurrences of the order are being requested. interruptibleInd: An indicator specifying whether the ActRequest is interruptible by asynchronous events. independentInd: An indicator specifying whether the ActRequest can be manipulated independently of other acts or whether manipulation of the ActRequest can only be through a super-ordinate composite act that has this ActRequest as a component. languageCode: The primary language in which this ActRequest statement is specified, particularly the language of the ActRequest.text. methodCode: A code that provides additional detail about the means or technique to be used to ascertain the ActRequest. In all ActRequests the method is already partially specified by simply knowing the kind of ActRequest (ActRequest definition, ActRequest.code) and this implicit information about the method does not need to be specified in ActRequest.methodCode. For example, many LOINC codes are defined for specific methods as long as the method makes a practical difference in interpretation. Thus, using LOINC, the difference between susceptibility studies using the "minimal inhibitory concentration" (MIC) or the "agar diffusion method" (Kirby-Baur) are specifically assigned different codes. The methodCode therefore is only an additional qualifier to specify what may not be known already from the ActRequest.code. targetSiteCode: A code specifying detail about the anatomical site or system that is the focus of the ActRequest if this information is not already implied by the ActRequest definition or ActRequest.code.

RequestChoice Act Relationships

The following act relationships are defined for acts within the RequestChoice choice box: • component • componentOf • reason • pertinentInformation • precondition • definition • ocurrenceOf • subjectOf3 • subjectOf2 • replacementOf • pertinentInformation2

component: Allows composite acts to be constructed using a sub-component structure. This structure accommodates a number of functionally relevant situations. For example, a hospital may define a test, such as VS (Vital Signs), that is a combination of several individual tests. This allows several related tests to be initiated with a single order or intent. Composite tests, or batteries are created to support several different functional situations. It is also possible to create tests that require a series of acts extending over a period of time for their completion, and for the creation of a meaningful result, for example a glucose tolerance test. In this case, an individual test is ordered, and broken down into components each of which is performed at a particular time, by particular participants.

componentOf(Encounter): The encounter in the context of which this act occurs. The patient encounter is an act extending over a period of time that becomes a container (for both clinical and financial analysis) for acts related to an instance of patient care. Encounters are most frequently created to support patients receiving inpatient care. Encounter information is contained in the A_Encounter CMET.

reason: A set of observations that are the reason or rationale for the focal observation request.

pertinentInformation: This association makes it possible to link an act with another act that provides supporting information of some kind.. This information is contained within the A_SupportingClinicalInformation CMET.

precondition: Associates the order with one or more observations that provide criteria governing the fulfillment of the order. The preconditions must evaluate to true for the order to be considered active. The target of the precondition act relationship is a clone of the Observation Event Criterion act.

definition: A link to the definition information associated with this particular type of order.

ocurrenceOf: Links all the individual occurrences of a repeating Act to that repeating Act (aka "parent").

subjectOf3(ConsentEvent): The record of a patient's or patient representative's consent to this act. The particular use case for this consent to be attached to typically an order is for advanced beneficiary notices. Consent information is contained in the ConsentEvent class. Note that the ConsentEvent is not the consent document itself, rather it records that the consent took place.

subjectOf2: Used to associate one or more annotation observations with the focal order. The author uses the annotation observation to include notes or comments as pertinent observations. These pertinent observation annotations do not have instance identifiers or status codes. Consequently, they must have the independentInd element set to false.

replacementOf: Makes it possible to identify a prior order (or report) which this one replaces.

pertinentInformation2: Each order may have one or more pertinent ProcessSteps. ProcessSteps cover activities such as accessioning, collection, transportation, and result processing. Virtually any workflow step in any department can be communicated here. The statusCode attribute has been provided to allow the communicator to indicate the state of a process step (including completion). The performer participation from the ProcessStep act is used to indicate the entity who completed this step.

RequestChoice Participations

The following participations may be associated to the acts within the RequestChoice choice box: • author • verifier • performer • informationRecipient • dataEnterer • consultant • recordTarget • subject • dataEntryLocation • callBackContact • location

author(AssignedEntity): The party that is responsible for creating the RequestChoice. For orders, this is the party who placed the order, for events, the party who principally authors the test result/report (commonly known as the filler). Information about the author is captured in the R_AssignedEntity CMET. This CMET can represent the individual author and the organization that the author represented in this act, either one or both can be specified.

verifier(AssignedEntity): Parties who verify information related to the RequestChoice, and who may have the responsibility of reviewing authorization of the act. For example, a resident writes an order and needs countersignature by a staff physician. Similar things can happen for results. Verifier information is defined using the R_AssignedEntity CMET. There can be multiple verifiers. Each may verify a different aspect of the order. For example, supervising providers, attending physicians, co-signing nurses, etc.

performer(AssignedEntity): The party who takes part in actually carrying out the act. In event-mood, the actual performer, in order or promise mood the designated performer. There may be multiple performers because several parties may collaborate in performance of the act. There may not be any specified, because these details will be left to the discretion of the author of the event. Author is required, but performer is not.

informationRecipient(AssignedEntity): Includes urgent notification contact (a.k.a. callback) and secondary recipients (a.k.a. trackers, result-cc). If these information recipients are attached to the order, the fulfiller is required to notify and copy respectively. Information recipient information is defined within the R_AssignedEntity CMET.

dataEnterer(AssignedEntity): The transcriptionist or other party who entered the information of the act. In some cases, multiple parties will be involved. In other cases, the identity of the party involved could be inherited from the context, or may not need to be communicated as part of the act. Data entry party information is defined within the R_AssignedEntity CMET.

consultant(AssignedEntity): An advisor participating in the service by performing evaluations and making recommendations.

recordTarget(Patient): The medical record that holds the documentation of this RequestChoice. Patient’s medical record information is specified with the R_Patient CMET.

subject(Patient): The party that the RequestChoice "is for". A patient may be a person or animal (non-person living thing). Patient information is specified with the R_Patient - clinical CMET.

dataEntryLocation: The place where the data about the order was entered.

callBackContact: A person or organization who should be contacted for follow-up questions about the act in place of the author. Call Back Contact information is defined using the R_NotificationParty CMET.

location(R_LocationServiceDelivery): The facility where the service is done. May be a static building (or room therein) or a moving location (e.g., ambulance, helicopter, aircraft, train, truck, ship, etc.). Location information is defined using the R_LocationServiceDelivery CMET.