Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Content of the Protocol Terminators
Page Tree | ||||||
---|---|---|---|---|---|---|
|
XDR Client Integration Testing
This page tries to gather all the specification of Integration testing for the XDR client component, including several aspects such as the description, inputs, results and last passed date.
Note |
---|
Work in progress! |
Note | ||
---|---|---|
| ||
These test definitions match the code implementation. The same Id and Test Name is used in method definitions. Please follow the same convention and remember to reflect the code changes in these tables and vice-versa. For each new test please add a new table and keep it updated. |
Initial Information
Consent
If the epSOS Consent Service provider is able to decode the received consent document IDs but the deprecating of the consent document failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
The response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. A failure location MUST NOT be given. The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element.
epSOS Consent Service allows for all of the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF - 3].
eDispensation
If the epSOS Dispensation Service provider is able to decode the received message but the processing of one or more dispensations failed, it responds with an ebXML Registry response That contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
If none of the eDispensations was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If at least one EDispensation was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”.
A failure location MUST be provided if the error does not apply to all provided eDispensation documents. It MUST NOT be given if the error applies to all provided documents.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element.
Tests
Table Color
Status | ||
---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Test #1 : "testQueryNoConsent"
Test Id | PT_CLIENT_XCA_#4 | ||||||
---|---|---|---|---|---|---|---|
Name | testQueryNoConsent | ||||||
Description | (ERROR) No matching ePrescription was found | ||||||
Test Inputs | A request for a patient which has not given any consent. | ||||||
Expected Results | Response Status: Failure | ||||||
Message: No Consent | |||||||
Code: 4701 | |||||||
Last Passed Date |
|
Test #X : "testXXXX"
Test Number | x | ||||||
---|---|---|---|---|---|---|---|
Name | testXXXX | ||||||
Description | Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam fermentum vestibulum est. Cras rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. | ||||||
Test Inputs | Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam fermentum vestibulum est. Cras rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. | ||||||
Expected Results | N/A | ||||||
Last Passed Date |
|