Query+for+Docs+Page+2

= =  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]. 2 Interface Description

2.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. 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. Any HIO 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]] . Specifically, a “document” transferred between NHIOs need not meet the criteria for persistence, stewardship, etc. as identified by the HL7 Structured Documents committee.

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. (irrelevant)

2.2 Triggers
After having obtained a Patient Identifier (PID), an NHIO edge system submits a query to its NHIO’s NHIN Gateway (the format of that query is outside the scope of this specification). In turn, the NHIN Gateway sends a query in the specified format to the NHIO Gateway correlated with the PID – specifically to the service endpoint, as identified in the NHIN service registry. The query includes the target patient identifier and, optionally, other constraining metadata. For further details regarding query parameters and metadata, see section 3.3 “Query Parameters”.

2.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.

2.4 Design Principles and Assumptions
The following assumptions or design principles underlie this specification: · How 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.

2.5 Technical Pre-Conditions
The following technical pre-conditions exist for this interface specification: · The NHIO(s) to which the query will be directed have been selected and applicable service end points have been identified. · The identifier for the patient as assigned by the each respondent NHIO’s assigning authority has been acquired through some verifiable means, primarily through use of the Patient Discovery. It is recommended that a patient identifier be re-discovered through the Patient Discovery Specification at least as often as every encounter prior to use in a document query. · The patient has provided their consent to share their information.

2.6 Technical Post-conditions
The following technical post-conditions will result after the execution of this interface specification: · Audit records are created and stored by both the requesting and responding NHIO, as described in section 5 “Auditing”. · Consumer preferences and local policies and permissions were enforced by the responding NHIO. - Only those documents available to the requestor are included in the list - If the requester was not authorized to view a list of documents, appropriate errors were returned. · The response to this query is a collection of Document IDs referring to available documents, and some metadata describing each. - These references may be used in the Retrieve Document transaction, as described in the NHIN Retrieve Documents specification. - These document references are valid for a limited duration (the timeframe of which is determined by the implementation of a particular HIO), and, if the document reference is ever the subject of a successful Retrieve Document transaction, it will persist forever. The intention here is to persist documents that have been actually retrieved across the NHIN, but not persist documents that have never been retrieved (this is important to those HIOs that may dynamically generate documents). · Part of the document metadata that is returned in the response to this message includes a hash value of the actual document. It is required that the hash value of the document be computed either before or during this query transaction so that it may be returned as part of the query. Document Consumers may use this hash value to assess the validity of retrieved documents. - In the event that the document hash and/or size are not known at the time of query because the creation of the document is being delayed until a retrieve is received, availabilityStatus=”urn:ihe:iti:2010:StatusCode:DeferredCreation” and -1 for hash and size may be used to indicate this state; further explanation is provided in sections 2.3 “Transaction Standard” and 3.3 “Query Parameters”. **Previous Page Next Page**
 * Errors encountered will be handled, as specified in Section 4 “Error Handling”.

[|[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.