Query+for+Docs+Page+1

= 1 Preface =

1.1 Introduction
The Nationwide Health Information Network (NHIN) Web Service Interface specifications define the core set of standard services to be implemented by each node on the NHIN network in order exchange interoperable health information over the Internet. Health Information Organizations (HIOs) which act as nodes on the NHIN are termed NHIOs. These functional services provide discovery and information exchange capabilities and rest upon a foundational set of messaging, security, and privacy services.

This document presents the NHIN Query for Documents Web Service Interface specification. Together with the Retrieve Documents Service Interface specification, Query for Documents enables the NHIN’s Query/Retrieve information exchange pattern.

1.2 Intended Audience
The primary audiences for NHIN Specifications are the individuals responsible for implementing software solutions that realize these interfaces at Health Information Organizations (HIOs) who are, or seek to be, nodes on the NHIN network. This specification document is intended to provide an understanding of the context in which the web service interface is meant to be used, the behavior of the interface, the Web Services Description Language ( WSDLs) used to define the service, and any Extensible Markup Language (XML) schemas used to define the content.

1.3 Business Needs Supported by this Specification
Query for documents is the second in the three-step process which defines the Query/Retrieve information exchange pattern in the NHIN: 1) Arbitrate patient identity 2) Query for list of available documents 3) Retrieve documents

1.4 Referenced Documents and Standards
The following documents and standards were referenced during the development of this specification. Specific deviations from or constraints upon these standards are identified below. 1) **Org/SDO name:** HITSP **Reference # / Spec Name:** TP13 / Manage Sharing of Documents Transaction Package  **Version #:** v2.6  **Underlying Specs:**   · IHE ITI TF Supplement XCA TI (2009-8-10)   · IHE ITI TF Vol. 1 & 2a, 2b, 2x, 3 Revision 6.0 (2009-8-10)  **NHIN Deviations or Constraints:** see entry for IHE ITI TF Supplement XCA TI (2009-8-10)  **Link:** []

2) **Org/SDO name:** HITSP **Reference # / Spec Name:** C80/ Clinical Document and Message Terminology Component  **Version #:** v1.1.1  **NHIN Deviations or Constraints:**  **Underlying Specs:**  **Link:** []

3) **Org/SDO name:** IHE **Reference # / Spec Name:** ITI TF Supplement XCA TI  **Version #:** 2009-8-10  **NHIN Deviations or Constraints:**   · IHE XCA 3.38 -. This specification allows return of -1 in hash and size to indicate "not available" to support dynamic documents. The use of availabilityStatus=”urn:ihe:iti:2010:StatusCode:DeferredCreation” indicates that the document creation has been deferred until a retrieve is received. Further explanation is given in sections 2.3 “Transaction Standard” and 3.3 “Query Parameters”.   · IHE XCA 3.38 - Document identifiers may be only valid for a limited time period – IHE makes no statement about this.   · IHE XCA 3.38 – XCA does not currently support the XDSUnknownPatientId to be used in a response to Cross Gateway Query. This specification allows this error to be used to indicate that a previously valid patient identifier is no longer valid. This deviation from XCA increases the risk of a spoofing attack as it is easier for an attacker to identify an invalid patient identifier. Rather than use this error, XCA requires that invalid identifiers result in the return of an empty list. **IHE Change Proposal 450** has been submitted to request a change of the IHE requirement and is expected to be approved by Spring 2010. **Underlying Specs:** **Link:** [] **Change Proposals Adopted by NHIN:** a. **//Change Proposal Name://** IHE Change Proposal 420 **//Change Proposal Description://** Updates XCA to use a single Action value for both synchronous and asynchronous interactions. This balloted and approved Change Proposal will integrate into the XCA Supplement in August 2010 and is adopted by the NHIN now because of its importance. **//Change Proposal Link://** [] b. **//Change Proposal Name://** IHE Change Proposal 403, 429 **//Change Proposal Description://** Minor updates to audit requirements. **//Change Proposal Links://** [], ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2009/CPs/FinalText/CP-ITI-429-FT.doc c. **//Change Proposal Name://** IHE Change Proposal 413 **//Change Proposal Description://** Clarification of calculation of hash. **//Change Proposal Link://** [] d. **//Change Proposal Name://** IHE Change Proposal 415 **//Change Proposal Description://** Defines an error in the case where a list of document unique ID’s in a query without patient identifier reference different patients **//Change Proposal Link://** []

4) **Org/SDO name:** IHE **Reference # / Spec Name:** ITI TF Vol. 1 & 2a, 2b, 2x, 3  **Version #:** Revision 6.0 (2009-8-10)  **NHIN Deviations or Constraints:**  **Underlying Specs:**  **Links:**  · []  · []  · []  · []  · []

5) **Org/SDO name:** OASIS **Reference # / Spec Name:** ebRIM: OASIS/ebXML Registry Information Model  **Version #:** v 3.0  **NHIN Deviations or Constraints:**  **Underlying Specs:**  **Link:**  []

6) **Org/SDO name:** OASIS **Reference # / Spec Name:** ebRS: OASIS/ebXML Registry Services Specifications  **Version #:** v 3.0  **NHIN Deviations or Constraints:**  **Underlying Specs:**  **Link:**  []

1.5 Relationship to Other NHIN Specifications
This specification is related to other NHIN specifications as described below: · **Messaging Platform –** specifies a base set of messaging standards and web service protocols which must be implemented by each NHIN node and applies to all transactions. All NHIN inter-nodal messages are SOAP messages over HTTP using web services, must be encrypted and digitally signed. · **Authorization Framework** – defines the exchange of metadata used to characterize each NHIN request. The purpose of that exchange is to provide the responder with the information needed to make an authorization decision for the requested function. Each initiating message must convey information regarding end user attributes and authentication using SAML 2.0 assertions. Together, the Messaging Platform and the Authorization Framework define the foundational messaging, security and privacy mechanisms for the NHIN.

· **Patient Discovery –** defines the mechanism by which one NHIN node can query another to reciprocally establish patient identity and to determine if a node may be a source of information for a specific patient. It represents the first of three steps in the typical NHIN Query/Retrieve information exchange pattern. · **Retrieve Documents** – allows an initiating NHIN node to retrieve specific documents from a responding node using the Document Reference IDs obtained via a prior Query for Documents transaction. It represents the final of the three steps in the typical NHIN Query/Retrieve information exchange pattern. · **Web Services Registry** – enables nodes to discover each other through interactions with the NHIN UDDI registry, which lists NHIN nodes, the NHIN web services supported by each node, and how to reach those service end points. In this context, it might be needed to identify target nodes. **Next Page**