TestSuite description GetRheumatoidArthritisData

This testsuite is used to verify the implementation of GetRheumatoidArthritisData prior to integration with the national platform.


  • For testing NPÖ-compliant systems, set <validateNPO> to true, else false.
  • If a testcase, e.g. the HTTPHeader-filtering testcase, is deemed not applicable for a certain producer, note it as N/A with an explanatory comment.

Global variables used
  • webServiceUrl
  • validateNPO

Tools

SoapUI

The testsuite uses SoapUI to verify the implementation. Documentation of SoapUI can be found at http://www.soapui.org
Link to download site: http://sourceforge.net/projects/soapui/files/soapui/
Install SoapUI according to the documentation.

Setup instructions

  1. Locate the test-suite/[contractName]-directory in your distribution.
  2. Copy the jar-file ‘soapui-support.jar’ to <SoapUI install dir>/bin/ext
  3. Open SoapUI and import the SoapUI project from the above directory, choose ‘Import Project’ from the File-menu.
  4. If your WebService endpoint requires a SSL Certificate, this can be configured from the Preferences (in the File menu). In the Preferences window open the ‘SSL Settings’ tab and import the Keystore containing the Client Certificate.
  5. Update test-data in data.xml to match the contents in your system.
  6. You should now be able to run the test suite!

Testcases

BasicTestcase

Verifies that the response is schema- and schematron- valid and contains data for the requested patient only.
The only requirement on test data is that there is some data for the given patientId. It might be a good idea to start by executing this testcase for a patient with a very simple response and when that works switch to a patient with more complex data.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType

DateBoundaries

Verifies that the result only contains information that was valid within the date boundaries for the given patient. The rule is:

"Begränsning av sökningen i tid, vilket innebär att endast svar där giltighetsintervallet ligger helt eller delvis inom efterfrågat tidsintervall returneras. Giltighetsintervallet startar vid validityTimePeriod.start och slutar vid tidigaste datum av obsoleteTime och validityTimePeriod.end om någon av dessa är satta, annars tills vidare.”

Additional information about failed assertions can be found in the script log.

  1. An element with validityTimePeriod.start before the given range, no validityTimePeriod.end, no obsoleteTime.
  2. An element with validityTimePeriod.start within the given range, no validityTimePeriod.end, no obsoleteTime.
  3. An element with validityTimePeriod.start before the given range, validityTimePeriod.end within the given range, no obsoleteTime.
  4. An element with validityTimePeriod.start before the given range, validityTimePeriod.end.end after the given range, no obsoleteTime.
  5. An element with validityTimePeriod.start within the given range, validityTimePeriod.end within the given range, no obsoleteTime.
  6. An element with validityTimePeriod.start within the given range, validityTimePeriod.end after the given range, no obsoleteTime.
  7. An element with validityTimePeriod.start within the given range, validityTimePeriod.end within the given range, obsoleteTime within the given range and before validityTimeEnd.
  8. An element with validityTimePeriod.start and validityTimePeriod.end.end after the given range, no obsoleteTime.
  9. An element with validityTimePeriod.start and validityTimeEnd before the given range, no obsoleteTime.
  10. An element with validityTimePeriod.start before the given range, validityTimePeriod.end after the given range and obsoleteTime before the given range.
It is possible to have several elements for one case, e.g. to test dates exactly at the start or end of the given range, and also to skip cases that are not applicable.
The expected DocumentId's, case 1-7 above, must be added as a comma-separated list in the expectedDocumentIds field.
The unexpected DocumentId's, case 8-10 above, must be added as a comma-separated list in the unexpectedDocumentIds field.
The fields httpHeaderHsaId and logicalAddress must contain values that do not limit the response.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType
  • timePeriodStart
  • timePeriodEnd
  • expectedDocumentIds
  • unexpectedDocumentIds

CareUnitIdFilter

Verifies that the result only contains information for the requested CareUnitIds.
Enter a PatientId and two CareUnitIds that exist in the source system.
The fields httpHeaderHsaId and logicalAddress must contain values that do not affect the returned list.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType
  • careUnitId1
  • careUnitId2

CareContactIdFilter

Verifies that the result only contains information for for the requested CareContactIds.
Enter a PatientId, sourceSystemHSAid and two CareContactIds that exist in the source system.
The fields httpHeaderHsaId and logicalAddress must contain values that do not affect the returned list.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType
  • sourceSystemHSAId
  • careContactId1
  • careContactId2

HttpHeaderFilter

Verifies that the source system filters the response based on the HttpHeader 'x-rivta-original-serviceconsumer-hsaid'.
The testcase is not applicable for systems that do not implement this kind of filtering.
Enter a PatientId that has data with more than one CareContactId in the source system.
One or more CareUnitIds must pass the Http-header-filtering. Add these to expectedCareUnitIds below.
One or more CareUnitIds must NOT pass the Http-header-filtering. Add these to unexpectedCareUnitIds below.
The field logicalAddress must be set to a value that does not affect the returned list.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType
  • expectedCareUnitIds
  • unexpectedCareUnitIds

NonExistentPatientId

Verifies that the service returns an empty result instead of a Soap Fault if a nonexistent PatientId is given.
Enter a PatientId that is not found in the source system and valid values for httpHeaderHsaId and logical adress.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType

NonExistentCareContactId

Verifies that the service returns an empty result instead of a Soap Fault if a nonexistent CareContactId is given.
Enter a PatientId that exists in the source system and a sourceSystemHSAId and CareContactId that is not found in the source system.
The fields httpHeaderHsaId and logicalAddress must contain values that do not affect the returned list.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType
  • careContactId
  • sourceSystemHSAId

CareContactIdWithoutSourceSystemHSAId

This negative test verifies that the source system returns a Soap Fault if careContactId has a value and sourceSystemHSAId is empty or not supplied.
Enter a PatientId/CareContactId-combination that exists in the source system and valid values for httpHeaderHsaId and logicalAddress.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • patientId
  • patientIdType
  • careContactId

SourceSystemHSAIdAndLogicalAddress

This negative test verifies that the source system returns a Soap Fault if the logicalAddress and sourceSystemHSAId are not the same.
Enter PatientId and a CareContactId and the correct SourceSystemHSAId of a CareContact that is found in the source system.
The field logicalAddress must NOT match SourceSystemHSAId.
The field httpHeaderHsaId must contain a valid value.

Variables used
  • httpHeaderHsaId
  • logicalAddress
  • careUnitHSAid
  • patientId
  • patientIdType
  • careContactId
  • sourceSystemHSAId