Query+for+Documents+Page+2

3 Interface Description
This section defines the NHIN Query for Documents web service, reviews its design principles and assumptions, triggers, and provides an explanation of underlying standards and protocols. Further descriptions, including pre and post conditions and usage scenarios can be found in Appendix XX.

3.1 Definition
**A query initiated from one NHIO to another, requesting a list of available documents meeting the given query parameters for a particular patient for later retrieval.** Query for Documents is used when a Document Consumer wants to query and retrieve standardized document metadata. In this Interface definition, a “document” refers to the form of clinical data as it is transferred between NHIOs, not as it is stored in an NHIO. An NHIO may store clinical data in whatever format or repository it chooses, so long as the NHIO can respond to queries as described in this interface, and respond to “retrieve document” requests as described in the “Retrieve Documents Service Interface specification [|[1]]. The primary assumption in the context of the NHIN is that documents are formatted as XML data following the HL7 Clinical Document Architecture (CDA) standard, but nothing precludes this interface from being used to query for other kinds of documents, such as Adobe Portable Document Format files or images.

3.2 Design Principles and Assumptions
The following assumptions or design principles underlie this specification: · The means by which an NHIO determines which other NHIOs to direct queries is not specified. This is a local NHIO decision. · An NHIN Gateway directs a query to other individual NHIOs. This specification does not define a central or federated service that performs transactions across multiple NHIOs. · An authorization decision evaluates each request against local consumer preferences and local polices and permissions to determine which document(s) can be made available for retrieval. · Patient Identifiers (PIDs), once shared with another NHIO will NEVER be reassigned to another person.

NHIN Query for Documents allows an Initiating Gateway to query a Responding Gateway for a list of patient specific documents which meets query parameters.

3.3 Transaction Standard
NHIN Query for Documents utilizes the IHE Cross Community Access (XCA) ITI-38: Cross Gateway Query transaction, which is part of HITSP TP13. The XCA Profile is an addendum to the complete IHE IT Technical Infrastructure Technical Framework (ITI-TF). The location of these documents, as well as other foundational standards for this transaction, is listed in Section 1.4 “Referenced Documents and Standards”. The XCA ITI-38 specification has been relaxed within this NHIN specification as needed to support the query for, and retrieval of, dynamically generated document content. As described further in sections 2.6 “Technical Post-conditions” and 3.3 “Query Parameters”, for documents whose creation has been deferred until retrieve time, the metadata values for document hash and document size are not required to be the actual hash and size of the later retrieved document, as mandated by XCA. In addition availabilityStatus=”urn:ihe:iti:2010:StatusCode:DeferredCreation” is used to identify this special status. This modification to XCA is expected to be adopted by IHE at some future time. A WSDL for the Responding Gateway actor and a full XML Schema can be accessed via a URL provided in Appendix B of this document.

NHIN Query for Documents adopts IHE’s ITI-38, which in turn references and relies upon several other standards and profiles. The [Rich K1]  lists and illustrates the relationships among the primary documents which define the underlying standards for this transaction. The location of these documents, as well as other foundational standards for this transaction, is listed in Section X.X “Referenced Documents and Standards”.

The standards and protocols specified for this transaction were developed by several different standards organizations. They and are defined in upwards of 100 pages of reference material across a multitude of documents, which successively build upon one another. In an effort to increase implementer ease of use, the authors of this document have endeavored to provide a walkthrough of transaction components, as well as an explanation and context as source material is referenced. ====

====

==== ====   [Rich K1]  If anyone has a better idea for the section title or better diagram, I am all ears ===

[|[1]] Note that to maintain compliance with HITSP constraints, the document hash value must be consistent between the document query transaction and the document retrieval transaction. See sections 3.3 “Query Parameters” and 2.6 “Technical Post-conditions” for more details. ===