Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Content of the Protocol Terminators

Page Tree
root@none
sortcreation
searchBoxtrue

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
titlePlease 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

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
titleCommon
Status
colourYellow
titleConsent Service
Status
colourGreen
titleDispensation Service

Test #1 : "

testQueryNoConsent

testQueryNoEP"

Test IdPT_CLIENT_XCAXDR_#4#1
NametestQueryNoConsent

testQueryNoEP

Description

(ERROR)

No matching ePrescription was found.

Test InputsA request for a patient which has not given any consenteDispensation submitting action for an nonexistent ePrescription.
Expected Results

Response Status: Failure

Message: No ConsentMatch
Code: 47014105
Last Passed Date
Status
colourRed
titleN/A


Test #X : "testXXXX"

Test Numberx
NametestXXXX
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 ResultsN/A
Last Passed Date
Status
colourRed
titleN/A