Comments due 9 Jul 2012 to indicate interest to develop OMG Spec.
VA funding will be available for RFP
PEFORMANCE WORK STATEMENT (PWS)
Specification of Service Interfaces to Enable Scalable, Standards-Based, Service-Oriented
Clinical Decision Support
June 26, 2012
Despite significant promise, advanced Clinical Decision Support (CDS) capabilities are not widely
available. While there are many reasons for this limited availability, an important reason is that
CDS capabilities are typically tightly coupled to individual software modules within specific clinical
information systems (CISs). For example, an alerting capability may be tightly coupled to the
computerized provider order entry (CPOE) module of a specific electronic health record (EHR)
system. As the scope of potentially useful CDS clearly surpasses the scope of CDS that can be
reasonably provided by any single vendor or healthcare delivery organization, it becomes
imperative to establish an architectural framework in which CDS capabilities and content can be
developed by multiple independent groups and utilized in multiple CISs.
An option for scaling CDS is the use of a service-oriented architecture (SOA). A SOA can be
utilized to provide a system in which independent services are coordinated to deliver the desired
functionality. For example, a point-of-care disease management module of an EHR system can
be efficiently implemented by leveraging software services such as a clinical data query service, a
terminology service, a communication service, and a Decision Support Service (DSS) that takes
in structured patient data and provides back patient-specific care guidance. SOAs for CDS have
been proposed and shown to have significant promise by many investigators, including through
the SAGE project, SEBASTIAN, the DDS-KMR project and the CDS Consortium.
The Department of Veterans Affairs (VA) and Department of Defense (DoD) are collaborating on
an interagency electronic health record (iEHR) that is designed around a service-oriented
architecture (SOA) coordinated by an enterprise service bus (ESB). The use of a SOA is
intended to enable the efficient addition of advanced capabilities, including CDS. Despite the size
and importance of this project, it is valuable for community consensus to be developed on how
CDS capabilities developed by various organizations (e.g., healthcare organizations and
knowledge vendors) can be integrated into EHR systems using common service interfaces.
In recognition of this need, the Health Level Seven (HL7) CDS Work Group embarked on an
effort in early 2012 to establish community consensus on the services and other capabilities
desired from CISs to enable a SOA for CDS. To this end, the HL7 CDS Work Group reviewed
the literature, hosted multi-stakeholder discussions, and consulted domain experts to identify and
prioritize the services and capabilities required from CISs to enable service-oriented CDS. In
addition, relevant available standards were identified. Through this process, ten CIS services and
eight CIS capabilities were identified as being important for enabling scalable, service-oriented
CDS. The results of this analysis are available in the attached manuscript (appendix 1), which
will be presented at the fall 2012 AMIA conference.
The objective of the proposed project is to define service interfaces for Electronic Health Record
(EHR) services required for a SOA approach to CDS, which both (i) support the CDS needs of
interoperable Electronic Health Record (iEHR) and (ii) can serve as the basis of international
health IT standards in this area.
The contractor will develop service interface specifications for the following three services: Event
Subscription and Notification Service; Order Placement Service; and User Communication
Service (see table).
These services were deemed to be priority services by the multi-stakeholder discussions for
which a current standard specification does not exist. The service specifications must (i) support
the CDS needs of the iEHR environment and (ii) be appropriate to serve as a starting point for
standardization through the Health Level Seven (HL7) Object Management Group
(OMG)Healthcare Service Specification Project (HSSP; hssp.wikispaces.com). The co-chair of
the HL7 CDS Work Group who has developed an HSSP/HL7/OMG standard (Dr. Kensaku
Kawamoto, MD, PhD) will be available as consultative resources.
Service Description and Example Use Case
Description: Publishes relevant CIS events, which can be listened to by a
CDS system to trigger CDS. Allows systems to subscribe to specific types of
Use case: EHR system publishes events such as the entry of new labs into
the clinical data repository, patients checking into appointments, and users
logging into the system. CDS system subscribes to types of events that will
trigger specific CDS processes.
Description: Places a clinical order.
Use case: CPOE CDS module places a pending order for lisinopril 5mg PO
Description: Communicates CDS results with appropriate end users.
Use case: A CDS system places a note in the EHR system’s alert inbox;
CDS system provides a popup alert; physician is paged regarding urgent CDS
Deliverables – Three Service Interface Specifications.
1) Each service interface specification will contain the sections and be formatted according to
the conventions below used in the HL7 and OMG. This process is further described at
a) HL7 Service Functional Model (SFM)
i) Template available at
ii) Example SFM for Decision Support Service available as Appendix II
b) OMG Technical Specification
i) Example Technical Specification for Decision Support Service available at
c) The most current version of each template available at the time of work product creation
shall be used
2) For the purposes of this contract, a service specification shall be primarily defined in terms of
the requirements set by Healthcare Services Specification Project (HSSP) as outlined in
Deliverable item 1 above. Moreover, the service specifications shall meet the following
requirements, which are based on the description of a service specification by IBM
http://www.ibm.com/developerworks/rational/library/07/1009_amsden/). In particular, a
service specification must specify everything that a potential consumer of the service needs
to know to decide if they are interested in using the service, as well as exactly how to use it. It
must also specify everything a service provider must know to successfully implement the
service. Thus, a service specification is a mediator or a contract between what consumers
need and what providers provide. Service specifications include at least this Information:
a) The name of the service, suggesting its purpose.
b) The provided and required interfaces, thereby defining the functional capabilities that are
provided by the service and those that it requires of its consumers. Note: This is not
about how the service is implemented, but rather the interaction between the consumers
and providers for this service.
c) Any protocol that specifies rules for how the functional capabilities are used or in what
d) Constraints that reflect what successful use of the service is intended to accomplish and
how it will be evaluated.
e) Policies for using the service, such as security and transaction scopes for maintaining
security and integrity or for recovering from the inability to successfully perform the
service or any required service.
f) Minimum of five Use Cases for each Service interface specification that illustrates the
projected implementation and capabilities of the service.
3) Milestone Deliverables and Due Dates
a) Interpretation and description of target clinical decision support environment 2 months
b) Interface Service Specifications
i) Draft 1 of Service Functional Models and Service Technical Specifications – 6
months from date of award
ii) Draft 2 of Service Functional Models and Service Technical Specifications – 9
months from date of award
iii) Final Service Functional Models and Service Technical Specifications – 11 months
from date of award
c) Monthly status reports describing progress, obstacles, plans for overcoming obstacles
and anticipated work for the upcoming month – Due on the last Wednesday of each
4) Review and Acceptance: The Government will review each deliverable within 10 business
days of delivery and the contractor must address each issue in the deliverable and provide a
punch list describing the changes within 10 business days of receipt of Government
5) Deliverable Format: The deliverables will be in Microsoft Word document format (2003 or
later) for narrative documents, Enterprise Architect models and platform-neutral XML
Metadata Interchange (XMI) exports for Unified Modeling Language (UML) models, XML
Schema Definition (XSD) files for XML schemas, and Web Service Description Language
(WSDL) files for Web service definitions. These deliverables shall be delivered electronically.
6) Government furnished Information: The Government will furnish existing HL7 specifications
and related content if needed by the contractor and determined to be "in scope" by the
7) Period of Performance: Date of Award + 12 months
8) Type of Order: Firm Fixed Price
9) Place of Performance: Contractor’s site.
a) Face to face meetings x 3
i) Nashville location, each meeting for 2 days
ii) Kick off, final presentation, and midcourse presentation
b) HL7 CDS work group meeting x 1 during U.S.-based HL7 meeting
i) One of the following meetings to be determined in conjunction with Government –
Jan 16, 2013 to Jan 17, 2013 in Phoenix, AZ or May 8, 2013 to May 9, 2013 in