Orders and Requests Pattern

Back to Orders & Observations WG main page

Scope of Orders and Requests Pattern

The model described in this document is a pattern designed to be used within multiple HL7 Version 3 domain models. This 'pattern' is intended to facilitate the consistent design of communications that convey a request for services to meet specific use cases. It is not intended that the 'pattern' itself is ever used in a communication, and consequently the information in this document is necessarily at a high level with a minimum of constraints applied.

Use of the model

The Orders and Requests Pattern RMIM represents a standard, high-level structure for the inclusion of information in communications intended to support specific requests for service within a healthcare setting. These services include administrative as well as clinical business functions. Although not capable of being implemented 'as is', the Orders and Requests Pattern can be modified to meet the requirements of many specific communications regarding a request for service. The process of modification will involve either pattern constraint or extension (or sometimes both) in order to achieve the needs of a particular domain. Pattern constraints include:

• A few ‘General Order and Request’ object attributes are constrained to reflect the nature of the pattern usage. For example:
• moodCode is constrained to ‘RQO’ for request (or order).

The generic ‘General Order and Request’ object attributes may be further constrained to reflect the precise nature of the data to be conveyed. For example:

• Optional attributes may be removed if not appropriate to the business case
• Attributes themselves may be constrained
• Multiplicities may be constrained to narrower number sets, e.g. (0..*) may be constrained to (1..*)
• Attribute value sets may be constrained to smaller attribute value sets
• Datatypes for an attribute may be constrained, e.g. 'ANY to CD'
• Associations may be constrained to remove the potential for complexity, e.g. the limitation of an implementation to three levels of nesting; the removal of 'Episode Link' in order to define an implementation to the 'lowest common denominator' regarding system capabilities
• Classes may be constrained: e.g. 'classCode' limited to 'PROC’ (Procedure)
• Classes may be removed if not required
• Classes may be constrained to specific subclasses, e.g. 'Observation Class' constrained to 'Condition Class'
• Classes may be 'cloned' in order to document specific constraints on attributes or associations.
• Classes with specific constraints applied may be 'unrolled' from the Clinical Statement Choice box in order to constrain their use to a specific structure (in that case, the constrained version of the class may no longer be assumed to be present in the generalized Clinical Statement Choice Box)

Options for pattern extension include:

• Additions of classes, attributes, and associations allowed in the RIM
• Enlargement of the value sets as supported by RIM approved vocabulary

Philosophy on Extensions

The intention of the 'pattern' is that it should represent the information most often required in order to request a healthcare service in an unambiguous and coherent representation. Due to this philosophy, extensions to this model do not need to be approved by the Orders and Observation Technical Committee. However, all extensions should be brought back to OO in order to maintain harmonization and possible inclusion in the pattern.

Pattern Use

This pattern is to be used as a starting point when developing any messages to communicate a request for healthcare service. The Observation Order RMIM is an example of a request for healthcare service developed from the Orders and Requests Pattern model.

Model Overview

R-MIM

Model Visio: File:POOO RM200999.vsd

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

NOTE: THIS WALKTHROUGH IS OUT OF DATE

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

This RMIM represents only transactions related to orders (mood = RQO). Included in this ballot is the General Events DMIM as well. Future ballot materials will also support transactions related to promises (mood = PRMS). These moods, which are central concepts for all Orders and Observations RMIMs, 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.

Orders Refined Message Information Model Classes

Entry into the RMIM 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 model, moodCode is fixed 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 model, the moodCode is fixed 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: 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 act 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.
• occurrenceOf: Links all the individual occurrences of a repeating Act to that repeating Act (aka "parent").
• subjectOf3: 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.

RequestChoice Participations

The following participations may be associated to the acts within the RequestChoice choice box:

• 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.
• 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.
• receiver(AssignedEntity): The assigned recipient of a delivered patient supply.
• 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.
• destination(R_LocationServiceDelivery): The location where the supply or diet is to be delivered which may not be a patient location.
• product: The product is the supply item to being ordered.