Structuring Order Sets for Interoperable Distribution

Abstract

A major portion of patient care planning occurs during the process of writing orders. Computerized order entry can present collections of predefined orders to the user during the ordering process. These order sets are useful for promoting standards of care, and provide one element of structured clinical knowledge to be used by Computerized Provider Order Entry (CPOE) systems at the point of care. Since the creation, confirmation and maintenance of order sets is resource intensive, sharing order sets is a useful goal. We describe a standard representation of order sets that supports maintenance, sharing and interoperation of pre-defined order sets. A dialogue within the HL7 community seeks to harmonize this proposal with the Clinical Document Architecture and the HL7 Reference Information Model.

INTRODUCTION

Many efforts are underway to translate evidence based clinical knowledge to actions at the point of care in support of error reduction, quality improvement, and reduced healthcare process variability. Predefined care plans detailing the essential steps in the treatment of patients with well defined clinical problems are designed to translate published guidelines into local workflow¹. Order sets consisting of predefined collections of orders addressing a particular patient scenario have been established for many common processes for medical, surgical, and procedural problems². Use of order sets is familiar for most clinicians³ and most institutions have pre-printed order sets in use.

Incorporation of order sets into CPOE systems is a powerful tool to guide clinicians to utilize best practices in their care planning sessions⁴, support implementation of standard care plans⁵, and reduce errors. However, creating, managing, updating and distributing a large collection of predefined orders and order sets is a time-consuming step in the preparation for installation of CPOE systems.⁶ In most cases authoring order sets is a local process requiring custom development and programming that involves the time and energy of knowledge engineers and clinical specialists^7–9. To ease the development burden and improve turn around time, specific tools for authoring and displaying order sets have been created for local use^10–12.

Recognizing that the creation of evidence based order sets is difficult and possibly a barrier to CPOE implementation, the Architecture and Standards Committee at the National Health Information Infrastructure 2004 meeting in Washington DC recommended the creation of standardized rule and order set libraries to aide clinical decision support transactions¹³. A shared repository of predefined order sets for publication and deployment in local systems requires a standard representation independent of specific CPOE implementations. The representation must also incorporate standardized vocabulary and data structures. We describe here a representation of order set content that supports interoperable publication and exchange of order sets developed by local and national clinical experts based on HL7 standards.

METHOD

We consider an order as an authenticated communication from a licensed practitioner authorizing a care plan action for a patient. We describe an order set as a template or collection of related orders, goals and communications assembled to organize a portion of a care plan.

In dialogue with the HL7 Clinical Decision Support Technical Committee (CDS TC) we developed a set of use cases defining four layers of increasingly detailed scenarios for the utilization of order sets. In Layer I vendors publish and distribute carefully crafted order sets for incorporation into practice by health care institutions. Order set knowledge exists within the proprietary format of the vendor and requires the client institution to adapt them for local use. Order set repositories are authored, maintained, and disseminated by multiple specialty groups both public and private in the standard format and easily converted to a vendor’s proprietary format. To support this type of sharing the proposed standard specifies a detailed header containing metadata about the order set content, use case, applicable patient population, and editorial history similar to features of the Guideline Elements Model¹⁴.

In a more detailed scenario, Layer II, each order item is specified so institutions can elect to share their order sets during their efforts to implement CPOE. Although many Hospital Information System (HIS) packages support order sets they have different order definitions and order processing systems. These systems may support textual alerts (comments) associated with an order. The Layer II scenario provides a standard representation of orders so any institution can import an order set and map it to their internal order definitions with associated textual alerts. Additional notations within the header metadata allow institutions to track implementation progress and milestones.

For the more detailed Layer III scenario a clinical middleware company might provide standardized order sets to a major software vendor to deploy in its provider order processing software. The middleware vendor maintains a library of current clinically reviewed orders sets employing the standards of Layers I and II to manage the content. The Layer III standard controls clinical presentation features that are integral to the order sets. Order grouping and sequencing specified by the middleware vendor, along with default pre-selection of orders and logical grouping of order actions all make the order set more clinically useful, efficient and attractive for clinician use. Embedded alerts from layer II enhance the understanding and proper selection of orders appropriate for the clinical situation. Resource links attached to each order allow for an expanded web-based help function relevant to each order when necessary¹⁵.

Layer IV provides for complete interoperation where a consortium of health care providers and vendors may share interactive guidelines. One feature of such systems is the deployment of dynamic, problem-oriented order sets to implement protocol-based work sessions¹⁶. In addition to the library, sharing, and presentation features mentioned above the order sets employ embedded decision logic to decide which orders to present at run time. Problem and session encoding of order sets assure that they may be employed in all relevant clinical contexts, and that order sessions may be merged when multiple guidelines apply to care planning for aa single session. Service coding of each order within the order set and order master allows the guideline software to determine whether an instance of an order is already active, and to manage merging of order sets to eliminate duplication. Level of recommendation flags allow dynamic prioritization of orders within sets, so that multiple treatment options may be placed in perspective for the clinician.

Based on these four use cases we observe from our previous work with order sets¹¹ that the content and structure for shareable order sets will need to support these basic and advanced features:

• Metadata for documentation of creation, edit and indexing

• Identification and coding of sufficient clinical context for appropriate employment of order sets by computer

• Support for clinically relevant ordering and organization of orders within sets

• Textual or graphical information items to improve organization, readability and comprehension of order set content by the clinician

• Mechanisms for linking of orders within a unit of work into a logical and cohesive set of actions

• Support for identification and pre-selection of common and protocol-based orders

• Alerts and explanatory text linked by order

• Links from the context of an order and the order set to help functions

• Formalisms for support of decision logic which can control presentation, prioritization and sanctioning of orders, although we assume that common vendor services such as allergy checking, drug interaction checking and dosing calculation will not be included in the order set decision layer.

RESULTS

The standard now being prepared for ballot at HL7 models an order set that requires header information that identifies the order set, specifies the patient population for whom the order set is useful, links the order set to the guideline or care plan, identifies the protocol session whose management this supplements, and contains editorial information for authorship and proper maintenance. The order set body includes line by line items in the order set for display to the clinician or mapped to the local ordering system. Each line in the order set is an order set item that contains both the order specification and information about the order and its relationship to the order set.

The header information (figure 1) supports indexing, editing and browsing of a library of order sets. This support requires data concerning the contents of the order set, the patient context for which the order set is valid and editorial information. Editorial information includes the responsible organization, dates for which the order set is valid and reference information. Each order set has a unique identification key to support identification and use in the body of other order sets These data items are included in header information attached to the order set. At this level of detail the order set can be used as a text document available for printing or browsing. This format has features similar to the HL-7 Clinical Document Architecture¹⁷ and a dialogue is underway to create a consensus representation.

Figure 1.

Order set header fields based on HL7 Version 3 Reference Information Model

Order set body

Because of the multiple scenarios in which these order sets may be deployed, the proposed standard presumes some features of the order processing system that are not discussed in the proposal. These features include: order presentation and processing, duplication checking, medication interaction checking and allergy checking. By exposing the details of the individual entries sophisticated decision support engines can manipulate the individual orders to provide custom alerts, dose modification, and preselection of preferred orders.

Order items

The basic unit of the order set body is an order item. An order item contains fields that describe the recommended action and supporting information. Each entry in the order set body provides details about each order to support the localization process when the order set is incorporated into the local CPOE application. Each order item in the order set may be 1) an order for a service or medications 2) may represent a goal or 3) an observation to be charted or it may be 4) a non-actionable information item or group header, or it may 5) refer to an external order set meant for inclusion in the body

The different types of order items (figure 2) are defined with fields derived from the version 3.0 Reference Information Model (RIM) Act subtypes. Using these standardized definitions permits a decision engine to identify the coded subject of the order, the dose, route, frequency, repetition count and other structured elements which are needed for guideline decision logic.

Figure 2.

Order item fields include basic fields of an order item and custom fields depending on type of item.

The full text provides context information for the user to map to their local order master. The alert text supports addition of a text field to the order within the order set. Calls to external order sets or nesting of one order set within another supports maintenance of protocols and order sets by different groups within the institution. These nested order sets are included within the order set at the time of order processing by the clinician. This mechanism supports editorial efficiency and helps avoid updating multiple order sets when changes in a protocol are made.

Non-actionable text entries allow the order set author to include guidance for utilization of the order set. This entry may be a separator to describe the purpose of the following orders. These order groups are a textual category for the order; software may employ these tags to link orders with similar actions or intent within an order set for ease of clinical browsing and to aid understanding and order selection. They may express intent, such as “Diagnostic” or “Treatments”, or be organizational in nature, such as “Laboratory” or “Radiology.” Non-actionable entries may also provide instructions for use of the order set. For instance an insulin protocol might include a table of recommended insulin doses for different blood glucose levels. The full text order is a complete textual description of the order including frequency, priority, repetitions, and related details. The order alerting text is a text message which is displayed as an informational item with an order set item at the time of the order session. The alerting text may be a static element of the order set or may be dynamically populated at the initiation of the order session by a decision support program.

Requests for services such as laboratory and radiology orders contain a field for standard coding schemes such as SNOMED CT¹⁸ or LOINC¹⁹ to support interoperability. Goals communicate process expectations to the care team. An example might include delivering an antibiotic within four hours of admission. These goals also support efforts to deploy clinical performance measures at the point of care. Observations support the opportunity to collect and record relevant data during the care planning process. When an aspirin is indicated for chest pain the clinician can indicate it was given prior to arrival and fulfill documentation requirements.

Pre-selection flags indicate the preferred orders in the order set. These are generally set at the time the order set is authored. But in layer IV implementations order pre-selection may be modified for display by the decision support software depending on patient specific data.

Logical Groups

Since an order set is a collection of recommended actions there are often recommendations for alternative action or related orders that must be considered. Logic internal to the order set is supported through the concept of a Boolean collective. Each entry in the order set can be a member of a group that may be exclusive or inclusive. Groups of exclusive orders (XOR) allow the user to select only one of the orders in the group (figure 3). Dietary orders are an example of mutually exclusive orders. Only one type of diet can be ordered at time. Inclusive groups mean that selecting one order requires the selection of the corollary orders (AND). Corollary orders are used to recommend ordering another order when one is selected.

Figure 3.

Segment of an order set for community acquired pneumonia with order group for no recent antibiotic therapy pre-selected, alerting text inserted by decision support for allergy, drug interaction, and pre-selection of alternative.

We specifically expect standard decision support tools such as drug-drug and drug-allergy checking to be a property of the supporting HIS platform. Therefore these requirements were not considered intrinsic to the order set definition.

DISCUSSION

Without indexing, standardizing and sharing order sets each health care system will have to invest the time in creating a library of order sets within their own system²⁰. We have found that the work of creating a library of order sets necessitates a long lag time between order set creation and deployment. This lag time is a disincentive for the local creation of order sets¹¹. Standardizing and sharing order sets will reduce the workload of local developers and support dissemination of best practices. Previous work by CPOE pioneers has demonstrated that custom coding of knowledge components is time consuming and labor intensive and that poorly implemented CPOE systems may lead to rejection by physicians.

Previous reports suggest that implementation failure and increased errors may occur in the presence of poor workflow design²¹ and when predefined order sets are not deployed²². We expect the creation of a common order set definition will allow CPOE implementers to “cross the chasm” and focus on implementation issues rather than the local creation of order sets.

Internal investigations during the SAGE project have demonstrated that a decision support system can recommend patient and context specific therapies through annotated order sets. This interaction between an external defined order set and decision support tools deployed within CPOE systems requires further investigation.

Growing from our use cases we have defined the requirements for shareable, interoperable order sets based on the HL7 version 3 RIM. Our intent is to create an interoperable order set format to support knowledge sharing. Sharing the work of order set creation may reduce one of the barriers to adoption of provider order entry systems and decision support systems in the course of care

This specification is being readied by the Clinical Decision Support Technical Committee at HL7 as a draft standard. Interested readers are welcome to peruse the documents available at www.hl7.org. Also, efforts are under way to harmonize this proposal with the Controlled Document Architecture and the HL7 reference information model.