Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Content of the Protocol Terminators

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.

Work in progress!

Please 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

COMMONCONSENT SERVICEDISPENSATION SERVICE

Test #1 : "testQueryNoConsent"

Test IdPT_CLIENT_XCA_#4
Name

testQueryNoConsent

Description

(ERROR)

No matching ePrescription was found

Test InputsA request for a patient which has not given any consent.
Expected Results

Response Status: Failure

Message: No Consent
Code: 4701
Last Passed DateN/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 DateN/A
  • No labels