NOTE: To use Track Changes, turn off “protection” by clicking on (pre-MS Word 2007) Tools > Unprotect Document or (MS Word 2007 and higher) Review > Protect Document.

PSS-Lite/Investigative Projects: Sections surrounded by a BOLD OUTLINE must be completed for approval of "Investigative Projects" (a.k.a PSS-Lite).

1.  Project Name and

Ordering Service Interface Specification Project / Project ID: 1010
TSC Notification Informative/STU to Normative / Date :
Check this box when the project proceeds from Informative to Normative or STU to Normative status. Forward to the TSC for notification, as this triggers American National Standards Institute (ANSI) Project Initiation Notification (PINS) submission.
Investigative Project / Date :
Check this box when the project is investigative or exploratory in nature, which allows limited project scope definition. Sections in bold outline are mandatory for project approval of an investigative project; all other sections are optional. (Sections 1, 2, 3a, 3b, 3g [limited, 6b [if known], and 6c [applicable] are required).
Investigative Project specific instructions are yellow highlighted.
An investigative project must advance in two WGM cycles, requiring a full scope statement. Otherwise the project will be closed.

2.  Sponsoring Group(s) / Project Team

2.a. Primary Sponsor/Work Group

Primary Sponsor/Work Group
(1 (And Only 1) Allowed) / Orders and Observations

2.b. Co-sponsor Work Group(s)

Co-sponsor Work Group(s)
(Enter co-sponsor approval dates in Section 6.c Project Approval Dates) / Service Oriented Architecture
Indicate the level of involvement that the co-sponsor will have for this project:
Request formal content review prior to ballot
Request periodic project updates. Specify period: / Monthly, at WGMs, etc.
Other Involvement. Specify details here: / Enter other involvement here
Co-sponsor Work Group(s)
(Enter co-sponsor approval dates in Section 6.c Project Approval Dates) / Clinical Decision Support
Indicate the level of involvement that the co-sponsor will have for this project:
Request formal content review prior to ballot
Request periodic project updates. Specify period: / Monthly, at WGMs, etc.
Other Involvement. Specify details here: / Enter other involvement here
Co-sponsor Work Group(s)
(Enter co-sponsor approval dates in Section 6.c Project Approval Dates) / Pharmacy??
Indicate the level of involvement that the co-sponsor will have for this project:
Request formal content review prior to ballot
Request periodic project updates. Specify period: / Monthly, at WGMs, etc.
Other Involvement. Specify details here: / Enter other involvement here
Co-sponsor Work Group(s)
(Enter co-sponsor approval dates in Section 6.c Project Approval Dates) / Imaging Integration???
Indicate the level of involvement that the co-sponsor will have for this project:
Request formal content review prior to ballot
Request periodic project updates. Specify period: / Monthly, at WGMs, etc.
Other Involvement. Specify details here: / Enter other involvement here

2.c. Project Team

Project facilitator (1 Mandatory) / Emory Fry, MDClaude Nanjo
Other interested parties and their roles / Craig Parker, MD; Davide Sottara, PhD, Pharmacy, Patient Care
Multi-disciplinary project team (recommended)
Modeling facilitator / Claude Nanjo
Publishing facilitator / Lorraine Constable
Vocabulary facilitator
Domain expert rep / ·  Francois Macary, Julie Scherer, Jose Costa Teixeira, Richard Esmond (II)
Business requirement analyst / Claude Nanjo
Conformance facilitator (for IG projects)
Other facilitators (SOA, etc) / CDS: Ken Kawamoto, MD; O&O: Lorraine Constable
Implementers (2 Mandatory for STU projects)
FHIR Project Note: The implementer requirement will be handled by the “balloting” project. Therefore work groups do not fill out the above section. However, feel free to list implementers specific to your work group’s resources if you know of any.
1) Cognitive Medical Systems, Inc
2) Intermountain Healthcare

3.  Project Definition

3.a. Project Scope

The proposed Ordering Service is intended to complements existing SOA services and the SAIF BehavioralBehavioural Framework (BF) for HL7. It will provides a Service Functional Model (SFM) for ordering pharmacy, laboratory, radiology, consult and nutritional services individually or part of an order set. The Ordering Service is intended to supports interactive applications utilized by healthcare providers, and service-to-service interactions as might be required by a Clinical Decision Support system. The initial interface specification will was be developed according to the conventions described at http://hssp.wikispaces.com/HSSPApproach, and will be documented in a corresponding HSSP wikiballoted in January 2013.September 2014, published as DSTU February 2015.
Pre-existing conceptual work in topics such as Composite Orders, Laboratory Orders, Nutrition, Medication, or FHIR Order and Prescription resources will were be leveraged extensively to help document the necessary definitions, descriptions, graphics, and artefacts that are relevant. In keeping with the approach used by the above referenced projects, the Ordering Service will distinguished between the order itself and the item requested. The Service Interface Specification will provides functional, semantic, and conformance profiles.
·  The submittedcurrent scope modification to the original PSS approved in 2013 is described below. The original scope statement for the Oorder Mmanagement service component of the service remains the same. However, this PSS modifies the Order Catalog Servicecomponent scope based on the need to harmonize requirements from new community contributions such asfrom eDOS and FHIR. Note that this PSS update addresses both orderable/product catalogs and their corresponding operations as well as the content contained therein. We refer to the entries in a catalog as ‘catalog entries’.
The core use cases areinclude:
·  The exchange of evidence-based clinical decision support content such as order set catalogs and corresponding orderable item catalogs between content providers and health care provider organizations.
Tthe sharing of product information from the regulators or catalog providers, making such information available to the clinical system that handle ordering, delivery and notifications about products so that systems have the relevant information about the existence and/or characteristics of the products.
· 
This project would
a)  FindDefine a common approach or structureconceptual model to support the exchange of productscatalog entry information. A "catalog" infrastructuremodel that would enable the construction of catalogs of devices, medications, etc. The resulting architecture shall address the representation, management, retrieval, and exchange of catalog entries including orderable items and products contained within a catalog.
b)  Describe how existing resources like Medication and Device can be used in the context of such catalog, to ensure that the end result is a valid "product catalog", or "device catalog", or “orderable item catalog”.
c) 
d) 
ThisThe resulting work product should handle aspects like:
·  Structuring of product attributes - hierarchies, handlingManaging locally defined characteristics vs characteristics defined by evidence-based CDS content vendors, manufacturers or regulators
·  Handshake - how to handle full updates vs differential updates, push vs pull models, etc.
·  Grouping and referencing - some products are actually a grouping of other products, and some products may reference other products. Medication protocols are an example, or lab services and devices/consumables.
·  Interdependencies - a catalog entry may define not just the item(s) but (also) rely on other aspects like workflow definitions, etc.
·  (Typical) use cases for exchange of product information, from regulators to clinical documents. Typical case is a bulk update of product info, but additional use cases may emerge from the analysis or from the openMedicine project, for example a real time query for retrieving products that meet certain conditions.
·  (Typical) use cases for the exchange of evidence-based clinical decision support between content vendors and health care providers. Use cases include the import of evidence-based content from content vendors, the maintenance of existing health care provider content based on changes in evidence-based recommendations or product recalls, the customization and/or normalization of content prior to export, and the ability to maintain catalogs between content and health care providers in sync.
There are commonalities for medication, devices and other itemscatalog entries, so a common mechanismmodel should be sought, possibly by linking to the base resources like device, medication. SIn the case of product catalogs,- special attention should be with regulators so that regulatory product info is in alignment with clinical exchange of product data.
The figure below shows the interaction between this PSS and the other resources (and PSSs: This is an infrastructural resource or model or pattern, not tied to a specific resource or domain.

Scope exclusions:
·  Inventory information (quantity at hand and traceability information) may be mentioned but are not in the dimension of formulary, so special caution is needed to avoid it.
·  The workflows and approaches by which this information is exchanged are not to be hardcoded: the mechanisms can be push or pull, synchronous or asynchronous, full or differential updates...
·  The different kinds of participants (drug databases, dispensing systems) and the kinds of data (internal data, national data, international data, regulatory, scientific or clinical data) are to be supported but not specifically hardcoded. Implementers can use this in a simple configuration inside a hospital, or use this context to retrieve data from national regulators or product DBs.
·  The value sets may be in principle excluded: when exchanging a list of medication products, it is not intended to exchange the code sets for substances, diseases, etc.
Some Order Catalog Service usage scenarios include:
The national drug authority publishes a service "product discovery" that enables consulting product characteristics based on its ID.
A drug database provider publishes a service that allows its customers to query for products based on ID, but also on characteristics, and obtain all characteristics of the product.
The hospital gets a weekly update from such drug database, for the products they have in their catalog and that are new or have been updated since the last synchronization.
The hospital makes its own catalog of products (=drugs+devices) from consulting those catalogs. It appends limited inventory information for that hospital
A physician scans a UDI from a product into the device database (a clone of the FDA GUDID database) and from that UDI, an ID is available, which allows the system to check that the item is not MRA safe (that is catalog information) and as such the product may not be ideal.
Every year, the hospital provides a list of the lab services available (e.g. lab procedures within the hospital and agreed providers), and the physicians can chose from that list.
A health care organization chooses to import a collection of order sets from a content vendor’s order set catalog into its EHR after customizing them.
A health care organization wishes to export one or more order sets into the content vendor’s system in order to update them based on the latest evidence-based recommendations. The health care provider then reimports these updated order sets into their EHR.
To support model transformation and terminology mapping, a health care organization chooses to export its orderable catalog, associated orderable models and constraints, and corresponding code set vocabulary into the content vendor’s system.
A health care organization or content vendor wishes to identify all order sets that reference a recalled medication product in order to properly adjust them.
Some usage scenarios:
a)  A CPOE system that provides extensive drug-drug, drug-allergy, and drug-disease decision support utilizes the interface to place a weight-adjusted Amoxicillin order for a paediatric patient.
b)  An EMR utilizes the interface to allow a community provider to refer a patient for an orthopaedic consult at the regional medical center.
c)  A hospitalist orders a low-carbohydrate, diabetic diet for a patient using a dedicated nutrition system.
d)  A Clinical Decision Support system analyses a patient’s clinical data and determines that their annual HgA1c is over due. The system places an unsigned order for the test and then notifies the Primary Care provider that their signature is required.
Exclusion: 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 semantics and management of orders that can be delegated or transferred is out of scope.
The Service Functional Model identified Order Catalog and Catalog Management interfaces. As the project moved into the OMG RFP logical and physical specification phases of the project, a need was identified to add FHIR capabilities for catalog and master data functionality for lab and pharmacy. The catalog stream of the Ordering Service specification is also tasked with defining a FHIR interface for the service specification. The required close coordination between the FHIR content model efforts and the technical service interface specification effort resulted in the decision to combine the scopes and add the FHIR implementation guide and profile scope to the FHIR physical model scope of the OMG technical specification effort. This project will trial the updated OMG / HL7 / FHIR collaboration process.

3.b. Project Need

A generalized service is needed to provide a standardized way to instantiate orders and thus initiate clinical workflows. The Ordering Service will provide a key integration component between systems involved in the distributed delivery and coordination of clinical care. Clinical Decision Support systems will benefit significantly. By being able to place unsigned, evidence-based orders requiring only a provider’s final signature, CDS tools will help overcome unnecessary behavioural or educational barriers to desired clinical practice. As appropriate, fully automated ordering and/or triggering of desirable workflow will reduce unnecessary approval delays, improve efficiency, and help reduce the task burden placed on providers and other care professionals.The existing Service Functional Model identified Order Catalog and Catalog Management interfaces. As the project moved into the OMG RFP logical and physical specification phases of the project, a need was identified to add FHIR capabilities for catalog and master data functionality for lab and pharmacy. The catalog stream of the Ordering Service specification is also tasked with defining a FHIR interface for the service specification. The required close coordination between the FHIR content model efforts and the technical service interface specification effort resulted in the decision to combine the scopes and add the FHIR implementation guide and profile scope to the FHIR physical model scope of the OMG technical specification effort. This project will trial the updated OMG / HL7 / FHIR collaboration process.
Additionally, there is a need to provide the ability to manage, federate and publish order, pharmacy and laboratory catalogues on the FHIR platform.

3.c. Security Risks