This test applies to responders to the [ITI-78] Patient Demographics Query for Moblie transaction:   Patient Demographics Suppliers in the PDQm Profile or Patient Identity Registry in the PMIR Profiles

This test is performed with the Patient Manager simulator https://gazelle.ihe.net/PatientManager acting as a Patient Demographic Consumer to initiate these queries.  

Test set up

There is no prerequisite in terms of data to be load into your system. As such, choose relevant values for the various parameters based on the patient demographics known by your system under test so that matches are returned.

First of all, register your system under test within the tool as a FHIR Responder under SUT Configurations > FHIR Responders. Make sure to select IHE => ITI-78 (PDQm Consumer) in the list of usages.

Access the Patient Demographics Consumer for PDQm in Patient Manager from menu PDQ* > Patient Demographics Consumer > [ITI-78] Patient Demographics Query FHIR.

Evaluation

Verify the conformance of each response issued by your system (blue play icon in the "response" column) and copy the permanent link to the message in your pre-connectathon test in Gazelle Test Management (available from the magnifying glass icon).  Also verify that the response format expected in the query matches the response format (XML vs JSON) returned by your system. 

Steps to execute

Capability Statement

Upload the capability statement of your system (showing at least the PDQm Supplier features) in the pre-connectathon test in Gazelle Test Management.

Query for a patient pick list

For this first step, we assume that the consumer actor 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 test the behavior of your system:

• Partial or complete patient name (given and/or family)
• One or more Patient identifiers
• Date of birth or age range
• One or more contact points (phone number, email etc)
• Partial or complete address
• Gender
• Whether you want to fetch inactive patients as well

Note that for parameters of type string, "exact" modifier will be added to the query if the wildcard is not used in the field (when valued). If you want to search of patients with a given starting with Ro, enter Ro* in the form.

If your system supports the Pediatric Demographics Option, you might also want to make sure that your system supports the mothersMaidenName search extension.

For this step, you are asked not to modify the default parameters in the "Additional information" section of the page.

Once you have flll out the form, push the "Send message" button. If matches are returned by your system, they will be displayed at the bottom of the page.

After you have retrieved a first batch of patients. You should also be able to use the resource ID search parameter (_id). You can find the value to use in the response returned by your system in Bundle.entry.resource.Patient.id.value.

Response encoding

Your system under test shall be able to support at least both JSON and XML encodings. Previous step has been executed using "XML" as format to be returned. Return the step above at least one but select Response format = json before sending the message to your system.

Retrieve patient

Access the detail of the response content and for one of the entries, access the URL displayed in field entry.fullUrl.value. You should retrieve the content of the Patient resource.

No Match

Send a new query to your system under test, make sure the query parameters do not match any patient in your database. Your system is expected to send back a Bundle resource with Bundle.total.value = 0.

Query for patient with identifiers in other domains

In this step, we focus on the domain restriction feature. We assume that your system manages at least one domain for patient identification.

Query with no domain

First, choose a combination of parameters that will return at least one patient. If your system supports multiple identifier domains, make sure the returned patients will show at least identifiers from two different domains. DO NOT restrict the search to a particular domain. We are interested in knowing what are the identifiers known for this patient.

Query with a known domain

Repeat the search below but in the "Additional information" section, add the identifier of one of the domains for which the returned patient has a PID assigned. Click on "Add domain to list" for the tool to take the value into account.

Your system is expected to return the patients that are a PID assigned to this domain, only one PID shall appear for each of them.

Query with more than one domain

If your system supports more than one domain, repeat the operation above to add a second domain in the list of domains that are returned.

Once again, your system is expected to return the patients with PID in the mentioned domains. No other PID shall be returned.

Query for an unknown domain

Repeat the test but first clean up the list of domains to return and add "1.3.6.1.4.1.21367.13.20.9999"  instead (this domain might not be known by your system, otherwise choose another value).

No entry shall be returned. Refer to section 3.78.4.1.3 / Case 4 for details on the expected response (Code HTTP 404 with OperationOutcome or HTTP 200 with no content).

Paging

The Patient Demographics Supplier shall represent the incremental responses as specified in FHIR Paging. 

Empty the query form and enter parameters that will allow your system to match more than two patients. 

In the "Additional information" section, check the box for option "Limit number of responses" and set the limit value to "1".

Click on "Send message", the tool shall display the single entry that is returned by your system and the following message "More results are available on supplier side". As for the other steps, copy the link to this message in Gazelle Test Management.

Click on "Get next results".

In the "Returned patients" section, the number of pages increases. A single patient is displayed.