Query+for+Documents+Page+3

4 Interface Definition
This section details the components of the NHIN Query for Documents transaction, providing details regarding message semantics, examples of syntax and sample messages, and some other stuff.

4.1 Overview of XCA
The Cross-Community Access (XCA) profile supports the means to query and retrieve patient relevant medical data held by other communities. A community is defined as a coupling of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing clinical information via an established mechanism. A community is identifiable by a globally unique id called the homeCommunityId. NHIN Query for Documents utilizes the IHE Cross Community Access (XCA) ITI-38: Cross Gateway Query transaction, which is part of HITSP TP13. The Cross Gateway Query transaction is described in IHE ITI XCA Supplement Section 3.38. Figure 1.1 below illustrates the actors and transactions involved in the ITI-38 Cross Gateway Query transaction. Note that the diagram represents the Initiating Community (NHIO in this context) as an IHE XDS-based community. The NHIN Query for Documents transaction does not require the XDS architecture; it is merely presented in the diagram for illustrative purposes. A sample query and response is provided in Appendix A “Sample Messages”.

4.2 Transaction Components
NHIN Query for Documents consists of an AdhocQueryRequest and AdhocQueryResponse, as documented in ebXML Registry Services and Protocols sections 6.3.2 and 6.3.3 respectively. As the Standards Documentation diagram in Section X.X suggests, the ebRS AdhocQuery protocol is foundational to ITI-18, ITI-38, and NHIN Query for Documents, which successively elaborate its use. The terminology used to describe transaction components varies with each successive document. As a reference, the terminology used in each referenced standard is provided below [|[Rich K1]] ebRS 3.0 - AdhocQueryRequest / Response ITI-18 – Registry Stored Query / Acknowledgement ITI-38 – Cross Gateway Query / Response NHIN – Query for Documents Query / Response

4.2.1 AdHocQuery Request (Registry Stored Query)
Rather than exchange actual query expressions, this transaction makes use of a collection of pre-defined, parameterized stored queries. Each stored query is identified by a Query Name and Query ID and is associated with a specified set of query parameters. The list of standard XDS queries available for this transaction as defined in Section 3.18.4.1.2.4 of ITI TF-2a and is provided below. [|[Rich K2]] NHIN intends that responding NHIN Gateways shall support all of the stored queries listed, however, some stored queries rely on concepts which may not be supported within an NHIO (IHE community). It is also possible that a Responding Gateway community may have policies which restrict the sharing of information related to those concepts. The concepts of concern are submission sets, folders and associations. In either case, a Responding Gateway shall respond to unsupported stored queries by returning zero results.
 * ** Query Name ** || ** Query ID ** ||
 * FindDocuments ||  urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d  ||
 * FindSubmissionSets ||  urn:uuid:f26abbcb-ac74-4422-8a30-edb644bbc1a9  ||
 * FindFolders ||  urn:uuid:958f3006-baad-4929-a4de-ff1114824431  ||
 * GetAll ||  urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3  ||
 * GetDocuments ||  urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4  ||
 * GetFolders ||  urn:uuid:5737b14c-8a1a-4539-b659-e03a34a5e1e4  ||
 * GetAssociations ||  urn:uuid:a7ae438b-4bc2-4642-93e9-be891f7bb155  ||
 * GetDocumentsAndAssociations ||  urn:uuid:bab9529a-4a10-40b3-a01f-f68a615d247a  ||
 * GetSubmissionSets ||  urn:uuid:51224314-5390-4169-9b91-b1980040715a  ||
 * GetSubmissionSetAndContents ||  urn:uuid:e8e3cb2c-e39c-46b9-99e4-c12f57260b83  ||
 * GetFolderAndContents ||  urn:uuid:b909a503-523d-4517-8acf-8e5834dfc4c7  ||
 * GetFoldersForDocument ||  urn:uuid:10cae35a-c7f9-4cf5-b61e-fc3278ffb578  ||
 * GetRelatedDocuments ||  urn:uuid:d90e5407-b356-4d91-a89f-873917b4b0e6  ||

The stored queries listed above are either “Find” or “Get” and target documents, submission sets, folders, and associations. The Find and Get All queries return registry objects for a given patient ID and status code. The remaining Get queries generally rely on unique object IDs (rather than Patient IDs) to locate registry objects.

4.2.2 Message Semantics
NHIN Query for Documents adopts Cross Gateway Query (ITI-38), which inherits message semantics from Registry Stored Query (ITI-18), which inherits message semantics from AdhocQuery Request. AdhocQuery message semantics are defined in Section 6.3.2 and 6.3.3, respectively of ebXML Registry Services and Protocols (ebRS) version 3.0, published by OASIS. ** [Spec Table] ** Message semantics are elaborated in much greater detail throughout the components of Section 3.18.4.1.2 of IHI TF-2a. Portions of that material are included below, but should not be considered as a substitute for a careful review of the reference documentation. ** [Spec Table] **

4.2.2.1 Query Request Parameters
Query Request Parameters are those which pertain to the request and should be distinguished from Query Parameters, which are those which pertain to the query itself. Parameters to be included in Stored Query Requests are described below. 1. **returnComposedObjects** - This optional parameter specifies whether the RegistryObjects returned should include composed objects as defined by Figure 1 in [ebRIM]. The default is to return all composed objects.

2. **returnType** – ‘LeafClass’ or ‘ObjectRef’

The ‘LeafClass’ return type is intended for use when anticipating the return of a small number of fully specified registry objects. This type of query result is self-contained, everything known about the object(s) is returned. As such, is not appropriate for queries which anticipate the return of hundreds of objects. Additionally, ObjectRefs (UUIDs) may also be returned. These represent objects that are referenced by, but not included among objects in the returned list.

The ‘ObjectRef’ return type returns references (UUIDs) to registry objects matching the query. This type is recommended when the returned list could be large, as far less data per object is returned. ObjectRef can be used to manage queries in which the return of hundreds or thousands of objects is anticipated. To construct a page for display, a small subset of the referenced objects can be retrieved via a second query and repeated for each page. Refer to IHE TF-2a: 3.18.4.1.2.6 for examples.

3. **QueryID** – A UUID from among those defined for each Stored Query in Table X.

4. **Query Parameters** – parameters from among those in the set associated with each Stored Query. Parameters for each Stored Query are detailed in section 3.18.4.1.2.3.7 of ITI TF-2a

4.2.2.2 Query Request Parameter Coding
Specific information detailing the coding style for Date/Time, Code/Code-Scheme, and the coding of multiple values is presented in Sections 3.18.4.1.2.3.3 – 5 of ITI TF-2a. [spec table?]

4.2.2.3 Home Community ID
A community (NHIO) is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community. The following information is included in the IHE XCA profile to define the use of the homeCommunityId. NHIN specific annotations are included in square brackets: · The homeCommunityId is a globally unique identifier for a community used to assist in subsequent requests for locating the data held by that community. homeCommunityId is structured as an OID limited to 64 characters and specified in URI syntax, for example the homeCommunityId of 2.16.840.1.113883.3.166 would be formatted as urn:oid: 2.16.840.1.113883.3.166. · [Each NHIO shall use the homeCommunityId of the form “urn:oid:n.n.n.n” using a globally unique OID assigned to the NHIO when responding to a Cross Gateway Query. The Initiating Gateway is expected to use this homeCommunityId to correlate a subsequent Retrieve Document request with the HIO that holds the requested data.] · It is returned within the response to Cross Gateway Query to indicate the association of a response element with a community. It is specified as the ebRIM home attribute within the relevant response elements. Document Consumers process the value in the response as an opaque unique identifier. · It is used by Initiating Gateways [when retrieving documents] to direct requests to the community where the data originated. 

4.2.2.4 Find Documents Query
FindDocuments queries a repository for Documents with a matching PatientID and Status attributes. The remaining parameters are optional and can be used to restrict the set of documents returned. Each of the parameters listed below correspond to XDS Metadata attributes, which are detailed in ITI TF-3, Table 4.1-5.

4.2.2.4.1 Query Parameters
IHE ITI-18 defines 13 Stored Queries and the query parameters associated with each. Among those 13 Stored Queries, it is anticipated that FindDocuments will be the primary query to be used in the NHIN Query for Documents transaction. A detailed overview and implementation guidance for the FindDocuments query is contained in this section. Information pertaining to the remaining 12 Stored Queries can be found in ITI-18: 3.18.4.1.2.3.7.

4.2.2.4.1.1 Patient ID
The Patient ID (PID) is the technical identifier used to represent the subject (patient) for whom documents are sought. This identifier shall originate from an Assigning Authority Domain supporting the NHIO. This specification **//does not//** constrain who the Assigning Authority is, whether it is the same as the Home Community ID, whether more than one might be utilized within an HIO, or whether a given Assigning Authority may be referenced by more than one HIO. The Patient ID shall contain two parts: Within the query request and response, these components of the patient ID are to be specified in the HL7 CX format, which is described in Volume 3 of the IHE ITI Technical Framework Section 4.1.7 Table 4.1-3. The HL7 CX data type consists of several components, but this specification allows the use of only two: ID Number, and Assigning Authority (AA). The Assigning Authority identifies the "domain" over which the ID Number represents a unique entity and is represented using a Universal ID and Universal ID Type, which must be ISO. The required format is: ‘ IDNumber^^^&OIDofAA&ISO’. No other values/modifications in other components or subcomponents are allowed. In the context of the NHIN, these values are exchanged during Patient Discovery; the Assigning Authority is the //root// of the patient identifier and the Patient ID is the //extension.// An explicit example is: ‘ 543797436^^^&1.2.840.113619.6.197&ISO’. Note that the '&' character must be properly encoded and the patient identifier must be surrounded by single quotes.   'd8420442513945d^^^&amp;1.3.6.1.4.1.21367.2005.1.1&amp;ISO'  
 *  Patient Identity Assigning Authority in the form of an OID
 *  An identifier in the above Assigning Authority domain

=** 4.2.2.4.1.2 Status Code **= The allowed values for the $XDSDocumentEntryStatus parameter are: urn:oasis:names:tc:ebxml-regrep:StatusType:**Submitted** urn:oasis:names:tc:ebxml-regrep:StatusType:**Approved** urn:oasis:names:tc:ebxml-regrep:StatusType:**Deprecated** urn:ihe:iti:2010:StatusCode:**DeferredCreation** The DeferredCreation value is an extension to ITI-38. It supports the query for, and retrieval of, dynamically generated document content. Such a document may be included in the list of returned objects, but is not actually created until such time as it is retrieved via an NHIN Retrieve Documents transaction.

4.2.2.4.1.3 Remaining Parameters
Efficient document searches can best be facilitated by limiting search parameters to a few elements, each with a coarse granularity. Beyond the required PatientID and Status attributes, the following elements are recommended as the primary query parameters:
 *  **Class Code** –specifies the particular kind of document (e.g., Prescription, Discharge Summary, Report, etc.). This value set is comprised of LOINC codes and is defined in Table 2-144 in HITSP C80 V2.0.1, which has been reproduced in Appendix X.x of this document.
 *  **Practice Setting Code** – specifies the clinical specialty where the documented act was performed (e.g. Family Practice, Laboratory). This value set is comprised of SNOMED CT codes and is defined in Table 2-149 of HITSP C80 mV2.0.1, which has been reproduced in Appendix x.x of this document.
 *  **Healthcare Facility Type** – specifies the type of organizational setting in which the documented act was performed. This value set is compromised of a set of SNOMED CT codes and is defined in Table 2-147 in HITSP C80 V2.0.1, which has been reproduced in Appendix X.x of this document.
 *  **Document Creation Time –** represents the time the author created the document. Format and syntax are defined in Table 4.1-5 in ITI TF Volume 3.

Table X.x, reproduced from IHE ITI TF 2a: 3.18.4.1.2.3.7.1 contains a complete list of FindDocuments query parameters. For more detailed information, refer to Table 4.1-4 in ITI TF Vol3.
 * ** Parameter Name ** || ** Attribute ** || ** Opt ** || ** Mult ** ||
 * $XDSDocumentEntryPatientId ||  XDSDocumentEntry. patientId  ||  R  ||  --  ||
 * $XDSDocumentEntryStatus ||  XDSDocumentEntry. status  ||  R  ||  M  ||
 * $XDSDocumentEntryClassCode1 ||  XDSDocumentEntry. classCode  ||  O  ||  M  ||
 * $XDSDocumentEntryPracticeSettingCode1 ||  XDSDocumentEntry. practiceSettingCode  ||  O  ||  M  ||
 * $XDSDocumentEntryHealthcareFacilityTypeCode1 ||  XDSDocumentEntry. healthcareFacilityTypeCode  ||  O  ||  M  ||
 * $XDSDocumentEntryCreationTimeFrom ||  Lower value of XDSDocumentEntry. creationTime  ||  O  ||  --  ||
 * $XDSDocumentEntryCreationTimeTo ||  Upper value of XDSDocumentEntry. creationTime  ||  O  ||  --  ||
 * $XDSDocumentEntryTypeCode1 ||  XDSDocumentEntry.typeCode  ||  O  ||  M  ||
 * $XDSDocumentEntryServiceStartTimeFrom ||  Lower value of XDSDocumentEntry. serviceStartTime  ||  O  ||  --  ||
 * $XDSDocumentEntryServiceStartTimeTo ||  Upper value of XDSDocumentEntry. serviceStartTime  ||  O  ||  --  ||
 * $XDSDocumentEntryServiceStopTimeFrom ||  Lower value of XDSDocumentEntry. serviceStopTime  ||  O  ||  --  ||
 * $XDSDocumentEntryServiceStopTimeTo ||  Upper value of XDSDocumentEntry. serviceStopTime  ||  O  ||  --  ||
 * $XDSDocumentEntryEventCodeList1 ||  XDSDocumentEntry. eventCodeList3  ||  O  ||  M  ||
 * $XDSDocumentEntryConfidentialityCode1 ||  XDSDocumentEntry. confidentialityCode3  ||  O  ||  M  ||
 * $XDSDocumentEntryAuthorPerson4 ||  XDSDocumentEntry. author  ||  O  ||  M  ||
 * $XDSDocumentEntryFormatCode1 ||  XDSDocumentEntry. formatCode  ||  O  ||  M  ||
 * $XDSDocumentEntryFormatCode1 ||  XDSDocumentEntry. formatCode  ||  O  ||  M  ||

4.2.3 AdHocQuery Response (Registry Stored Query)
A responding NHIO will respond to a FindDocuments (or other Registry Stored Query request) with a list of available documents. If the returnType on the query request was ObjectRef, the responder will return references (UUIDs) to available documents matching query parameters. If the returnType was LeafClass, the responder will return a list of documents with fully specified document metadata.

4.2.3.1 Message Semantics
NHIN Query for Documents adopts Cross Gateway Query (ITI-38), which inherits message semantics from Registry Stored Query (ITI-18), which inherits message semantics from AdhocQuery. AdhocQuery message semantics are defined in Section 6.3.2 and 6.3.3, respectively of ebXML Registry Services and Protocols (ebRS) version 3.0, published by OASIS. ** [Spec Table] ** Message semantics are elaborated in much greater detail throughout the components of Section 3.18.4.1.2 of IHI TF-2a. Portions of that material are included below, but should not be considered as a substitute for a careful review of the reference documentation.

4.2.3.1.1 Response Parameters
ResponseStatusType – indicates the status of the request and contains the following values: · Success – indicates that the request was successful · Failure – indicates that the request encountered a failure. One or more errors MUST be included in the RegistryErrorList · Unavailable – indicates that the response is not yet avaiaoble. [|[Rich K5]] – specifies the ID of the request for which this is the response. It must match the AdhocQueryID included in the query request. Sample Query Request The following NON NORMATIVE example specifies: · The LeafClass returnType · The FindDocuments query ID   · patientID st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO · Return Approved documents only · Time range (creation time) 200412252300 to 200501010800 · Healthcare Facility Type Code of Emergency Department Note: request parameters and query parameters have been highlighted in green and yellow, respectively.  <query:AdhocQueryRequest <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <query:ResponseOption returnComposedObjects ="true" returnType ="LeafClass"/> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <rim: AdhocQuery id ="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <rim:Value>’st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO’</rim:Value> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:ValueList> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:Slot> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <rim:Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</rim:Value> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:ValueList> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:Slot> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <rim:Value>200412252300</rim:Value> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:ValueList> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:Slot> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <rim:Value>200501010800</rim:Value> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:ValueList> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:Slot> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> [|[Rich K6]]  "> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;">  <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> <rim:Value>(‘Emergency Department’)</rim:Value> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:ValueList> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:Slot> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </rim:AdhocQuery> <span style="background: #f2f2f2; display: block; margin: 0in 0in 0pt; mso-background-themecolor: background1; mso-background-themeshade: 242; tab-stops: 8.65pt 17.3pt 25.9pt 34.55pt .6in;"> </query:AdhocQueryRequest>

[|[Rich K1]] Need table

[|[Rich K2]] Lets discuss

[|[Rich K3]] Need Karen/John to show me where the Get queries are required to be for a single patient.

[|[Rich K4]] Need Karen/John to show me where the Get queries are required to be for a single patient.

[|[Rich K5]] Need smart person to validate

[|[Rich K6]] Should include the SNOMED code from the c80 value set, correct 73770003?