This test applies to initiators of the [ITI-78] Patient Demographics Query for Mobile transaction:  Patient Demographics Consumers in the PDQm or PMIR Profiles.

This test is performed with the Patient Manager simulator https://gazelle.ihe.net/PatientManager acting as a Patient Demographic Supplier to  response to PDQm queries.  

Test step up

The list of patients available on the supplier side are available under the Patients menu. Select "simulated actor" = "PDS" to see which one can be returned in a PDQm query response.

The endpoint to contact is available under menu PDQ* > Patient Demographics Supplier> FHIR configuration.

Evaluation

Verify the conformance of each query issued by your system (blue play icon in the "query" column) and copy the permanent link to the message in your pre-connectathon test in Gazelle Test Management (available from the magnifying glass icon). 

The messages received by the simulator are available under HL7 Messages. To restrict the search, either access the page using the "history" icon on the FHIR Configuration page, either sent the following filters in the search criteria panel:

• Simulated actor = PDS - Patient Demographic Supplier
• Transaction = ITI-78 - Mobile Patient Demographics Query

Steps to execute

Not all the following test cases might be of relevance for your system under test. The purpose of this test is to make sure you correctly implement the portions of the specifications which are of interest for your system (based on the use cases it supports).

Query for a patient pick list

For this first step, we assume that the operator wants to retrieve a list of patients based on some demographics traits. You might want to repeat this step with various combinations of parameters among the following ones to see how the supplier understand your query:

• given and/or family: Partial or complete (exact) patient name (you might have the ability to provide the various given names of the patient)
• identifier: One or more Patient identifiers
• birthdate: Date of birth or age range (your system might allow you to input the exact birth date or a date interval)
• telecom: One or more contact points (phone number, email etc)
• address (or address-city, address-country, address-postalcode, address-state): Partial or complete address
• gender: The gender of the patient
• active: Whether you want to fetch inactive patients as well - By default the simulator will only send back active records if not otherwise requested in the query
• _id: Patient resource's id - The simulator uses the UUID field displayed in the GUI as resource's ID
• mathersMaidenName: Mother's maiden name if your system supports the Pediatric Demographics Option.

For each query, your system should at least display the number of retrieved entries and some of the demographic traits for each entry in the list.

Note that queries with no search parameter will return no entry at all.

Response encoding

If your system supports both JSON and XML encoding, repeat at least once of the previous query with the second encoding so that you can verify that your system correctly set the requested encoded. You might use the HTTP header or the _format query parameter.

Retrieve patient

In addition to the query feature, your system shall support the retrieve patient feature. Choose one patient out of the list and directly retrieve the associated resource by performing the retrieve operation.

Example: https://gazelle.ihe.net/PatientManager/fhir/Patient/UUID.

No Match

Send a new query to your system under test, make sure the query parameters do not match any patient in the tool. Your system is expected to inform the final user that no match has been found.

Query for patient with identifiers in other domains

You must execute the steps below if your system is able to constrain the domains from which patient identifiers are returned from the Patient Demographics Supplier. 

Query with no domain

If you can turn off the domain restriction in your system. First, choose a combination of parameters that will return at least one patient with identifiers in several domains. Under the Connectathon > Patient Demographics menu, you will find the patients that will be pre-loaded by suppliers during the Connectathon; they are also known by the Patient Demographics Supplier implemented in the tool. Each patient has an identifier in at least four domains.

Your system shall receive the patient(s) with identifiers in the IHEBLUE, IHEFACILITY, IHEREF and IHEGREEN domains at least.

Query with a known domain

Reuse the same query parameters as for the previous test but restrict the domain to the IHEBLUE (urn:oid:1.3.6.1.4.1.21367.13.20.3000) domain.

If your query is correctly formatted, the returned patient(s) should only have identifiers with system = urn:oid:1.3.6.1.4.1.21367.13.20.3000.

Query with more than one domain

If your system supports more than one domain, repeat the operation above: constraint the identification domain to IHEBLUE and IHERED (urn:oid:urn:oid:1.3.6.1.4.1.21367.13.20.1000).

Once again, if your query is correctly formatted, the returned patient(s) should only have identifiers with system urn:oid:1.3.6.1.4.1.21367.13.20.3000 and urn:oid:1.3.6.1.4.1.21367.13.20.1000.

Query for an unknown domain

Reuse the same query parameters once again and restrict the domain to urn:oid:1.3.6.1.4.1.21367.13.20.9999999. This domain is unknown from the Patient Demographics Supplier.

If your query is correctly formatted, you should receive HTTP 404 error code with an OperationOutcome resource in which the unknown domain is precised. You might or might not give feedback on such error to the final user. No entry shall be displayed to the user (none will be returned by the Patient Demographics Supplier).

Paging

Execute this step if your system supports the paging mechanism, meaning that it can add the _count parameter to the query. In this step we assume that the user is able to set the number of records to fetch at one time. If your system does not provide this ability (default quantity, or quantity to choose from a list), simply adapt the test data below.

Set search parameters in a way that they will select at least 3 entries (usually given=rob is a good candidate) and ask for only two records at a time. If your query is correctly formatted, the received Bundle should contain only 2 entries and 

• A link to the next results (2 or less);
• A total number of results higher to 2.

Ask for the next batch of results. You should be able to see at least one more patient.