V3_SPEC_ORDERSRVINT_R1_D1_2014SEP
HL7 Version 3 Specification: Ordering Service Interface,
Release 1
September 2014
HL7 DSTU Ballot
Sponsored by:
Orders and Observations Working Group HL7
Clinical Decision Support Working Group HL7
Copyright © 2013 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 and Health Level Seven are registered trademarks of Health Level
Seven International. Reg. U.S. Pat & TM Off.
Use of this material is governed by HL7's IP Compliance Policy.
Page 2
HL7 Version 3 Specification: Unified Communication Service Interface, Release 1 - US Realm
© 2013 Health Level Seven International. All rights reserved.
January 2014
Project Lead
Emory Fry, MD
Editor
Alfred Bustamante
Authors
Emory Fry, MD
Jerry Goodnough
Claude Nanjo
Edited By
Edited On
Change
Jerry Goodnough
4/30/2014
Deployment diagrams added.
Claude Nanjo
7/1/2014
Finalized review draft
Page 3
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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
Page 4
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 5
© 2013 Health Level Seven International. All rights reserved.
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.
Page 6
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Table of Contents
1
Overview .................................................................................................................................... 9
1.1
Introduction and Scope ....................................................................................................... 9
1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP) ............................................... 9
1.1.2 Service Definition Principles ..............................................................................................10
2
1.2
Overall disclaimers ............................................................................................................11
1.3
Readers Guide ...................................................................................................................11
Executive Summary..................................................................................................................11
2.1
Service Overview ...............................................................................................................11
2.1.1 Service Description and Purpose .......................................................................................11
2.1.2 Scope13
2.2
The Reason Why the Service Is Necessary ........................................................................14
2.3
Context of this SFM within the HSSP Roadmap ................................................................16
2.4
Structure of the Service .....................................................................................................17
2.5
Implementation Considerations........................................................................................20
2.6
Deployment Scenarios.......................................................................................................20
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 .........................................................................27
5.1
Domain Model ...................................................................................................................27
5.2
Entities ...............................................................................................................................30
5.2.1 Functional Entities .............................................................................................................30
5.2.2 Informational Entities ........................................................................................................31
5.2.3 Handling Aggregate Data...................................................................................................35
5.3
Order Management Interface ...........................................................................................35
5.4
Fulfillment Update Interface .............................................................................................43
5.5
Fulfillment Interface (Implemented By Fulfillment System) .............................................46
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 7
© 2013 Health Level Seven International. All rights reserved.
5.6
Order Workflow Interface .................................................................................................49
5.7
Order Service Catalog Query Interface .............................................................................56
5.8
Order Service Catalog Management Interface ..................................................................58
5.9
Order Notification Interface ..............................................................................................60
5.10 Order Monitoring Interface ...............................................................................................62
5.11 Order Service Monitoring Interface ..................................................................................64
5.12 Example Event Flows .........................................................................................................66
6
Profiles .....................................................................................................................................70
6.1
Introduction.......................................................................................................................70
7
Recommendations for Technical RFP Issuance........................................................................72
8
Appendix A - Relevant Standards.............................................................................................73
9
Appendix B - Glossary ..............................................................................................................74
10 Appendix C - HL7 EHR Functional Model Traceability .............................................................75
11 Appendix D - Relationship to Information Content .................................................................76
Page 8
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 Service Functional Model (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 SIG in collaboration with other HL7
committees, which currently include the Vocabulary TC and the Clinical Decision Support 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
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 9
© 2013 Health Level Seven International. All rights reserved.
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
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.
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.
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.
Page 10
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 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
2.1.1
Service Overview
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 clinical decision support
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
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 11
© 2013 Health Level Seven International. All rights reserved.
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 a common service
set providing definition to what an orderable item is, 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 lab on ice within
30min 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 Catalog. While ordering is typically constrained by the
systems found within a single organization, one can easily imagine a time when an increasingly
Page 12
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
distributed and competitive network of suppliers vie to provide fulfillment services. The Order
Service Catalog functionality provides a specification of how orderable items of many types
might be listed, exposed, and utilized to great effect within the ordering workflow.
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 IHE Laboratory Clinical Communications profile, which defines the
information models required to support automated communications between a Laboratory
Information System and it “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 metamodel cleanly separating essential concerns, prerequisites, and workflow. The advantages for
care coordination, process management, and clinical decision support afforded by having a
common set of standardized service interfaces are significant.
2.1.2
Scope
The Order Service is intended to complement existing 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
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 13
© 2013 Health Level Seven International. All rights reserved.
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.
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. Such functionality, while
important to managing clinical workflow and care transitions, will be addressed in future
iterations of this functional model.
Finally, 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 setting order
state 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.
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 systems and other applications that expose ordering
functionality to individuals are obvious beneficiaries, workflow automation and clinical decision
support services are also ideal candidates for leveraging Order Service capabilities. A 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 avoidable 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
Page 14
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 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 Service Oriented Architecture (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.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 15
© 2013 Health Level Seven International. All rights reserved.
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 Service Functional
Model 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, analyses 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 RLUS service, 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.
Page 16
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 2: Prototypic use of Order Service within an organization’s SOA.
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 fulfillment 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 the Order Service Functional Model addresses include:
1. An order service interface decoupled from the requestor (e.g., a clinical decision support
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
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 17
© 2013 Health Level Seven International. All rights reserved.
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. For example, the management of a
Gentamicin order based on recent creatinine lab results.
The Order Service supports the fulfillment 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 and 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 status, 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 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.
Page 18
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 3: Service Description
Figure 4: Functional Entities
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 19
© 2013 Health Level Seven International. All rights reserved.
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. 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 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 that the Order Service might interact
with. Some services not be illustrated here (e.g., security, authentication, etc.…) but are
essential to any deployment.
Page 20
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 5: Simple Deployment Example
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 21
© 2013 Health Level Seven International. All rights reserved.
Figure 6: Hybrid Deployment Example
Page 22
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 7: Inter-Organizational Deployment
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 23
© 2013 Health Level Seven International. All rights reserved.
Figure 8: Central Order Service (Inter- or Intra-Deployment Use Case)
Page 24
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 9: 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.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 25
© 2013 Health Level Seven International. All rights reserved.
class Order Serv ices Catalog
«executionEnviro...
CDS Know ledge Vendor
«interface»
Order Catalog Query
«interface»
Order Catalog Management
Query Catalog Item (E.g.,
Order Sets, Orderables,
Orderable Items - Pull Model)
Query Catalog Item
(e.g., Order Sets - Pull
Model)
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)
Update/Create Catalog Item (E.g.,
orderable, orderable item - push
model)
«interface»
Order Catalog Management
«interface»
Order Catalog Query
EHR System
«executionEnviro...
CPOE System
«executionEnviro...
Terminology Catalog
Serv ice
E.g., EHR imports order
sets from knowledge
vendor.
E.g., organization exports
orderable items and orderables
to knowledge vendor
Figure 10: Bi-directional Catalog Information Flow
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 clinical decision support 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 a unsigned, weightadjusted, 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 low-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, for example, a hospital
policy requiring a nutritional assessment by a dietician.
Page 26
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 the facility contracts for. 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. 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.
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),
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 27
© 2013 Health Level Seven International. All rights reserved.
Page 28
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.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 11: Detailed Domain Model
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 29
© 2013 Health Level Seven International. All rights reserved.
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
o
A catalog providing authoritative listings of potential orderable with their
orderable detail definitions (e.g., a medication orderable and its relevant fields
such as dose, dose unit, route of administration, etc.).
o
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’).
o
A catalog of order sets maintained by the organization.
o
A catalog of order requirements.
o
A catalog of exemplar orders or “prototypes”.
Fulfillment Service Catalog – An optional component providing authoritative listings of
potential fulfillment services available for adjudicating an order. An Order Fulfillment
Service represents a series of components dealing with the management of orders and
the promises associated with them. Each Order Fulfillment Service contract creates
distinct boundaries between ownership of orders and ownership of promises for
fulfillment.
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.
Page 30
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 12: Functional Entities
5.2.2
Informational Entities
The Order Service consists of several informational entities described below in greater detail.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 31
© 2013 Health Level Seven International. All rights reserved.
Figure 13: Informational Entities
Page 32
Subject – The patient for whom the order was written. This includes identifying
information such as name, birth date, identifier, gender, etc.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 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).
Provenance – The reason for the given order (e.g., the rationale for the order proposed
by a clinical decision support system) or a reference to the group(s) to which this order
belongs. Orders can often be grouped into collections of orders such as orders that
result from the execution of an order set or as part of clinical guidance returned by a
clinical decision support system. The order provenance attribute links a given order to
one or more of these collections.
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
FHIR, CDA, and vMR.
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.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 33
© 2013 Health Level Seven International. All rights reserved.
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, for example, requirements for submitting a specific type of order. For
example, 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 – The result details, 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/state of a requirement, e.g.
“initial”, “in process”, “met”.
The following diagram illustrates the relationship between an orderable, an orderable item,
and an order.
Page 34
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
class orderModel
Orderable Detail
Orderable
+
isCharacterizedBy
-
Orderable Detail Attribute
E.g., Dose, Route, Frequency, Urgency, Duration, etc...
+
E.g., Medication
References
Constrains
Orderable Item
+
E.g., Dose :Physical Quantity
References
ConformsTo
E.g., Amoxicillin 200 mg Tab
Instantiate
1..*
Order Item
Requirement
+
+
E.g., Contact if not dispensed
E.g., Amoxicillin 200 mg Tab - 2 tablets, stat, PO
1..*
Order
Generates
0..1
0..*
Order Detail
+
Security, Routing, etc...
OrderResponse
+
Promise
Requirement
Status
E.g., Fulfillment or dispensation notification
+
E.g., Met
0..*
Figure 14: 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 drilldown 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.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.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 35
© 2013 Health Level Seven International. All rights reserved.
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 Lab Collection Center. The lab looks up and finds the order for her testing in
the lab system. The appropriate blood samples are extracted, their containers labeled, and the sample information
entered into the information in the lab system.
The lab performs the analysis on the specimen(s), enters the results into the lab 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 lab receives the specimen(s), accessions each, and looks up the order for her testing in the lab system. The lab
performs the analysis on the specimen(s), enters the results into the lab 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 lab performs the analysis on the specimen(s), enters the results into the lab
system, and sends the results to Dr. Primary’s care system reported as final.
Page 36
Description: Allows a client to create an order of one or more types
Pre-Conditions:
The client has sufficient information to create the request.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
User or requestor has permissions to create a request within the context.
Conceptual Information Objects:
Inputs:
Order
Outputs:
Order
Post-Conditions:
The returned order structure has been updated with order identifier.
Action maybe audited.
Knowledge of the order is retained by the order service
Exception Conditions:
Ordering Exception
Malformed Order Exception
Unfulfillable Order Exception
Notes
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 37
© 2013 Health Level Seven International. All rights reserved.
Figure 15: Create Order with Analyzable Entity
Page 38
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 16: Create Order without Analyzable Entity
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 39
© 2013 Health Level Seven International. All rights reserved.
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 lab 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 lab 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.
The user or requestor has permission to update an order.
Conceptual Information Objects:
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.
Exception Conditions:
Invalid Order state change, e.g. Order has already been completed.
Malformed Order.
Unfulfillable Order.
Notes
Under what conditions a specific order maybe 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 lab system. The previously received specimen had not yet been processed and so the analysis was
cancelled.
Page 40
Description: Used when a requestor (placer) would like for a previously requested, and
not yet completed, order not to be performed.
Pre-Conditions:
An order exists and the identifier is known.
The order is not completed.
The user or requestor has permission to cancel an order.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Any fulfillment systems involved in the processing the order allow the order to
be cancelled
Action may be audited.
Conceptual Information Objects:
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 is returned.
Exception Conditions:
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:
User or requestor has permissions to query for orders.
Conceptual Information Objects:
Inputs:
Subject or Query
Outputs:
A collection of orders
Post-Conditions
Action may be audited.
Exception 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
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 41
© 2013 Health Level Seven International. All rights reserved.
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.
The client has permission to retrieve orders.
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Order
Post-Conditions
Action may be audited.
Exception Conditions
Unknown Order
Notes
Retrieve Result
Story Board(s)
Later that day, Dr. Oncology accesses Eve’s medical record 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.
Page 42
Description: Allows a requestor to retrieve a result from the order service using the
result identifier.
Pre-Conditions:
The client has permission to retrieve results.
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.
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Result
Post-Conditions
Action may be audited.
Exception Conditions
Unknown Order.
Order does not provide results.
Results not yet available.
Results are currently unavailable.
Notes
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 but 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.
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:
An order exists and the identifier is known.
The fulfillment system making the request is associated with this order.
Conceptual Information Objects:
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.
Exception Conditions
Fulfillment service not associated with this order
Unknown Order
Notes
Update Result Status
Story Board(s)
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 43
© 2013 Health Level Seven International. All rights reserved.
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.
The user or requestor has permission to update a result status.
Conceptual Information Objects:
Input
Order Id
Result Id
Status
Output
Success/Fail
Post-Conditions
Change noted on order service.
Exception Conditions
Fulfillment service not associated with this order.
Unknown Order.
Notes
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.
Page 44
Description: Allows the fulfillment system to send the entire result to the Order Service.
Pre-Conditions:
An order result exists and the identifier is known.
The user or requestor has permission to update a result.
Conceptual Information Objects:
Input
Order Id
Result Id
Result
Output
Success/Fail
Post-Conditions
Exception Conditions
Fulfillment service not associated with this order
Unknown Order.
Notes
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Propose Order Replacement
Story Board(s)
One of Eves 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 and an alternate order to the
Order Service. This proposal occurs after the order has been accepted by the fulfillment
system and may occur as a result in changes in the fulfillment environment occurred
after that time.
Pre-Conditions:
Conceptual Information Objects:
Input
Order Id
Proposed Replacement Order
Output
Proposal is accepted for review (True/False)
Post-Conditions
Exception Conditions
Fulfillment service not associated with this order
Unknown Order.
Notes
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:
An order result exists and the identifier is known.
The user or requestor has permission to update a result.
Conceptual Information Objects:
Input
Order Id
Result Id
Result Augmentation
Output
Success/Fail
Post-Conditions
Exception Conditions
Fulfillment service not associated with this order
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 45
© 2013 Health Level Seven International. All rights reserved.
5.5
Unknown Order.
Notes
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 in to 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.
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
Page 46
Description: Allows the order service to place an order and receive a promise from the
fulfillment system.
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order
Outputs:
Promise
Fulfillment specific requirements
Promise Status
Post-Conditions
Order and promise associated
Fulfillment of the order maybe suspended pending fulfillment specific
requirements.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Exception Conditions
Order not supported by this service
Order is malformed
Notes
The specific details about what occurs in the fulfillment of and 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:
An order exists and the identifier is known.
The order is not completed.
The requester is the originator of the order.
The fulfillment service supports the cancellation operation.
Conceptual Information Objects:
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.
Exception Conditions:
Order is not known to the fulfiller.
Order cannot be cancelled.
Order has already been completed.
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:
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 47
© 2013 Health Level Seven International. All rights reserved.
Conceptual Information Objects:
Inputs:
Result Identifier(s) or Promise Identifier
Outputs:
Result(s)
Post-Conditions
Exception Conditions
Result unknown.
Promise unknown.
Notes
Get Result Augmentations
Story Board(s)
When Eve’s additional tumor marker validation and subtyping tests are resulted and appended, Dr. Oncology logs into the
to the EHR and retrieves the additional information appended to the original results. Embedded in the appended section
are Infobutton links to reference material explaining how the subtyping was done and its clinical significance.
Description: Allows the order service to retrieve supplemental information about a
result.
Pre-Conditions:
Conceptual Information Objects:
Inputs
Result Identifier
Outputs:
Result augmentation(s)
Post-Conditions
Exception Conditions
Result unknown.
Notes
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 residents order, but won’t actually fulfill it until the required endorsement is
obtained.
Page 48
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:
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Conceptual Information Objects:
Inputs:
Order Id
Outputs:
Requirement(s)
Post-Conditions
Exception Conditions
Unknown Order.
Notes
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.
5.6
Description: Allows the order service to validate the requirements of an order with a
fulfillment system.
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order Id
Requirements
Ignore Unknown requirements (True/False)
Outputs:
Valid (True/False)
Validation message
Post-Conditions
Exception Conditions
Unknown Requirement
Unknown Order.
Notes
Order Workflow Interface
The Order Workflow interface provides the core services that are required 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. The following diagrams show how the Order Workflow interface
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 49
© 2013 Health Level Seven International. All rights reserved.
would be used. In this case an order is discovered and specific requirement that are required are
updated.
The following is an example of how the Workflow interface might be used.
Page 50
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Figure 17: 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:
User or requestor has permissions to query for orders.
Conceptual Information Objects:
Inputs:
Subject or Query
Outputs:
A collection of orders
Post-Conditions
Action may be audited.
Exception Conditions
Invalid Query.
Invalid Subject.
Notes:
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 51
© 2013 Health Level Seven International. All rights reserved.
At the logical level, additional query criteria (e.g., date ranges, result status, etc.)
may be defined.
Retrieve Order
Story Board(s)
Later that day, Dr. Oncology accesses Eve’s medical record 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:
The order identifier is known.
The client has permission to retrieve orders.
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Order
Post-Conditions
Action may be audited.
Exception Conditions
Unknown Order.
Notes
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.
Page 52
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.
The user or requestor has permission to update an order.
Conceptual Information Objects:
Inputs:
Order
Order Identifier
Outputs:
Order
Post-Conditions:
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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.
This action may be audited
Exception Conditions:
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 maybe 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:
An order exists and the identifier is known.
The order is not completed.
The system has permission to update an order status.
Conceptual Information Objects:
Inputs:
Order
Order Identifier
Outputs:
Success
Post-Conditions
Exception Conditions
Unknown Order
Invalid state change
Notes
Query Order Requirements
Story Board(s)
Description: Provides consumer the ability to find what requirements an order has for
fulfillment and what their current status is. This source of this information might include
such thinks and the order catalog, order service configuration, and requirements
asserted by fulfillment systems.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 53
© 2013 Health Level Seven International. All rights reserved.
Object Model:
Figure 18: Query Order Requirements
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Collection of requirements with details
Post-Conditions
Exception Conditions
Order is not known to the System.
Notes
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.
Page 54
Description: Allows the Order Service to be updated when requirements for a given
order are updated.
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Collection of requirements
Post-Conditions
Varies depending upon the specifics order and its related workflow and
requirements.
Exception Conditions
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Order is not known to the System.
Notes
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 a consumer of order service to validate the requirements of an
order.
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order Id
Requirements
Ignore Unknown requirements (True/False)
Outputs:
Valid (True/False)
Validation message
Post-Conditions
Exception Conditions
Unknown Requirement
Unknown Order.
Notes
Depending on the nature of the requirement,the fulfillment service(s) involved in this
order may also be consulted.
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 the order.
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order Id
Outputs:
Workflow Model
Post-Conditions
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 55
© 2013 Health Level Seven International. All rights reserved.
Exception Conditions
Unknown Requirement
Unknown Order.
Notes
The Workflow Model is not in scope for this specification
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.
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 admission 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:
Conceptual Information Objects
Input:
A valid query statement
Output:
A collection of catalog item types
Post-Conditions
Exception Conditions
Invalid Catalog Request
Notes
Page 56
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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 parental, solid, and liquid diets. 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:
Conceptual Information Objects
Input:
A valid query.
Output:
Collection of catalog items.
Post-Conditions
Exception Conditions
Notes
Get Catalog Item Detail
Story Board(s)
Dr. Hospitalist selects a reduced calorie, low carbohydrate diet from the order catalog. He receives a list of the diet’s
daily menu options and a detailed list of nutritional data including calories, fat content, and other ingredients.
Description: User can retrieve details about orderable items in the catalog.
Pre-Conditions:
Conceptual Information Objects
Input: The identifier of the catalog item
Output: The catalog item
Post-Conditions
Exception Conditions
Catalog Item Does Not Exist
Notes
Get Catalog Item Prototype
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:
Conceptual Information Objects
Input:
Catalog Item Prototype identifier or Catalog Item Type
Output:
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 57
© 2013 Health Level Seven International. All rights reserved.
Catalog Item Prototype
Post-Conditions
Exception Conditions
Catalog Item Does Not Exist
5.8
Order Service Catalog Management Interface
The Order Service Catalog Management interface allow 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.
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:
Conceptual Information Objects
Input: A valid catalog item identifier
Output: A catalog item
Post-Conditions
Exception Conditions
Catalog Item Does Not Exist
Notes
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.
Page 58
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Description: Allows a caller to update a catalog item.
Pre-Conditions:
Conceptual Information Objects
Input: A valid Catalog Item
Post-Conditions
Exception Conditions
Catalog Item Does Not Exist
Notes
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:
Conceptual Information Objects
Input: A valid Catalog Item identifier
Post-Conditions
Exception Conditions
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:
Conceptual Information Objects
Input: A valid Catalog Item
Post-Conditions
Exception Conditions
Invalid Format
Notes
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 59
© 2013 Health Level Seven International. All rights reserved.
5.9
Order Notification Interface
The order notification interface is used by other order handling systems to provide visibility to
the order service of orders that 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.
Conceptual Information Objects
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
Exception Conditions
Not authorized
Notes
If the order services wishes further updates relating to this order it should
return a local order identity to its copy of the order
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.
Page 60
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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.
Conceptual Information Objects
Input
Order
Local Order Identity
Remote Service Identity
Output
Success (True/False)
Post-Conditions
Local state of the order is updated
Exception Conditions
Not Authorized
Order Unknown
Notes
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.
Conceptual Information Objects
Input
Order
Local Order Identity
Remote Service Identity
Output
Success (True/False)
Post-Conditions
Local state of the order is updated
Exception Conditions
Not Authorized
Order Unknown
Notes
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 61
© 2013 Health Level Seven International. All rights reserved.
5.10 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 login into the hospital EMR and checks to see if all her discharge
orders had been processed,
Description: Used to obtain a list of Orders that are still are not complete.
Pre-Conditions:
User or requestor has permissions to query for orders.
Conceptual Information Objects:
Inputs:
Query
Outputs:
A collection of orders
Post-Conditions
Action may be audited.
Exception Conditions
Invalid Query.
Notes:
At the logical level, additional query criteria (e.g., date ranges, result status, etc.)
may 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 hold up might be.
Page 62
Description: Allows the client to retrieve a specific Order and its full detail, given an
Order Identifier.
Pre-Conditions:
The order identifier is known.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
The client has permission to retrieve orders.
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Order
Post-Conditions
Action may be audited.
Exception Conditions
Unknown Order
Notes
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:
The client has permission to retrieve results.
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.
Conceptual Information Objects:
Inputs:
Order Identifier
Outputs:
Result
Post-Conditions
Action may be audited.
Exception Conditions
Unknown Order.
Order does not provide results.
Notes
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 the order.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 63
© 2013 Health Level Seven International. All rights reserved.
Pre-Conditions:
Conceptual Information Objects:
Inputs:
Order Id
Outputs:
Workflow Model
Post-Conditions
Exception Conditions
Unknown Requirement
Unknown Order.
Notes
The Workflow Model is not in scope for this specification
5.11 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:
Conceptual Information Objects
Input
Output
Service Status
Post-Conditions
Exception Conditions
Not authorized
Notes
Get Fulfillment Statistics
Page 64
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
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:
Conceptual Information Objects
Input
Fulfillment Type(s)
Output
Collection of statistics
Post-Conditions
Exception Conditions
Not Authorized
Notes
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:
Conceptual Information Objects
Input
Output
Statistics
Post-Conditions
Exception Conditions
Not Authorized
Notes
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:
Conceptual Information Objects
Input
Output
Fulfillment Information
Post-Conditions
Exception Conditions
Not Authorized
Order Unknown
Notes
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 65
© 2013 Health Level Seven International. All rights reserved.
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 19: Create Order Flow - Analyzable Entry Required
Page 66
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
The following diagram depicts the event flow for orders that do not require an Analyzable Entity
to be obtained.
Figure 20: Create Order Flow - Analyzable Entry Not Required
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 67
© 2013 Health Level Seven International. All rights reserved.
Change Order Event Flow
Allows the client to submit a change to an existing Order.
Figure 21: Change Order Event Flow
Page 68
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Cancel Order Event Flow
Used when a requestor (placer) would like for a previously requested, and not yet
completed, order not to be performed.
Figure 22: Cancel Order Event Flow
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 69
© 2013 Health Level Seven International. All rights reserved.
Catalog Event Flow
Figure 23: Catalog Event Flow
6 Profiles
6.1
Introduction
A set of conformance profiles are defined that cover specific functions, semantic information
and overall conformance.
Core Ordering
Page 70
Must implement the Order Management Interface
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
Pluggable Fulfillment
Must implement the Order Management Interface
Must implement the configuration of fulfillment systems callable by the Fulfillment
Interface
Must call pluggable fulfillment implementations using the Fulfillment interface
May implement other interfaces
Order Catalog
Must implement the Order Management Interface
Must implement the Order Catalog Interfaces
May implement other interfaces
Work flow support
Must implement the Order Management Interface
Must implement the Order Workflow Interface
Must defer order fulfillment until requirements are met
May implement other interfaces
Fulfillment request push
Must implement the Order Management Interface
Must fulfill the requirements for pluggable fulfillment
Must implement the Fulfillment Update Interface
Must preserve updates from the Fulfillment Update Interfaces
May implement other interfaces
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 71
© 2013 Health Level Seven International. All rights reserved.
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.
Page 72
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
8 Appendix A - Relevant Standards
Review of potentially relevant standards, including a short-list of applicable standards.
For each applicable standard (this may include citations to standards themselves,
information content, portions of standards, etc. Demonstrate that “you are not reinventing the wheel”):
A short review that explains its intended relationship to this specification
What are the relevant parts that are being re-used, extended, etc.
Include context of how the service relates to the existing standard.
How does this work relate to similar work;
What are the implications if this service is used in an environment that has
already adopted a competing or closely related standard
If there is relevant realm work, a traceability matrix would be useful here {for instance,
U.S. Federal Enterprise Architecture/Service Reference Model}
HL7:
FHIR Order Resource
FHIR Order Response Resource
Order Request Manager
Composite Order
Nutritional Orders
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 73
© 2013 Health Level Seven International. All rights reserved.
9 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.)
CDS
Clinical decision support
CDSS
Clinical Decision Support Service (synonymous with DSS)
DRG
Data requirement group
DRI
Data requirement item
DSS
Decision Support Service
HITSP
Health Information Technology Standards Panel of ANSI HL7 Health
Level 7
HSSP
Healthcare Services Specification Project
IHE
Integrating the Healthcare Enterprise
ISO
International Organization for Standardization
KM
Knowledge Module
OMG
Object Management Group
PIM
Platform Independent Model
PSM
Platform Specific Model
RIM
Reference Information Model defined by HL7
RM-ODP
Reference Model of Open Distributed Processing
SFM
Service Functional Model
UML
Unified Modeling Language
.
Page 74
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
10 Appendix C - HL7 EHR Functional Model Traceability
This section lists the EHR Functions that are related to this service.
Note that in general there will not be a direct correspondence between EHR Functions and HSSP Services, since Services are
specified from a different system viewpoint. The mapping provided here enables the HSSP Services to be understood in the context
of the EHR-S Functional Model DSTU. The table below references Version ________ of the EHR Functional Model.
EHR Function ID
EHR Function Name
EHR Function Statement
Notes
For every row, explain the rationale for including in
this specification.
HL7 Version 3 Specification: Ordering Service Interface, Release 1
January 2014
Page 75
© 2013 Health Level Seven International. All rights reserved.
11 Appendix D - 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:
1. SFMs shall provide a conformance profile supporting HL7 content where relevant.
2. We shall not preclude the use of non-HL7 content.
3. SFMs will reuse to the maximum extent possible the content models as defined in other
standards (for example, HL7 RMIMs).
4. Information content representations shall be represented in platform-agnostic formalisms
(e.g., UML).
5. 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).
6. 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.).
7. Details about semantics specific to this SFM appear in other sections of this document.
Page 76
HL7 Version 3 Specification: Ordering Service Interface, Release 1
© 2013 Health Level Seven International. All rights reserved.
January 2014
© Copyright 2026 Paperzz