Draft Standard for Trial Use · 2018-10-24 · This draft standard is not an accredited American...

V3_SPEC_ORDERSRVINT_R1_DSTU_2015FEB

HL7 Version 3 Specification: Ordering Service Interface, Release 1 – U.S. Realm

Draft Standard for Trial Use

February 2015

Publication of this draft standard for trial use and comment has been approved by Health Level

Seven International (HL7). This draft standard is not an accredited American National Standard.

The comment period for use of this draft standard shall end 24 months from the date of

publication. Suggestions for revision should be submitted at

http://www.hl7.org/dstucomments/index.cfm.

Following this 24 month evaluation period, this draft standard, revised as necessary, will be

submitted to a normative ballot in preparation for approval by ANSI as an American National

Standard. Implementations of this draft standard shall be viable throughout the normative ballot

process and for up to six months after publication of the relevant normative standard.

Copyright © 2015 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form

is strictly forbidden without the written permission of the publisher. HL7 International and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

Sponsored by:

Clinical Decision Support Working Group HL7

Orders and Observations Working Group HL7

Service Oriented Architecture Group HL7

http://www.hl7.org/dstucomments/index.cfm


February 2015 © 2015 Health Level Seven International. All rights reserved.

IMPORTANT NOTES:

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

http://www.hl7.org/implement/standards/index.cfm

http://www.hl7.org/legal/ippolicy.cfm



Project Lead Emory Fry, MD

Editor Alfred Bustamante

Authors Emory Fry, MD

Jerry Goodnough

Claude Nanjo



Preface

Notes to Readers

This document is the Service Functional Model for the Order Service (OS), which is specified

under the Service Development Framework process under the auspices of the Healthcare

Services Specification Project (HSSP). Further context is given in the overview section below,

but one key point to note is that the SFM provides a Service Interface specification, NOT the

specification for a Service implementation. This is a critical distinction in terms of Service

Oriented Architecture. There could be many different ways of implementing all or part of the

functionality to support the behavior described in this specification.

Acknowledgements

In addition to the listed authors, the following individuals are acknowledged for

their contributions during the development and review of this document.

Lorraine Constable (Constable Consulting)

Steven Elliott (Cognitive Medical Systems)

Ken Kawamoto, MD (University of Utah)

Victor Lee, MD (Zynx Health)

Bernadette Minton (Zynx Health)



Important Notes

A. If you are the individual that downloaded or ordered this HL7 Standard,

specification or other work (in each and every instance "Material"), the following

describes the permitted uses of the Material.

B. If you are NOT such individual, you are not authorized to make any use of the

Material. To obtain an authorized copy of this Material, please visit

http://www.hl7.org/implement/standards/index.cfm.

C. If you are not an HL7 Organizational Member, the following are your permitted

uses of this Material:

1. Read and Copy License Only. HL7 hereby grants you the right, without charge,

to download and copy (for personal use only) this Material for study purposes only.

This license grant does not include the right to sublicense or modify the Material, or

to implement the Material, either in whole in part, in any product or service.

Please see http://www.hl7.org/legal/ippolicy.cfm for the full license terms governing

the Material.

D. If you are an HL7 Organizational Member, the following are your permitted uses of

this Material.

1. Implementation License Terms.

1.1 Definitions. As used in this Agreement, the following terms shall have the

following definitions:

"Compliant Product" is a product or service that implements Material that is an

HL7 Specification in whole or in part.

"End User" is a company, entity or individual that is the ultimate purchaser or

licensee from Licensee of a Compliant Product.

1.2 License. In consideration of becoming an Organizational member of HL7 and

continuing to pay the appropriate HL7 Organizational membership fees in full, HL7

hereby grants to you without additional charge, on a perpetual (except as provided for

in the full license terms governing the Material), non-exclusive and worldwide basis,

the right to (a) download, copy (for internal purposes only) and share this Material

with your employees and consultants for study purposes, and (b) utilize the Material

for the purpose of developing, making, having made, using, marketing, importing,

offering to sell or license, and selling or licensing, and to otherwise distribute,

Compliant Products, in all cases subject to the conditions set forth in this Agreement

and any relevant patent and other intellectual property rights of third parties (which

may include members of HL7). No other license, sublicense, or other rights of any

kind are granted under this Agreement.

Please see http://www.hl7.org/legal/ippolicy.cfm for the full license terms governing the

Material.

http://www.hl7.org/implement/standards/index.cfm

http://www.hl7.org/legal/ippolicy.cfm



Table of Contents

1 Overview ........................................................................................................................7 1.1 Introduction and Scope ............................................................................................7 1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP) ...............................7 1.1.2 Service Definition Principles ...................................................................................8 1.2 Overall disclaimers ..................................................................................................9 1.3 Readers Guide ..........................................................................................................9

2 Executive Summary .....................................................................................................10 2.1 Service Overview ...................................................................................................10 2.1.1 Service Description and Purpose ...........................................................................10 2.1.2 Scope ......................................................................................................................11 2.2 The Reason Why the Service Is Necessary............................................................12 2.3 Context of this SFM within the HSSP Roadmap ...................................................14 2.4 Structure of the Service ..........................................................................................16 2.5 Implementation Considerations .............................................................................19 2.6 Deployment Scenarios ...........................................................................................19 2.6.1 Inter- and Intra-Organizational Deployment Examples .........................................20

3 Business Storyboards ...................................................................................................26 4 Assumptions and Dependencies ..................................................................................27 5 Detailed Functional Model for Each Interface .............................................................28

5.1 Domain Model .......................................................................................................28 5.2 Entities ...................................................................................................................30 5.2.1 Functional Entities .................................................................................................30 5.2.2 Informational Entities ............................................................................................32 5.2.3 Handling Aggregate Data ......................................................................................35 5.2.4 Security and Auditing ............................................................................................35 5.3 Order Management Interface .................................................................................36 5.4 Fulfillment Update Interface ..................................................................................42 5.5 Fulfillment Interface (Implemented By Fulfillment System) ................................45 5.6 Order Workflow Interface ......................................................................................49 5.7 Order Service Catalog Query Interface ..................................................................55 5.8 Order Service Catalog Management Interface .......................................................57 5.9 Order Notification Interface ...................................................................................59 5.10 Order Monitoring Interface ....................................................................................61 5.11 Order Service Monitoring Interface .......................................................................63 5.12 Example Event Flows ............................................................................................65

6 Profiles .........................................................................................................................70 6.1 Introduction ............................................................................................................70 6.2 Conformance Profiles ............................................................................................70

7 Recommendations for Technical RFP Issuance ..........................................................71 Appendix A – Relevant Standards .....................................................................................72 Appendix B – Glossary ......................................................................................................73 Appendix C – Relationship to Information Content ..........................................................74



1 Overview

1.1 Introduction and Scope

The Service Specification Development Framework Methodology is the methodology followed

to define HSSP specifications. The methodology sets out an overall process, and also defines the

responsibilities of the Service Functional Model (SFM). Section 2 sets out the business context

for this particular specification, but firstly it is important to understand the overall context within

which this specification is written, i.e., its purpose from a methodology standpoint.

1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP)

The Healthcare Services Specification Project (HSSP) [http://hssp.wikispaces.com] is a joint

endeavor between Health Level Seven (HL7) [http://www.hl7.org] and the Object Management

Group (OMG) [http://www.omg.org]. The HSSP was chartered at the January 2005 HL7

meeting under the Electronic Health Records Technical Committee, and the project was

subsequently validated by the Board of Directors of both organizations.

The HSSP has several objectives. These objectives include the following:

To stimulate the adoption and use of standardized “plug-and-play” services by healthcare

software product vendors

To facilitate the development of a set of implementable interface standards supporting

agreed-upon services specifications to form the basis for provider purchasing and

procurement decisions

To complement and not conflict with existing HL7 work products and activities,

leveraging content and lessons learned from elsewhere within the organization

Within the process, HL7 has primary responsibility for (1) identifying and prioritizing services as

candidates for standardization; (2) specifying the functional requirements and conformance

criteria for these services in the form of SFM specifications such as this document; and (3)

adopting these SFMs as balloted HL7 standards. These activities are coordinated by the HL7

Services Oriented Architecture special interest group in collaboration with other HL7

committees, which currently include the Vocabulary technical committee (TC) and the Clinical

Decision Support (CDS) TC.

Based on the HL7 SFMs, OMG will develop “Requests for Proposals” (RFPs) that are the basis

of the OMG standardization process. This process allows vendors and other submitters to

propose solutions that satisfy the mandatory and optional requirements expressed in the RFP

while leaving design flexibility to the submitters and implementation flexibility to the users of

the standard. The result of this collaboration is an RFP submission, which will be referred to in

the HSSP process as a Service Technical Model (STM). HL7 members, content, and concerns

are integral to this process, and will be explicitly included in the RFP creation and evaluation

process.

It is important to note that the HL7 SFMs specify the functional requirements of a service, the

OMG RFPs specify the technical requirements of a service, and the STM represents the resulting

technical model, except as specified below. In many cases, SFMs describe an overall coherent

http://hssp.wikispaces.com/

http://www.hl7.org/

http://www.omg.org/



set of functional capabilities and/or define a minimum set of behaviors necessary to guarantee a

minimal level of service in a deployment scenario. These capabilities may be specialized or

subdivided from both functional and informational (semantic) perspectives to provide

conformance “profiles” that may be used as the basis for the OMG RFP process and/or

implemented.

The development of this specification adheres to the principles outlined by Services-Aware

Interoperability Framework (SAIF), in particular the Behavioral and Information frameworks.

SAIF aims to provide consistency between specifications that cover governance, conformance,

and behavioral semantics necessary to achieve working interoperability. This specification

focuses primarily on behavioral semantics with references to informational concepts relevant to

the service specification. It is a technology neutral specification.

1.1.2 Service Definition Principles

The high level principles regarding service definition that have been adopted by the Services

Specification Project are as follows:

Service Specifications shall be well defined and clearly scoped and with well understood

requirements and responsibilities.

Services should have a unity of purpose (e.g., fulfilling one domain or area) but services

themselves may be composable.

Services will be specified sufficiently to address functional, semantic, and structural

interoperability.

It must be possible to replace one conformant service implementation with another

meeting the same service specification while maintaining functionality of the system.

A Service at the SFM level is regarded as a system component; the meaning of the term

“(system) component” in this context is consistent with UML usage1. A component is a modular

unit with well-defined interfaces that is replaceable within its environment. A component can

always be considered an autonomous unit within a system or subsystem. It has one or more

provided and/or required interfaces, and its internals are hidden and inaccessible other than as

provided by its interfaces.

Each Service’s Functional Model defines the interfaces that the service exposes to its

environment, and the service’s dependencies on services provided by other components in its

environment. Dependencies in the Functional Model relate to services that have or may in future

have a Functional Model at a similar level; detail dependencies on low-level utility services

should not be included, as that level of design is not in scope for the Functional Model.

The manner in which services and interfaces are deployed, discovered, and so forth is outside the

scope of the Functional Model. However, HSSP Functional Models may reference content from

other areas of HSSP work that deals with architecture, deployment, naming and so forth. Except

where explicitly specified, these references are to be considered informative only. All other

1 It is expected that services will be defined, in response to the OMG RFP process, as UML components; however,

that level of design is outside the scope of the Functional Model.



interactions within the scope of the scenarios identified above are in the scope of the Functional

Model.

Reference may be made to other specifications for interface descriptions, for example where an

interface is governed by an existing standard.

1.2 Overall disclaimers

Examples are illustrative and not normative unless otherwise specified.

The scope of information content of HSSP service specifications is not limited to HL7

content models. At a minimum, however, specifications should provide a semantic profile

as part of its conformance profile to provide support for HL7 content models where

applicable.

1.3 Readers Guide

Based upon the nature of your interest, we suggest the following as areas to focus your attention:

Audience Sections (In order of Priority)

Domain Committees, SMEs 2, 3, 8

Architects, HSSP 6, 5, 8, 7, 4

RFP Submitters 2, 8, 7, 5



2 Executive Summary

2.1 Service Overview

2.1.1 Service Description and Purpose

The ordering behavior of clinicians has significant implications for the quality and cost of patient

care. Many organizations are adopting evidence-based knowledge artifacts (order sets and plans

of care) and more customized and automated approaches (such as CDS systems) to assist

clinicians with point-of-care decision-making. A strong emphasis has also been placed on more

consistent and transparent approaches to the management and allocation of health care resources

within an increasingly heterogeneous ecosystem of information system technologies. This

service functional model (SFM) seeks to support more effective provider ordering, order

management, and order fulfillment.

The Order Service (OS) provides a consistent, structured methodology for ordering a variety of

services and products, including, but not limited to, pharmacy, nutrition, radiology, and

laboratory items. It is intended to support the lifecycle of an order(s) using common services

that range from identifying orderable items and how these can be ordered, how orders can be

created and modified, and how order results can be retrieved. The service ensures that access

control to these core functions is role based and appropriate, and that orders can be managed in a

reliable and reproducible fashion. The service provides common governance and orchestration

for the full order lifecycle, from a simple bed assignment order to a complex chemotherapy

regimen involving multiple courses of treatment over many months.

In addition to expected create/modify/execute functionality, the Order Service facilitates

discovery of requirements that must be satisfied if an order is to be successfully executed. Orders

are often accompanied by a set of constraints, either for the successful submission/acceptance of

an order, or for its subsequent fulfillment. For example, a referral management system may

require that an imaging study be requested before it will accept an orthopedic consult order.

Similarly, a laboratory fulfillment system may have specimen collection requirements, i.e.

ammonia levels need to be collected in green top tubes and delivered to the laboratory on ice

within 30 minutes of being drawn. Such constraints are typically documented using nursing

procedures or other non-computable methods that are inefficient and not amenable to automation

or decision support. In the future, the Order Service envisions a workflow specification by which

workflow requirements and processes will be machine discoverable, managed and enforced.

Another important function of the Order Service is providing catalog management capabilities to

consumers. The Order Service defines functionality surrounding the persistence, management,

and retrieval of artifacts that guide the ordering process. We refer to such functionality as the

Order Service Catalog. The Order Service Catalog allows organizations to collect, import,

annotate, manage, and export list of items that can be subsequently displayed to consumers for a

variety of different purposes. It typically holds collections of orderable items available to an

organization or facility, the definition of orderables used to render and constrain order entry

forms, and libraries of order set or plan of care definitions for any number of patient populations.

For example, the Order Catalog Service can make a medication formulary generally available for

ordering by providers, but optionally facilitate removal of an item from the orderable list if it is

out of stock. Making inventory items known to users is a common application of catalog



functionality and has important usability/quality control implications for Order Service

consumers. Through the management of such artifacts, in particular Order Sets, the Order

Service Catalog can play an important role in the overall governance that surrounds the ordering

of clinical services.

A listing of available fulfillment systems is another example of a non-inventory catalog item that

might be exposed by a Fulfillment Service Registry. While ordering is typically constrained by

the systems found within a single organization, one can easily imagine a time when an

increasingly distributed and competitive network of suppliers vies to provide fulfillment services.

Finally, the Order Service provides facilities for the communication and resolution of order

replacement, result verification, and result interpretation proposals that are largely outside of the

purview of existing order systems. A typical order system may facilitate order creation,

modification, cancellation, and even result reporting, but it does not usually support a fulfillment

system returning computable recommendations for either a) alternative orders that might be more

appropriate for the clinical context or intent, or b) other proposed orders that may be required to

satisfy the intent of the original request. The former occurs when a fulfiller has information

indicating that one or more ordered items may be inappropriate for a specific patient (e.g., a

regular diet for a phenylketonuric); the latter occurs when additional recommended analysis is

needed before existing results can be interpreted correctly (e.g., direct bilirubin testing in the

setting of a newborn with an elevated total bilirubin level). The recognition and adjudication of

proposed orders returned by “intelligent” fulfillment systems is currently manual, time

consuming, and error prone. In the laboratory domain, the Order Service will complement the

Integrating the Healthcare Enterprise (IHE) Laboratory Clinical Communications profile, which

defines the information models required to support automated communications between a

Laboratory Information System and its “customers” regarding order and result recommendations.

The Order Service provides a specification for how such proposals can be better managed.

The Order Service specification allows providers of complex services or applications to submit

appropriate, valid orders and to facilitate desirable interactions with a larger number of

fulfillment services. The Service helps unify disparate types of orders into a common meta-

model cleanly separating essential concerns, prerequisites, and workflow. The advantages for

care coordination, process management, and CDS afforded by having a common set of

standardized service interfaces are significant.

2.1.2 Scope

The Order Service is intended to complement existing Service Oriented Architecture (SOA)

services and the SAIF Behavioral Framework (BF) for HL7. It manages electronic requests for

healthcare services between an order source and those providing fulfillment services, specifically

recognizing that the consequences of an order are not necessarily enacted by the initial recipient,

but may only be realized after a complex, multi-step workflow. The Order Service also defines

functional behaviors surrounding the querying and management of an Order Service Catalog.

The general behaviors of ordering, order fulfillment and results reporting are supported by

appropriate Order Service interfaces; these operations are thought to be common regardless of

the service or item being requested.

It is important to note, however, that behaviors and information models in a service functional

model are presented at a higher conceptual level than the definitions one would typically find in



lower-level specifications and APIs. For instance, when discussing Order Service Catalog

behaviors, an operation such as ‘Get Catalog Item Details’ represents a general behavior on any

‘Order Catalog Item’. An Order Set Catalog may implement this operation as

getOrderSetDetails(int orderSetId) while an Orderable Item Catalog may implement this

operation as getOrderableItemDetails(int orderableItemId). Such fine-grained operations and

data model specializations are outside the scope of an SFM, as are behaviors that are unique to a

given specialization of the generic service and which are not generalizable.

While the Order Service defines a set of Order Service Catalog operations that support the

import and export of catalog items, transformations and terminology alignment operations

required to migrate content between systems are considered out-of-scope of this specification.

Note, however, that other HL7 standards currently address various aspects of this challenge.

The semantics and management of orders that are delegated or transferred are currently out of

scope. For example, the Order Service will not track who is responsible for performing a care

task if the patient’s nurse delegates that task to an aide, nor will responsibility for orders that are

transferred to alternative performers at change of shift be monitored. Similarly, reflex orders

(orders generated in response to results of other orders) are also out-of-scope at this time. Such

functionality, while important to managing clinical workflow and care transitions, will be

addressed in future iterations of this functional model.

While the Order Service provides a means for communicating requirements that might be

necessary before an order is indeed ready for fulfillment, it is not responsible for defining order

states, use-case-specific state transitions, or the workflow that might modify that state. For

example, if the Radiology department requires, in certain clinical situations, a Head CT with

Contrast before it will schedule an MRI, the Order Service will describe that requirement, but

will not determine that the MRI order should be rejected or suspended, or otherwise dictate a

workflow that causes the order to be modified. Such state management may be the responsibility

of the fulfillment system or particular implementations of the Order Service, but is currently not

standardized and not in the scope of this standard.

Finally, Order Service security (authentication, access control, encryption, auditing, etc.) is also

out of scope in the current service functional model. While such services and functionality are of

great importance to any order service implementation and deployment, they are to be covered by

other specifications or future iterations of this specification and will not be explicitly listed in

more detailed descriptions of the Order Service interfaces.

2.2 The Reason Why the Service Is Necessary

The Order Service aims to standardize key aspects of the ordering process by defining the core

set of functionality required to support reproducible order and fulfillment workflows. While

Computerized Provider Order Entry (CPOE) systems and other applications that expose ordering

functionality to individuals are obvious beneficiaries, workflow automation and CDS services

are also ideal candidates for leveraging Order Service capabilities. A Clinical Decision Support

(CDS) system might create unsigned medication or nursing care orders in response to real-time

clinical events, thereby facilitating timely and evidence-based interventions, avoiding

unnecessary delays, and improving patient outcomes. For example, if a system could

automatically recalculate a medication dosage based on the latest renal panel results and alert the

provider when an unsigned order with the adjustment was available for their consideration and



signature, then many potentially detrimental adverse drug reactions/side effects might be avoided

or at least minimized. The cost avoidance achieved by reducing iatrogenic injury is a significant

value proposition and a powerful justification for deploying a well-designed, generalized Order

Service. The functionality afforded by the service can make CDS real-time, actionable and

workflow efficient.

Equally important is the impact an Order Service might have on clinical workflow orchestration.

Orders are central to the requisition of healthcare services, the delivery of evidence-based care,

and for the timely access to the results of their fulfillment. As the legal mechanism by which

privileged providers authorize other healthcare participants to perform services and

interventions, orders are the initiators of almost all-healthcare activity. The Order Service, its

supporting functionality, and the orders it helps create are key enablers of complex clinical

workflows, both within a single care location and across organizational boundaries. Being able to

manage those workflows by creating, modifying, revoking, and monitoring the status of the

orders that initiate them is critical to ensuring that patient care can be automated when

appropriate and managed throughout the care continuum.

Reducing variance and improving reliability in order workflow is a critical objective in both

patient care and administrative activities. The great variety of ways clinical orders and order sets

are represented, created, customized, updated, executed, and fulfilled pose significant challenges

for health information systems that are increasingly distributed across organizational boundaries.

It is clear that the large number of proprietary interfaces confronting a healthcare technology

implementer is not ideal for developing generalizable, cost-effective software solutions.

Certainly a small business vendor implementing a scalable CDS system that can ‘propose’ orders

to a number of different Electronic Health Record (EHR) systems would find integration costs

prohibitive. Technology implementers and integrators will increasingly need to incorporate

Order Services when designing loosely coupled, scalable services that can be monitored and

managed by a modern healthcare organization. Only if systems map to a standard and expose

their capabilities can SOA benefits be realized. Unfortunately, too few vendors currently expose

their interfaces publicly.

Finally, the Order Service Catalog enables organizations to ensure that high quality standards are

maintained over time. Order sets and plans of care evolve as best practices and evidence change,

but without standardized Catalog APIs, it is often not easy or even possible to exchange catalog

resources between organizations. For instance, an organization may decide to contract with a

CDS knowledge provider to obtain evidence-based order sets to help them standardize care. The

organization may wish to customize these order sets (e.g., modifying the names of orderable

items to reflect the local vocabulary used at a given facility or changing the data models of

categories of orderables such as medication orderables), and with great effort, import these

customized order sets into their EMR. Given the lack of standard interfaces to support the import

of such order sets, updating local content as evidence-based practices evolve is unnecessarily

convoluted and expensive.

While this specification does not address implementation details, clinical models or message

formats, it does aims to standardize at a functional level the core types of operations that an

integrator will need to support desirable functionality and long term interoperability. This SFM,

when used in conjunction with other related standards, should help address important system

behavior concerns and facilitate robust, well-defined, interoperable services.



2.3 Context of this SFM within the HSSP Roadmap

The Order Service SFM is consistent with future order management requirements as identified in

the HSSP Roadmap Version 1.0. It contributes the functionality and behaviors of other SOA

services available to an organization and to the development of standardized “plug-and-play”

components supplied by any number of healthcare software vendors. The SFM complements

existing HL7 and OMG work products and activities, leveraging content and lessons learned

from elsewhere within both organizations.

Figure 1: The Complementary HL7 + OMG Relationship

To illustrate how an organization might integrate an Order Service into a hypothetical

infrastructure, consider the increasingly important application of decision support technologies in

support of evidence-based clinical practice guidelines. When a pediatric asthmatic patient, for

example, is first admitted to a hospital, an Admission-Discharge-Transfer (ADT) message might

be published to an Event Publish and Subscribe system that then “pushes” events to topic

subscribers. The CDS system receives this event notification, analyzes its rule base to determine

required actions, and then notifies the appropriate providers of its recommendations using a

Unified Communications Service. The intended recipients receive alerts informing them that the

CDS system, using patient information obtained from a Retrieve, Locate, and Update Service

(RLUS), selected and placed an unsigned Pediatric Asthma Admission Order Set into the

provider’s order queue. The provider is then encouraged to review the orderable items within the

set and sign those that are appropriate for their specific patient. This use case is illustrated in the

sequence diagram below.



Figure 2: Prototypic Use Of Order Service Within An Organization’s SOA.

HL7 Version 3 Specification: Ordering Service Interface, Release 1


2.4 Structure of the Service

This Service Functional Model is intended to highlight a core set of high level service interfaces

needed to support a large number of interoperability use cases in a distributed health information

ecosystem. Lower-level specifications of these services are left to future standards. Moreover,

this SFM provides a basis for vendor extensions and innovation.

The Order Service is a part of an overarching Order Processing pattern describing contracts that

need to be implemented when managing the complex business processes that underlie orders and

observations use cases.

The key functional requirements that the Order Service functional model addresses include the

following:

1. An order service interface decoupled from the requestor (e.g., a CDS system). This

provides a standardized order entry point for placing, monitoring, and managing an order

independent of the actual fulfillment and order-specific workflow associated with the

order.

2. Exposure and standardization of interfaces for bidirectional artifact exchange between

knowledge providers and knowledge consumers. Through the use of catalog services,

systems should be able to exchange resources such as a clinical order catalog and order

sets. The payload for such artifact exchange would ideally also be standardized, thereby

reducing some of today's integration challenges.

3. Workflow discovery and management for order placement and fulfillment. Clinical

workflows vary from system-to-system, organization-to-organization; discovery and

management capabilities allow a caller to adjust accordingly. This functionality consists

of three distinct capabilities: (1) discovery of the workflow itself, (2) discovery of the

status of an item in a particular workflow, and (3) workflow management operations to

complement those offered by the underlying system(s) and workflow(s) being proxied.

4. Monitoring and updating related orders that cut across system boundaries. The Order

Service facilitates the monitoring and updating of orders whose components span across

one or more systems by providing a convenient interface that abstracts variations in

actual configurations and implementations (e.g., the management of a Gentamicin order

based on recent creatinine laboratory results).

The Order Service supports the Order Processing pattern by providing one (1) core and three (3)

optional functionalities exposed using nine (9) interfaces.

All necessary order creation, modification, query and retrieval functionality are provided by a

core ordering capability (Order Service) primarily exposed to clients using an order

management interface. This central functionality also supports a workflow interface through

which a system might update an order’s status, query, retrieve requirements important to

successfully executing an order, and otherwise manage order workflow. Workflow requirements

are critical for more comprehensive management of orders that require the collection of an

intermediary entity that must be analyzed to fulfill the request. We call these Analyzable Entities

– specimens collected for a laboratory order are typical examples. Orders involving analyzable

entities typically include complex behaviors (directing a patient to get their blood drawn) that are

usually managed by verbal direction or convention. The Order Service attempts to manage such



orders more explicitly using the functionality offered by the workflow interface. Related

functionality for monitoring order status and service operations are grouped into an order

monitoring interface and an order service monitoring interface, respectively, for convenience

and clarity. An additional interface, the order notification interface, provides the capability for

an Order Service to notify another Order Service about additions or changes to the orders it

maintains.

The Order Service supports communicating orders, order updates and statuses, and results to

associated fulfillment systems. This behavior is implemented by the fulfillment update interface

and works in concert with each vendor’s fulfillment interface. Together, these interfaces are

responsible for managing bi-directional exchanges between the Order Service and its fulfillers.

Finally, the Service also supports important catalog functions by which orderable items can be

aggregated, organized into collections of related resources, and ultimately exposed as searchable

and updateable lists. Catalogs can be used by users for lookup and to retrieve human readable

information about items, or by machines/services for the purposes of driving application or

business behavior. For example, a catalog of fulfillment services might be used by an inventory

system to discover how to locate possible vendors when determining the best price for a

particular medication. Catalog functionality is exposed in the catalog management and catalog

query interfaces.

The core functionality and interfaces supported by the Order Service are illustrated in the

diagram below and described in more detail in subsequent sections.



Figure 3: Service Description

Order Management Interface: The Order Management interface is the primary

interface used by consumers systems that wish to place and manage orders, or need to

retrieve results relating to previously submitted orders.

Fulfillment Interface: The Fulfillment Interface is a contract for how a general order

service can interact with another system that actually fulfills the order. This interface

supports requests for fulfillment, result retrieval, retrieval of result supplements, and

updating fulfillment specific workflow requirements.

Fulfillment Update Interface: The Fulfillment Update interface provides a service point

for fulfillment systems that wish to push information to the order service. This includes

updating the order status, updating results, providing supplemental result information,

and proposing an alternative order.

Order Workflow Interface: The Order Workflow interface provides the core services

that are required to support order workflow. This interface is geared toward systems that

deal with updating the state / status of an order or with disclosing / managing specific

order requirements.

Order Service Catalog Query Interface: The Order Service Catalog Query interface

provides consumers with visibility into the catalog of items maintained by the Order

service.



Order Service Catalog Management Interface: The Order Service Catalog

Management interface allows callers to perform basic CRUD operations on items in a

catalog.

Order Notification Interface: This interface is used by other order management systems

to provide the Order Service visibility into the status of orders that it is not managing

itself. This interface supports workflow dependencies and federation of order services.

Order Service Monitoring Interface: The Order Service Monitoring interface is used to

review the health of the order service.

Order Monitoring Interface: The Order Monitoring interface is a specialization of the

order management and workflow interfaces to provide a read-only view into the order

service for viewing the state of outstanding orders.

See Section 5.2.1 for a definition of each functional entity.

2.5 Implementation Considerations

Organizations may choose to organize, implement and/or configure these high level services in a

number of ways to meet business-specific needs. Furthermore, product implementers may use as

few or as many of the functions and interfaces defined by the Order Service functional model

depending on the conformance profile selected for implementation (See Section 6). By putting a

common Order Service interface in front of different types of ordering systems, one can support

any number of underlying topologies and implementations while still providing an intuitive and

uniform interface to such services.

The service is intended to operate in a healthcare environment in which one or more fulfillment

systems have also been deployed and where an electronic patient record system is available.

Because the OS is intended to be one module in a larger architecture, any deployment scenario

will necessarily involve other modules.

The Order Service makes no assumptions about implementation architecture behind its service

contract.

2.6 Deployment Scenarios

The Order Service specification is explicitly a functional specification intended to enhance

interoperability; it is not an implementation specification. In addition, there is nothing inherent in

the specification that limits its use to a single organization. The OS can work in multiple

different deployment topologies; consequently, all scenarios herein should be considered non-

normative with regard to conformance to the OS standard. They are offered for explanatory

purposes only – other topologies can be realized on the basis of the OS specification.

For instance, in one scenario an organization may have separate best-of-breed scheduling,

pharmacy and laboratory ordering, and fulfillment systems, whereas in another organization,

these functions may be provided by the same underlying EHR system. In the latter use case, the

coordination of orders across domains (pharmacy, laboratory) or the fulfillment of a composite

order (an order that is made up of related individual orders) is generally provided by the EHR. In

the former use case, the management of cross-system workflows may be required. Both

topologies are supported by the Order Service functional model. Ideally a sequence of clinical



actions such as ordering a lab, scheduling a follow-up appointment, and dispensing a given

medication should be done transparently regardless of the underlying topology. The Order

Service aims to support the orchestration of complex sequences of orders across functions and

systems.

2.6.1 Inter- and Intra-Organizational Deployment Examples

The diagrams that follow highlight a subset of the services with which the Order Service might

interact. Some services may not be illustrated here (e.g., security, authentication, etc.) but are

essential to any deployment.

Figure 4: Simple Deployment Example



Figure 5: Hybrid Deployment Example



Figure 6: Inter-Organizational Deployment



Figure 7: Central Order Service (Inter- or Intra-Deployment Use Case)

deployment Central

This diagram shows the order

service in a central role of

handling all order requests in an

enviroment.

«Fulfi l lment»

Outside

Laboratory

«Fulfi l lment»

Pharmacy

Order Serv ice«interface»

Order Serv ice

«Fulfi l lment»

Inside Laboratory

«interface»

Fulfillment Update

«Fulfi l lment»

Nutrition

«Fulfi l lment»

Radiology

«interface»

Fulfillment

Order Serv ice

Catalog

«interface»

Order Catalog

CPOE System«interface»

Order Workflow

CDS System



Figure 8: Order Service in Federated Configuration

The following diagram illustrates a possible deployment configuration between a CDS

knowledge vendor and one of its customers who uses an EHR system to provide CPOE

capabilities. In this scenario, the health care facility pulls default or customized order sets from

the knowledge vendor system using the Order Catalog Query interface. In an alternative

scenario, the knowledge vendor client might be configured to push order sets and updates

directly using the Order Catalog Management interface. The Order Catalog Query and

Management interfaces support this type of bi-directional flow of information.

deployment Federation

Medical Facility BMedical Facility A

This diagram shows how

order services might be

used in a federated

manner.

Order Serv ice A Order Serv ice B

LaboratoryImaging Pharmacy A Pharmacy B

constraints

{Does not push results}

«interface»

Order Serv ice

«interface»

Order Serv ice

«interface»

Order Notification

«interface»

Order Notification

«interface»

Fullfilment

«interface»

Fulfillment«interface»

Fulfillment Update

«interface»

Fulfillment Update



Figure 9: Bi-directional Catalog Information Flow

class Order Serv ices Catalog

EHR System

«executionEnviro...

CDS Knowledge Vendor


CPOE System


Terminology Catalog

Serv ice

«interface»

Order Catalog Management

«interface»

Order Catalog Query

«interface»

Order Catalog Query

«interface»

Order Catalog Management

E.g., EHR imports order

sets from knowledge

vendor.

E.g., organization exports

orderable items and orderables

to knowledge vendor

CDS Knowledge Vendor pulls order

sets, orderable items, terminology, or

orderables from organization's

'catalog' and pushes order sets to

organization.

Update/Create Catalog

Item (E.g., Order Sets -

Push Model)

Query Catalog Item (E.g.,

Order Sets, Orderables,

Orderable Items - Pull Model)

Query Catalog Item

(e.g., Order Sets - Pull

Model)

Update/Create Catalog Item (E.g.,

orderable, orderable item - push

model)



3 Business Storyboards

The following scenarios illustrate some of the wide-ranging applications of the Order Service to

address a number of important clinical use-cases:

A CDS system may wish to propose orders for a patient based on new information about

this patient. It does so by creating orders in the ‘proposed’ state using the Order Service.

For example, a system that provides extensive drug-drug, drug-allergy, and drug-disease

decision support utilizes the interface to place an unsigned, weight-adjusted Amoxicillin

order for a pediatric patient.

A regional medical center exposes an order interface to allow a trusted community

provider to directly refer a patient for orthopedic consultation. The system provides the

referrer with detailed information regarding requirements that must be satisfied before the

order can be accepted.

A hospitalist orders a consistent carbohydrate, diabetic diet for a patient using a dedicated

nutrition system. The system provides the physician with detailed information regarding

requirements that must be satisfied before the order can be filled (e.g., a hospital policy

requiring a nutritional assessment by a dietician).

A health facility wishes to incorporate evidence-based order sets from a content vendor

into one or more of its systems. A content vendor uses the Order Service Catalog

functionality to upload and maintain the order sets for which the facility contracts. The

facility’s system accesses the vendor content using the Catalog Service to retrieve the

updated artifacts.

A health facility may wish to upload an existing order set from its EHR into an external

CDS content editor in order to update it given recent evidence uncovered in the particular

domain of this order set. The order set is uploaded, modified based on a number of

requirements, and when complete, reimported into the EHR.



4 Assumptions and Dependencies

The Order Service is intended to be a buffer between systems and components attempting to

exchange orders for any number of possible products and services. One assumption about this

scenario is that the items being procured vary tremendously in the metadata required to safely

order them. The Order Service is designed to accommodate this variability and minimize the

complexity exposed to other system components.

Another assumption is that certain Order Service functionality will require the use of other

services, including, but not limited to, an EHR data retrieval service and a mechanism of aligning

data/order semantics. These capabilities might be internal to the systems utilizing the Order

Service, or exposed as SOA components such as HL7 RLUS or a CTS2 compliant vocabulary

service.

A final assumption is that devices and systems that are participants in an ordering event have

unique identifiers, such as MAC or IP addresses, and are pre-configured to conform to the site’s

data security policy. An appropriate security framework for ensuring safe and reliable service

behavior is also a dependency.



5 Detailed Functional Model for Each Interface

5.1 Domain Model

The following diagram provides a comprehensive picture of the Order Service functional model

including core functional and informational entities. Each item in this diagram is described in

greater detail in subsequent sections of the document.

The Order Service defines four (4) core functional entities that implement the nine (9) service

interfaces. These entities organize the core functions of the service into groups of capabilities

related to managing a catalog of resources (including but not limited to an orderable item

catalog, an order set library, etc.), order fulfillment behaviors, and the management of analyzable

entities such as blood or urine specimens.

The diagram also depicts a number of informational entities relevant to this domain. These

concepts include:

Orders (e.g., for a procedure or medication administration)

Order items in an orderable catalog (e.g., a drug ingredient, dispensable, laboratory

procedure)

Promises to fulfill that order

Subjects (generally a patient)

Results of an order (e.g., a laboratory report for a CBC panel)

Requirements that may constrain how the order is fulfilled

Provenance or reason for the order, if needed, for auditing or clinical review purposes

Other supporting classes such as exception conditions that may result when placing an

order



Figure 10: Detailed Domain Model



5.2 Entities

The Service functional model breaks entities into two major groups: functional entities that

exhibit behavior and information entities that contain data. Functional entities refer to a specific

role and are used for modeling. An actual functional entity may do significantly more than is

described by this document. Likewise, information entities also define a minimum set of

concepts and attributes. An implementation model may have significantly more attributes.

5.2.1 Functional Entities

The Order Service consists of four functional entities discussed below.

Order Service (Manager) – Provides the core functionality for managing order creation,

submission, modification, catalog services, access to results, etc. The Order Manager will

typically interact with other services that provide for provider, patient, and orderable item

authentication and access control.

Order Service Catalog – A general catalog of resources (versioned and unversioned) used

by the Order Service. This catalog may consist of a number of sub-catalogs such as the

following:

A catalog providing authoritative listings of potential orderables with their orderable

detail definitions (e.g., a medication orderable and its relevant fields such as dose,

dose unit, route of administration, etc.)

A catalog of individual orderable items such as an individual medication or

dispensable or a laboratory test (e.g., ‘Acetaminophen’, ‘Acetaminophen 100mg

Tab’, ‘CBC Panel’)

A catalog of order sets maintained by the organization

A catalog of order requirements

A catalog of exemplar orders or “prototypes”

Fulfillment Service Registry – An optional component providing authoritative listings of

potential fulfillment services available for adjudicating an order.

Analyzable Entity Management – Provides for management of orders that require the

collection of an intermediary entity such as a specimen that must be analyzed to fulfill the

request. Laboratory tests that require a specimen are typical examples. Radiology exams

where an imaging study must be obtained are another. Unlike items requested from an

inventory, analyzable entity orders typically include complex behaviors, including

workflow orchestration and state management.



Figure 11: Functional Entities



5.2.2 Informational Entities

The Order Service consists of several informational entities described below in greater detail.

Figure 12: Informational Entities



Subject – The entity or entities for which the order was intended to benefit. A subject

may be human, non-human, living, or non-living. For example, the subject may be a

veterinary patient, a group of anonymous individuals (e.g., a community or a herd of

livestock), or a well, whose water must be tested on behalf of a public health agency.

Order – This class represents the request for a service. For instance, it may represent a

request for a laboratory procedure to a fulfillment system.

Order Detail – This class is used to communicate details about an order to support

fulfillment of the order such as routing or security parameters.

Order Item – This consists of the item being ordered (e.g., Amoxicillin 200 mg Tab) and

the clinical parameters for how the order is to be performed (e.g., 2 tablets, thrice daily,

with food).

Rationale – The reason for the given order (e.g., the rationale for the order proposed by a

CDS system) or a reference to the group(s) to which this order belongs. Orders can often

be grouped into collections such as orders that result from the execution of an order set or

as part of clinical guidance returned by a CDS system.

Promise – This class represents the intent of the fulfillment system to perform certain

service(s).

Orderable – A class of concepts that can be ordered which is characterized by a common

set of shared attributes which define any member of that set in the ordering context. For

instance, a medication orderable.

Orderable Details – The collection of relevant attributes shared among all concepts in

this class that one must/may specify when ordering this item. In a typical CPOE system,

the orderable details would correspond to the order entry form and each attribute would

correspond to a field in this form. For certain medications, these may include dose

quantity, route, coded frequency, method of administration, etc.

Orderable Detail Attribute – An orderable attribute definition such as “Dose is a

quantity with a decimal value and units,” “PRN Reason is coded attribute,” etc. Note that

orderables and their attributes are often defined in clinical logical models and/or

templates such as Fast Healthcare Interoperability Resources (FHIR), Child Development

Associate, and Virtual Medical Record.

Orderable Item – The association between a concept that can be ordered from an order

catalog (e.g., Acetaminophen) and its orderable reference (a medication orderable). For

instance, in the case of a medication, it may correspond to an Acetaminophen orderable

that is a type of medication orderable and, as such, includes all the fields defined for

medication orderables. Note that an orderable item is not an order instance (e.g.,

Acetaminophen 200 mg PO TID) but rather a ‘template’ for any number of

Acetaminophen orders. Also note that for medication orderables, an orderable item may

reference either an ingredient (Acetaminophen) or a dispensable (Acetaminophen 100 mg

TAB).



Order Response – The consequence of fulfilling an order is an order response. For

example, in the laboratory domain, an order for a chemistry test will produce a result

document containing the requested data.

Order Set – Collection of orderable items for a condition, disease, or procedure.

Orderable Item Requirement – This class is used to hold metadata regarding orderable

items in a catalog, e.g., requirements for submitting a specific type of order. Another

example is a laboratory collection tube requirement for a specialty test or non-nominal

orders.

Analyzable Entity – An entity that is analyzed as part of an order’s fulfillment.

Analyzable entities may be biological (blood, urine, etc.) or physical (image, EKG,

consultation report, etc.).

Specimen – A material sample obtained from a biological or a physical entity, or the

environment, for the purposes of diagnostic or environmental testing. A specimen is a

common type of analyzable entity.

Fulfillment – Used to communicate the status of the performance of a request.

Reporting Status – This class is used to communicate the business status of the result.

Normal values include preliminary, final, and corrected.

Result – For diagnostics like Laboratory, this class represents the “answer” to the

quantitative or qualitative request.

Result Detail – Contains the specifics of the result, e.g. qualitative and quantitative

measurements.

Requirement – Constraints or preconditions to the acceptance or fulfillment of an order.

Requirements can be about the collection of a specimen, counseling, patient presence or a

requirement procedure/sequence.

Requirement Status – This class is used to capture the state of a requirement (e.g.,

“initial,” “in process” and “met”).



The following diagram illustrates the relationship between an orderable, an orderable item, and

an order.

Figure 13: Order Catalog Entities

5.2.3 Handling Aggregate Data

Many of the operations on this service return collections of data. The data collections can be

grouped into two broad forms: lists/sets and trees. In general such collections can contain either

all members of the collection or a subset of the members with a link to fetch the rest. An example

might be a paged list of results following a search on a web site. Moreover, the operation might

return full instances of data or some summary form with a reference where the full detail

information may be retrieved. An example might be a summarized list of news articles on a news

website. Collections of data represented in tree form may be returned in a ‘lazy’ manner whereby

children dependencies are only fetched when needed. This is typical in drill-down approaches to

hierarchical content – e.g., drilling down a catalog on Amazon.com or lazy loading of

dependencies in an Object Relational Management framework such as Hibernate. The techniques

above ensure that all result sets are reasonable in size and neither overwhelm computing

resources nor result in slower overall performance.

5.2.4 Security and Auditing

As noted in section 2.1, security and auditing are out-of-scope of this documentation and are thus

not explicitly mentioned or listed in the description of the relevant functional specifications.

However, it is important to note that most of the operations described in the following sections

do not exclude these requirements but rather leave them for future technical specifications to

specify.

class orderModel

Orderable

+ E.g., Medication

OrderResponse

+ E.g., Fulfi l lment or dispensation notification

Orderable Item

+ E.g., Amoxicil l in 200 mg Tab

Orderable Detail

- E.g., Dose, Route, Frequency, Urgency, Duration, etc...

Orderable Detail Attribute

+ E.g., Dose :Physical Quantity

Order

Order Item

+ E.g., Amoxicil l in 200 mg Tab - 2 tablets, stat, PO

PromiseOrder Detail

+ Security, Routing, etc...

Requirement

Status

+ E.g., Met

Requirement

+ E.g., Contact if not dispensed

References

0..1

References

1..*

Generates

0..*

Constrains

isCharacterizedBy

0..*

1..*

Instantiate

ConformsTo



5.3 Order Management Interface

The Order Management interface is the primary interface used by consumers systems that wish

to place and manage orders. This interface provides the core services required to initiate and

track orders and retrieve any results relating to the submitted orders.

Figure 14: Order Management Interface

Create Order

Story Board(s)

Create Order with Analyzable Entity (Fulfillment System Collect)

Eve Everywoman, a 27-year-old female, is seen in the outpatient clinic for fatigue. Dr. Primary enters a request to check the iron levels in Eve’s blood into her care system and Eve receives a paper order requisition that serves as an appointment reminder,

provides directions to the collection center, and details preparation instructions for the patient to follow before the test specimen is obtained.

Later that week Eve presents herself at the Laboratory Collection Center. The laboratory looks up and finds the order for her testing in the laboratory system. The appropriate blood samples are extracted, their containers labeled, and the sample information entered

into the information in the laboratory system.

The laboratory performs the analysis on the specimen(s), enters the results into the laboratory system, and sends the results to Dr.

Primary’s care system reported as final.

Create Order with Analyzable Entity (Provider Collect)

Eve Everywoman, having been treated for iron deficiency, returns to Dr. Primary for a repeat iron level. Her provider enters a request to check the iron levels in the care system, which sends the test requests to the Laboratory service. The clinic now employs a

phlebotomist who collects the necessary specimen(s), labels them, packages them and ships them to the laboratory.

The laboratory receives the specimen(s), accessions each, and looks up the order for her testing in the laboratory system. The

laboratory performs the analysis on the specimen(s), enters the results into the laboratory system, and sends the results to Dr.

Primary’s care system reported as final.

Create Order with Analyzable Entity (3rd

Party Collect)

Eve Everywoman’s iron levels are now normal, but she still complains of fatigue. Dr. Primary decides to order some additional specialty tests and requests that a third party collect them.

Later that week Eve calls the 3rd Party collection service for an appointment. The service looks up and finds the order for her testing and then sends a phlebotomist to the patient location. The appropriate blood samples are obtained and brought to the

laboratory service. The laboratory performs the analysis on the specimen(s), enters the results into the laboratory system, and sends

the results to Dr. Primary’s care system reported as final.

Description: Allows a client to create an order of one or more types.

Pre-Conditions

The client has sufficient information to create the request.



Conceptual Information Objects

Inputs

Order

Outputs

Order

Post-Conditions

The returned order structure has been updated with order identifier.

Knowledge of the order is retained by the order service.

Exception Conditions

Ordering Exception

Malformed Order Exception

Unfulfillable Order Exception



Figure 15: Create Order with Analyzable Entity



Figure 16: Create Order without Analyzable Entity

Change Order

Story Board(s)

Dr. Primary reviews Eve Everywoman’s chart at the end of her clinic day making sure her notes are complete. She decides that a manual differential of the requested CBC might be helpful and updates (revises/modifies) the order, which is then communicated to

the laboratory system. The previously received specimen is evaluated as to whether there is an adequate volume to accommodate the

additional tests. There is sufficient specimen, the analysis is performed, and the results are added to the laboratory system.

Description: Allows the client to submit a change to an existing Order

Pre-Conditions

An order exists and the identifier is known.

The order is not completed.


Inputs

Order

Order Identifier



Outputs

Order

Post-Conditions

The order referenced by order identifier has been updated to match the

requirements in the input order.

The modified order is returned.

The change in state of the order may be communicated to fulfillers.


Invalid Order state change (e.g., order has already been completed).

Malformed Order.

Unfulfillable Order.

Notes

Under what conditions a specific order may be changeable is outside the scope of this

specification and is highly dependent of the type of order and what is being fulfilled.

Cancel Order

Story Board(s)

Dr. Primary reviews Eve Everywoman’s chart at the end of her clinic day, making sure her notes are complete. She decides that a previously ordered ferritin level was unnecessary given other recent testing and cancels the order, which is then communicated to

the laboratory system. The previously received specimen had not yet been processed and so the analysis is cancelled.

Description: Allows the client to submit a change to an existing Order

Pre-Conditions



Any fulfillment systems involved in the processing of the order allow the

order to be cancelled.


Inputs

Order

Order Identifier

Outputs

Order

Post-Conditions

The order referenced by order identifier has been cancelled and will not be

acted upon.

The cancel order notification is returned.


Unknown Order.

Order has already been completed.

Order cannot be cancelled



Query Orders

Story Board(s)

Eve’s specialized testing reveals leukemia and she is subsequently hospitalized. The morning following Eve’s admission, Dr. Oncology accesses her medical record before starting her morning rounds and queries the system for all of Eve’s inpatient orders.

The system returns a summary list of laboratory, nutrition and radiology orders, some of which are labeled “complete.”

Description: Used to obtain a list of orders relevant to a specific subject

Pre-Conditions


Inputs

Subject or Query

Outputs

A collection of orders

Post-Conditions


Invalid Query

Invalid Subject

Notes:

At the logical level, additional query criteria (e.g., date ranges, result status, etc.) may

be defined.

Retrieve Order

Story Board(s)

Dr. Oncology accesses Eve’s medical record before starting her morning rounds and queries the system for all of Eve’s inpatient orders. The system returns a summary list of laboratory, nutrition and radiology orders. By selecting each individual order in turn,

Dr. Oncology can retrieve the full order, who requested it, and any order specific instructions that may have been provided.

Description: Allows the client to retrieve a specific order and its full detail, given an

order identifier

Pre-Conditions

The order identifier is known.


Inputs

Order Identifier

Outputs

Order

Post-Conditions


Unknown Order



Retrieve Result

Story Board(s)

Later that day, Dr. Oncology accesses Eve’s medical record and queries the system for all of Eve’s resulted inpatient orders. The system returns a summary list of laboratory, nutrition and radiology orders, some of which are labeled “complete.” By selecting

each individual “complete” order in turn, Dr. Oncology is able to retrieve and review each result report.

Description: Allows a requestor to retrieve a result from the order service using the

result identifier

Pre-Conditions

Results are available either by a direct request to the fulfiller or as the result of

the fulfiller previously sending them to the orders service.


Inputs

Order Identifier

Outputs

Result

Post-Conditions


Unknown Order.

Order does not provide results.

Results not yet available.

Results are currently unavailable.

Retrieve Result Augmentations

Story Board(s)

Eve’s initial testing was positive for leukemia. When Dr. Oncology logs into the EHR to review results, she notes that additional subtyping, as per oncology protocol, had been performed. She uses the system to retrieve the additional results appended to the

original report

Description: Allows a requestor to retrieve supplemental information about a result.

Pre-Conditions

None


Inputs

Order Identifier or Result Identifier

Outputs

Result augmentation(s)

Post-Conditions

None


Result unknown

5.4 Fulfillment Update Interface

The Fulfillment Update interface provides a service point for fulfillment systems that wish to

push information to the order service. This interface is implemented by the order service as a

callback point for fulfillment systems. This includes updating the order status, updating results,

providing supplemental result information, and proposing an alternative order.



Figure 17: Fulfillment Update Class

Update Order Status

Story Board(s)

The radiology tech takes Eve’s admission chest x-ray. He accessions the film into the hospital PACS system, which then

communicates with the ordering system to update the order status to “Complete.”

Description: Allows the fulfillment system to communicate a change in order state

(e.g., unsigned, active, reserved, on hold, refused, complete) back to the ordering

system

Pre-Conditions


The fulfillment system making the request is associated with this order.


Input

Order Id

Status

Output

Success/Fail

Post-Conditions

Order status updated on the order server.

Changes of status may cause workflow related behavior on the order service.


Fulfillment service not associated with this order

Unknown Order

Update Result Status

Story Board(s)

The radiologist completes her review and interpretation of Eve’s admission chest x-ray. She enters the result into the hospital PACS

system, which then communicates with the ordering system to update the order result status to “Final.”

Description: Allows the fulfillment system to communicate an updated result status

back to the ordering system

Pre-Conditions

An order result exists and the identifier is known.


Input

Order Id



Result Id

Status

Output

Success/Fail

Post-Conditions

Change noted on order service.



Unknown Order

Update Result

Story Board(s)

While Dr. Oncology is writing other orders for Eve’s leukemia treatment, she notices that Eve’s admission chest x-ray was recently resulted and that the interpretation is final. She selects the order in question and requests the radiology result. The PACS system

then communicates with the ordering system to provide the final report.

Description: Allows the fulfillment system to send the entire result to the Order

Service

Pre-Conditions



Input

Order Id

Result Id

Result

Output

Success/Fail

Post-Conditions

None



Unknown Order

Propose Order Replacement

Story Board(s)

One of Eve's admission orders is for a medication that becomes temporarily out of stock before it can be dispensed. The pharmacy

system provides a recommendation for a substitute that is similar and is currently available. The fulfillment system returns this

recommendation to the ordering service, which then forwards the suggestion to the provider.

Description: Allows the fulfillment system to propose an alternate order to the Order

Service. This proposal may occur after the order has been accepted by the fulfillment

system as a result of changes in the fulfillment environment that may have occurred

after that time. A fulfillment system may also suggest a more appropriate order prior

to accepting the original order so as to refine it per organizational policy or due to

evidence-based knowledge protocols.



Pre-Conditions

None


Input

Order Id

Proposed Replacement Order

Output

Proposal is accepted for review (True/False)

Post-Conditions

None



Unknown Order

Submit Result Augmentation

Story Board(s)

Another of Eve’s admission orders is for a specialty tumor marker that is subsequently positive. As part of its standard operating procedure, the laboratory conducts several additional tests on the original specimen, both to validate the initial results and to

subtype the leukemia. These additional tests are resulted 36 hours later and appended to the original tumor marker screen.

Description: Allows the fulfillment system to send supplemental result information

to the Order Service

Pre-Conditions



Input

Order Id

Result Id

Result Augmentation

Output

Success/Fail

Post-Conditions

None



Unknown Order

5.5 Fulfillment Interface (Implemented By Fulfillment System)

The Fulfillment Interface is a contract for how a general order service can interact with another

system that actually fulfills the order. This interface may be implemented by systems that wish to

plug into a generalized order service. A generalized order service uses this interface as the

primary means of interacting with a fulfillment service. This interface supports requests for

fulfillment, result retrieval, retrieval of result supplements, and updating fulfillment specific

workflow requirements.



Figure 18: Fulfillment Class

Request Fulfillment

Story Board(s)

Prior to Eve’s hospitalization, Dr. Oncology writes a number of pre-admission orders for Eve, including a bone scan. Upon

completing the order, the PACS system is informed.

Description: Allows the order service to place an order and receive a promise from

the fulfillment system

Pre-Conditions

None


Inputs

Order

Outputs

Promise

Fulfillment specific requirements

Promise Status

Post-Conditions

Order and promise associated

Fulfillment of the order may be suspended pending fulfillment specific

requirements.


Order not supported by this service

Order is malformed

Notes

The specific details about what occurs in the fulfillment of an order are out scope

except as it relates to the operational behavior of the order service.

Cancel Order

Story Board(s)

While Dr. Oncology is writing other orders for Eve’s leukemia treatment, she notices that Eve has a duplicate order for her

admission bone scan. Dr. Oncology selects the duplicate order and cancels it. The PACS system is subsequently notified and the

order is cancelled.

Description: Allows the order service to communicate to the fulfillment system that a

previously requested, and not yet completed, order should not be performed



Pre-Conditions



The requester is the originator of the order.

The fulfillment service supports the cancellation operation.


Inputs

Order

Order Identifier

Outputs

Order

Success/Fail

Post-Conditions

The order referenced by order identifier has been cancelled and will not be

acted upon.

The cancelled order is returned.


Order is not known to the fulfiller.

Order cannot be cancelled.

Order has already been completed.

Note

Depending on local practice, there may be other conditions that prevent cancelation

of an order – in some labs, once a specimen is accessioned, the test can’t be canceled,

as the laboratory may need to be able to bill for it.

Retrieve Result

Story Board(s)

While Dr. Oncology is finishing other orders for Eve’s leukemia treatment, she notices that Eve’s admission chest x-ray was recently resulted and that the interpretation is final. She selects the order in question and requests the radiology result. The ordering system

then communicates with the PACS system to retrieve the final result report.

Description: Allows the order service to retrieve one or more results from the

fulfillment system using a result identifier or the promise identifier.

Pre-Conditions

None


Inputs

Result Identifier(s) or Promise Identifier

Outputs

Result(s)

Post-Conditions

None


Result unknown

Promise unknown



Get Result Augmentations

Story Board(s)

Eve’s initial testing was positive for leukemia. When Dr. Oncology logs into the EHR to review results, she notes that additional subtyping, as per oncology protocol, had been performed. She uses the system to retrieve the additional results appended to the

original report.

Description: Allows the order service to retrieve supplemental information about a

result from a fulfillment system.

Pre-Conditions

None


Inputs

Result Identifier

Outputs

Result augmentation(s)

Post-Conditions

None


Result unknown

Update Order Requirements

Story Board(s)

Dr. Oncology is the Attending Physician for an oncology team that recently began including interns and residents for the first time

on rounds and in-patient care activities. Given the criticality of chemotherapy orders, the fulfillment updates oncology order requirements to indicate that an attending physician endorsement/co-signature is needed for all house staff orders. The system will

accept a resident's order but won’t actually fulfill it until the required endorsement is obtained.

Description: Allows the order service to update the requirements of an order that has

been submitted for fulfillment. This update to requirements is used to provide

supplemental workflow steps that may be required by the fulfillment system.

Pre-Conditions

None


Inputs

Order Id

Outputs

Requirement(s)

Post-Conditions

None


Unknown Order

Verify Order Requirements

Story Board(s)

Later that night, Dr. Oncology reviews the intern’s chemotherapy orders and co-signs them. The system verifies that his signature is satisfactory and that all fulfillment requirements have been satisfied. Dr. Oncology is told his signature was accepted and that the

orders were being processed.

Description: Allows the order service to validate the requirements of an order with a

fulfillment system



Pre-Conditions

None


Inputs

Order Id

Requirements

Ignore Unknown requirements (True/False)

Outputs

Valid (True/False)

Validation message

Post-Conditions


Unknown Requirement

Unknown Order

5.6 Order Workflow Interface

The Order Workflow interface provides the core services that are required to address order

workflow. This interface is geared toward systems that deal with updating the state and status of

an order. In many ways, this interface is a specialization and extension of the Order

Management Interface. This specialization is one of perspective, which is often reflected in

different information requirements for invoking the same operation found in the Order

Management Interface. As a result, a number of the operations in this interface duplicate those

found in Order Management. In this case an order is discovered and specific requirements that

are necessary are updated.

Figure 19: Order Workflow Class



The following is an example of how the Workflow interface might be used.

Figure 20: Workflow Example



Query Orders

Story Board(s)

The pharmacy fulfillment system requests a list of new inpatient orders by ward and priority, cross-indexed by patient and then

ordering provider.

Description: Used to obtain a list of Orders relevant to a specific Subject

Pre-Conditions


Inputs

Subject or Query

Outputs


Post-Conditions


Invalid Query

Invalid Subject

Notes


be defined.

Retrieve Order

Story Board(s)

Later that day, Dr. Oncology accesses Eve’s medical record and queries the system for all of Eve’s resulted inpatient orders. The system returns a summary list of laboratory, nutrition and radiology orders, some of which are labeled “complete.” By selecting

each individual “complete” order in turn, Dr. Oncology is able to retrieve and review each result report.

Description: Allows the client to retrieve a specific order and its full detail, given an

order identifier

Pre-Conditions



Inputs

Order Identifier

Outputs

Order

Post-Conditions


Unknown Order

Change Order

Story Board(s)

While reviewing Eve’s new inpatient orders, the pharmacist determines that a particular drug in her chemotherapy regimen needs a dose adjustment. He uses a pharmacokinetics calculator to adjust the dose and interval to accommodate the patient’s renal status.

The calculator submits the changes to the ordering system to update the existing order.

Description: Allows the client to submit a change to an existing order

Pre-Conditions






Inputs

Order

Order Identifier

Outputs

Order

Post-Conditions

The order referenced by order identifier has been updated to match the

requirements in the input order.

The modified order is returned.

The change in state of the order may be communicated to fulfillers.


Order state change exception (e.g., order has already been completed)

Ordering Exception

Malformed Order Exception

Unfulfillable Order Exception

Notes

Under what conditions a specific order may be changeable is outside the scope of this

specification and is highly dependent of the type of order and what is being fulfilled.

Update Order Status

Story Board(s)

After each pharmacy order has been reviewed, authorized and filled, the pharmacy ordering system then communicates with the

ordering system to update the order status to “Filled.”

Description: Allows the fulfillment system to communicate a change in state of the

order (e.g., unsigned, active, reserved, on hold, refused, complete)

Pre-Conditions




Inputs

Order

Order Identifier

Outputs

Success

Post-Conditions

None




Unknown Order

Invalid state change

Query Order Requirements

Story Board(s)

Dr. Oncology wishes to obtain an additional, rarely ordered immunoassay. She queries the order system and determines that the

test needs to be collected in green top tubes and delivered to the lab on ice within 30min of being drawn.

Description: Provides consumer the ability to find what requirements an order has for

fulfillment and what their current status is. This information might include such

things as the order catalog, order service configuration, and requirements asserted by

fulfillment systems.

Object Model

Figure 21: Query Order Requirements

Pre-Conditions

None


Inputs

Order Identifier

Outputs

Collection of requirements with details

Post-Conditions

None


Order is not known to the System.



Update Order Requirements

Story Board(s)

Upon retrieving a particular drug’s requirements, the pharmacy system validates that prerequisites have been satisfied and notifies the ordering system which have been satisfied and which remain. In Eve’s case, the requirement for volume loading has still not

been addressed and her chemotherapy has consequently not been started.

Description: Allows the Order Service to be updated when requirements for a given

order are updated (e.g., status updates, addition and removal of requirements

associated with an order).

Pre-Conditions

None


Inputs

Order Identifier

Outputs

Collection of requirements

Post-Conditions

Varies depending upon the specifics order and its related workflow and

requirements.


Order is not known to the System.

Get Order Workflow

Story Board(s)

Not being very familiar with the new co-signature requirement, Dr. Oncology uses the CPOE system to query the Order Service and retrieve the workflow requirements for the chemotherapy orders he just co-signed. He learns that he has to endorse intern and

resident chemotherapy orders, but that fellow orders do not. He also verifies that the orders had indeed been accepted and were

being processed.

Description: Allows a consumer of the order service to examine the workflow model

and state of the order.

Pre-Conditions

None


Inputs

Order Id

Outputs

Workflow Model

Post-Conditions


Unknown Requirement

Unknown Order

Notes

The Workflow Model is not in scope for this specification.



Verify Order Requirements

Story Board(s)

Later that night, Dr. Oncology reviews the intern’s chemotherapy orders and co-signs them. The system verifies that his signature is

satisfactory and that all fulfillment requirements have been satisfied. Dr. Oncology is told his signature was accepted.

Description: Allows a consumer of order service to validate the requirements of an

order.

Pre-Conditions

None


Inputs

Order Id

Requirements

Ignore Unknown requirements (True/False)

Outputs

Valid (True/False)

Validation message

Post-Conditions

None


Unknown Requirement

Unknown Order.

Notes

Depending on the nature of the requirement, the fulfillment service(s) involved in this

order may also be consulted.

5.7 Order Service Catalog Query Interface

The Order Catalog Query interface provides consumers with visibility into the catalog of items

maintained by the Order service.

Figure 22: Order Service Catalog Query Interface

Query Catalog Item Types

This operation retrieves a list of catalog item types maintained by this catalog service. Catalog

item types may include orderables, orderable items, order sets, etc.

Story Board(s)



Dr. Hospitalist is writing inpatient orders for Dave Everyman. A new employee at the hospital, Dr. Hospitalist is unsure what types of orders the CPOE system can handle. He logs in and queries the system and is pleased to discover the system allows him to order

lab, radiology, nursing, nutrition and medication items.

Description: Orderer can query for types of orderable entities.

Pre-Conditions

None


Input

A valid query statement

Output:

A collection of catalog item types

Post-Conditions

None


Invalid Catalog Request

Query Catalog Items

Story Board(s)

Dr. Hospitalist, interested in nutrition orders, queries the CPOE system to obtain a list of different dietary sub-categories including oral diets, enteral, and parenteral nutrition. Further selecting solid diets, Dr. Hospitalist receives a searchable list of orderable

items.

Description: User can navigate/query an order catalog and locate orderable items.

Pre-Conditions

None


Input

A valid query

Output:

Collection of catalog items

Post-Conditions

None


None

Get Catalog Item Detail

Story Board(s)

Dr. Hospitalist selects a reduced calorie, low carbohydrate diet from the order catalog. He receives a brief description of the types

of items available in the diet and some examples of when the diet is clinically appropriate.

Description: User can retrieve details about orderable items in the catalog.

Pre-Conditions

None


Input

The identifier of the catalog item

Output

The catalog item



Post-Conditions

None


Catalog Item Does Not Exist.

Get Catalog Item Prototype

This method returns the Catalog Item Prototype for the given prototype identifier. A Catalog

Item Prototype represents an example instance for a type of catalog resource. For instance, it

might consist of an example order item for Metoprolol.

Story Board(s)

Dr. Hospitalist selects an appropriate diet and requests an order prototype. The order catalog returns a representative order for the

diet in question, annotated clearly to indicate available options and how the order is best completed.

Description: User can retrieve a prototypical example of a completed order.

Pre-Conditions

None


Input

Catalog Item Prototype identifier or Catalog Item Type

Output

Catalog Item Prototype

Post-Conditions

None



5.8 Order Service Catalog Management Interface

The Order Service Catalog Management interface allows callers to perform basic CRUD

operations on items in a catalog. Note that catalog items include collections of other items in the

catalog. For instance, a catalog may contain both terms and value sets that represent a collection

of terms used on order entry forms.

Figure 23: Order Service Catalog Management Class



Get Catalog Item

Story Board(s)

A CDS knowledge integrator wishes to retrieve all publishable order sets from a CDS content provider to import into his facility’s

EHR system. He then selects the desired order set for import into the system.

Description: Allows a caller to retrieve an item by identifier from a catalog

Pre-Conditions

None


Input

A valid catalog item identifier

Output

A catalog item

Post-Conditions

None



Update Catalog Item

Story Board(s)

A hospital’s terminologist wishes to update a frequency term’s display name in the CDS content provider system to make the term

available to order set authors.

Description: Allows a caller to update a catalog item

Pre-Conditions

None


Input

A valid Catalog Item

Post-Conditions

None


Catalog Item Does Not Exist

Delete Catalog Item

Story Board(s)

The hospital’s terminologist enters a term in error and wishes to delete it from the catalog.

Description: Allows a caller to delete a catalog item

Pre-Conditions

None


Input

A valid Catalog Item identifier

Post-Conditions

None


Catalog Item Does Not Exist



Notes

A delete removes a resource entirely from the catalog. To inactivate a resource, use

Update Catalog Item to update its status to, say, ‘Archived’ or ‘Inactive.’

Create Catalog Item

Story Board(s)

A hospital CDS knowledge integrator wishes to import a new order set from one system to another. He selects the order set from the

first system and then adds it to the other system.

Description: Allows a caller to add a new resource into the catalog

Pre-Conditions

None


Input

A valid Catalog Item

Post-Conditions

None


Invalid Format

5.9 Order Notification Interface

Figure 24: Order Notification Class

The order notification interface is used by other order handling systems to provide visibility to

the order service of orders that it is not managing. This interface is provided to support workflow

dependencies and federation of order services.

Notify of Order

Story Board(s)

An order service installed in a heterogeneous operating environment and existing CPOE systems are configured to notify the order

service of new orders.

Description: Informs the order service of an order that is being managed elsewhere.

Pre-Conditions

Called is authorized to notify the order service of orders.


Input

Order

Remote Order Identity



Remote Service Identity

Output

Local Order Identity (optional – see notes)

Post-Conditions

Remote Order and Identity mapping may be retained.


Not authorized

Notes

If the order service wishes further updates relating to this order, it should return a

local order identity that can be used for future updates.

Notify Order Updated

Story Board(s) An order service installed in a heterogeneous operating environment and order updated by a CPOE system and a notification of the

updated order is sent to the order service.

Description: Informs the order service of updates to an Order that is being managed

elsewhere

Pre-Conditions

The order service has already been notified of this order.

The order service has issued a local identifier for the order.


Input

Order

Local Order Identity


Output

Success (True/False)

Post-Conditions

Local state of the order is updated


Not Authorized

Order Unknown

Notify Order Retracted

Story Board(s)

An order service installed in a heterogeneous operating environment and has been notified of an order. This order is then cancelled

in the originating systems and a retraction is sent to order service.

Description: Invalidates an order that was previously registered

Pre-Conditions

The order service has already been notified of this order.

The order service has issued a local identifier for the order.


Input

Order

Local Order Identity




Output

Success (True/False)

Post-Conditions

Local state of the order is updated


Not Authorized

Order Unknown

5.10 Order Monitoring Interface

Figure 25: Order Monitoring Interface

The order monitoring interface is a specialization of the order management and workflow

interfaces to provide a read-only view into the order service for viewing the state of outstanding

orders.

Query Pending Orders

Story Board(s)

On the day that Eve is to be discharged, Dr. Oncology logs into the hospital EMR and checks to see if all her discharge orders have

been processed.

Description: Used to obtain a list of Orders that are still are not complete.

Pre-Conditions


Inputs

Query

Outputs


Post-Conditions


Invalid Query.

Notes:


be defined.



Retrieve Order

Story Board(s)

One of Eve’s discharge orders is still pending, delaying her departure. Dr. Oncology selects the pending order and examines the full

order to determine what the holdup might be.

Description: Allows the client to retrieve a specific Order and its full detail, given an

Order Identifier

Pre-Conditions



Inputs

Order Identifier

Outputs

Order

Post-Conditions


Unknown Order

Retrieve Result

Story Board(s)

The pending order indicated that the order result needed pathology review before being certified. Dr. Oncology retrieves the result, makes note that the result while abnormal for an average patient was appropriate for a leukemic. He calls the front desk and tells

Eve’s nurse that she was cleared for discharge.

Description: Allows a requestor to retrieve a result from the order service using the

result identifier

Pre-Conditions

Results are available either by a direct request to the fulfiller or as the result of

the fulfiller previously sending them to the orders service.


Inputs

Order Identifier

Outputs

Result

Post-Conditions


Unknown Order

Order does not provide results.

Retrieve Order Workflow

Story Board(s)

Not being very familiar when pathology reviews are required, Dr. Oncology uses the CPOE system to query the order service and retrieve the workflow requirements for the pending order. He learns that most laboratory tests are based on adult male norms and

that rarely are accommodations made for the female gender or specific diseases.

Description: Allows a consumer of order service to examine the workflow model and

state of the order.

Pre-Conditions



None


Inputs

Order Id

Outputs

Workflow Model

Post-Conditions


Unknown Requirement

Unknown Order

Notes

The Workflow Model is not in scope for this specification

5.11 Order Service Monitoring Interface

Figure 26: Order Service Monitoring Interface

The order service monitoring interface is used to review the health of the order service.

Get Server Status

Story Board(s)

A fulfillment service is having difficulty communicating with the hospital order service. It queries the service and learns that the

fulfillment update service is temporarily down for maintenance.

Description: Retrieves the status of the order service

Pre-Conditions

None


Input

Output

Service Status

Post-Conditions

None


Not authorized



Get Fulfillment Statistics

Story Board(s)

The hospital pharmacy queries the service to learn how many medication orders have been fulfilled in the past month.

Description: Fetches fulfillment related statistics

Pre-Conditions

None


Input

Fulfillment Type(s)

Output

Collection of statistics

Post-Conditions

None


Not Authorized

Get Service Statistics

Story Board(s)

The hospital IT staff queries the service to discovery how many transactions have been completed, how long the service had been

operational since the last maintenance period, and what the average response latency has been.

Description: Gets general statistics relating to the order service as a whole

Pre-Conditions

None


Input

Output

Statistics

Post-Conditions

None


Not Authorized

Get Fulfillment Information

Story Board(s)

The hospital EMR queries the service to learn what fulfillment systems are accessible.

Description: Get information about what fulfillment types as supported by the order

service and related operational information

Pre-Conditions

None


Input

Output

Fulfillment Information

Post-Conditions

None




Not Authorized

Order Unknown

5.12 Example Event Flows

Create Order Event Flow

Create Order allows the client to create an order for a service or product. The following diagram

depicts the event flow for orders that require an analyzable entity to be obtained.

Figure 27: Create Order Flow – Analyzable Entry Required



The following diagram depicts the event flow for orders that do not require an analyzable entity

to be obtained.

Figure 28: Create Order Flow – Analyzable Entry Not Required



Change Order Event Flow

Allows the client to submit a change to an existing order.

Figure 29: Change Order Event Flow



Cancel Order Event Flow

Used when a requestor (placer) would like for a previously requested, and not yet completed,

order not to be performed. Note that there are many steps in the fulfillment process where an

order might appropriately be cancelled, either during or after the order itself has been processed.

These are considered out-of-scope for this specification and are not described in the diagram

below.

Figure 30: Cancel Order Event Flow



Catalog Event Flow

Figure 31: Catalog Event Flow



6 Profiles

6.1 Introduction

A set of conformance profiles are defined that cover specific functions, semantic information and

overall conformance.

6.2 Conformance Profiles

Profile Interfaces Requirement

Core Ordering Implements Order Management Interface Yes

Pluggable Fulfillment Implements the Order Management Interface Yes

Implements the configuration of fulfillment systems callable by the Fulfillment Interface

Yes

Calls pluggable fulfillment implementations using the Fulfillment interface Yes

Implements other interfaces Recommended

Order Catalog Implements the Order Management Interface Yes

Implements the Order Catalog Interfaces Yes


Workflow support Implements the Order Management Interface Yes

Implements the Order Workflow Interface Yes

Defers order fulfillment until requirements are met Yes


Fulfillment request push Implements the Order Implements Management Interface Yes

Fulfills the requirements for pluggable fulfillment Yes

Implements the Fulfillment Update Interface Yes

Preserves updates from the Fulfillment Update Interfaces Yes

May implement other interfaces Recommended



7 Recommendations for Technical RFP Issuance

There should be no impact to this service for internationalization because the service deals in

strings of data that do not need to have any other semantic or syntactic characteristics other than

those specified by the site. The service itself is not designed to discriminate for or against any

particular language. Any required multi-language functionality is assumed to be implemented

with the system.



Appendix A – Relevant Standards

HL7

FHIR Order Resource

FHIR Order Response Resource

Order Request Manager

Composite Order

Nutritional Orders

Laboratory Orders Domain Analysis Model

http://hl7.org/implement/standards/fhir/order.htm

http://hl7.org/implement/standards/fhir/orderresponse.htm

http://wiki.hl7.org/index.php?title=Order_Request_Manager_Conceptual_Specification

http://wiki.hl7.org/index.php?title=Composite_Order_Conceptual_Spec

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=289

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=331



Appendix B – Glossary

There are a number of acronyms used in this document, and in standards or other documents

related to this specification. The following is a brief list of what the most common ones stand

for:

Acronym Full Name

ANSI American National Standards Institute (U.S.A.)

BF Behavioral Framework

CDS Clinical Decision Support

CPOE Computerized Provider Order Entry

DRG Data requirement group

DRI Data requirement item

DSS Decision Support Service

FHIR Fast Healthcare Interoperability Resources

HL7 Health Level Seven

HSSP Healthcare Services Specification Project

IHE Integrating the Healthcare Enterprise

ISO International Organization for Standardization

KM Knowledge Module

OMG Object Management Group

OS Order Service

PIM Platform Independent Model

PSM Platform Specific Model

RFP Requests for Proposals

RIM Reference Information Model defined by HL7

RLUS Retrieve, Locate, and Update Service

RM-ODP Reference Model of Open Distributed Processing

SAIF Services-Aware Interoperability Framework

SFM Service Functional Model

SOA Service Oriented Architecture

STM Service Technical Model

TC Technical Committee

UML Unified Modeling Language



Appendix C – Relationship to Information Content

The following principles shall be followed for specifying the information model to be used by

the services being specified in this Service Functional Model:

SFMs shall provide a conformance profile supporting HL7 content where relevant.

We shall not preclude the use of non-HL7 content.

SFMs will reuse to the maximum extent possible the content models as defined in other

standards (for example, HL7 RMIMs).

Information content representations shall be represented in platform-agnostic formalisms

(e.g., UML).

SFMs may identify content at varying levels of granularity, depending upon the functions

being specified. (For example, the Common Terminology Service will deal with different

granularity of information than the Resource Location and Update Service).

Conformance Profiles may be balloted or adopted after the release of the initial SFM to

address specialized business needs (e.g., realm-specific profiles, domain-specific profiles,

etc.).

Details about semantics specific to this SFM appear in other sections of this document.

Draft Standard for Trial Use · 2018-10-24 · This draft standard is not an accredited American...

Documents

Transcript of Draft Standard for Trial Use · 2018-10-24 · This draft standard is not an accredited American...