<H3>Special Instructions</H3><p> <p>None</p> </p> <H3>Description</H3> <p>The PDQv3_Multiple_Query test requires PDQ Consumers to send different types of queries to a PDQ Supplier. Some PDQ Consumers may not have user interfaces that support all of the intended queries.</p> <p>Each query (Using the HL7v3 Patient Registry Find Candidates Query) is made assuming a single domain Assigning Authority that can be specified with an empty value in the DataSource.value attribute. The syntax of wild card queries is not specified by the IHE Technical Framework. There may be some negotiation between Consumer and Supplier actors.</p> <H3>Evaluation</H3> <p>Connectathon monitor should observe all queries in real  time and evaluate response. PDQ Consumer should demonstrate configuration/logs  indicating the PDQ Supplier that is queried.</p> <p> PDQ Supplier does not need to demonstrate any results  unless there are problems. In that case, access to logs would be helpful.</p> <p>The PDQ Supplier is required to support queries with the  attributes listed below.  Not all  Consumers will support all queries. Evaluate as many query combinations as are  supported by the Consumer.</p> <ul>     <li> <em>LivingSubjectId</em> </li>     <li> <em>LivingSubjectName</em> </li>     <li> <em>LivingSubjectBirthTime</em> </li>     <li> <em>LivingSubjectAdministrativeGender</em> </li>     <li> <em>Patient.Address</em> </li>     <li> <em>OtherIDsScopingOrganization (ie the Assigning Authority)</em> </li> </ul><p>The PDQ Supplier is required to support at least all exact  matches to the query parameters sent by the Consumer.  The Technical Framework does not further  specify matching requirements (eg wildcards, upper and lower case, alternate  spellings')  </p><p> <strong>We especially  want to see the query result that uses the Kudu name of the demographics  supplier. This will help to show the monitor you are sending a query to the  proper system.</strong>  </p> 