From IHEWiki

Contents 1 Individual Tests 1.1 11710 1.2 11728 1.3 11729 1.4 11730 1.5 11733 1.6 11734 1.7 11735 1.8 11736 1.9 11737 1.10 11738 1.11 11739 1.12 11740 1.13 11741 1.14 11743 1.15 11746 1.16 11747 1.17 11748 1.18 11750 1.19 11751 1.20 11801 1.21 11802 1.22 11827 1.23 11870 1.24 11871 1.25 11873 1.26 11874 1.27 11875 1.28 11876 1.29 11877 1.30 11878 1.31 11879 1.32 11880 1.33 11881 1.34 11882 1.35 11883 1.36 11884 1.37 11885 1.38 11886 1.39 11887 1.40 11890 1.41 11897 1.42 11898 1.43 11901 1.44 11902 1.45 11903 1.46 11904 1.47 11905 1.48 11906 1.49 11907 1.50 11908 1.51 11909 1.52 11936 1.53 11937 1.54 11938 1.55 11939 1.56 11940 1.57 11941 1.58 11942 1.59 11943 1.60 11944 1.61 11945 1.62 11946 1.63 11947 1.64 11948 1.65 11952 1.66 11953 1.67 11954 1.68 11955 1.69 11956 1.70 11957 1.71 11958 1.72 11959 1.73 11960 1.74 11961 1.75 11963 1.76 11964 1.77 11965 1.78 11966 1.79 11969 1.80 11970 1.81 11971 1.82 11972 1.83 11973 1.84 11974 1.85 11975 1.86 11979 1.87 11980 1.88 11981 1.89 11982 1.90 11983 1.91 11986 1.92 11990 1.93 11991 1.94 11992 1.95 11993 1.96 11994 1.97 11995 1.98 11996 1.99 11997 1.100 11999 1.101 12000 1.102 12001 1.103 12002 1.104 12004 1.105 12005 1.106 12020 1.107 12021 1.108 12023 1.109 12024 1.110 12028 1.111 12029 1.112 12030 1.113 12031 1.114 12037 1.115 12038 1.116 12045 1.117 12046 1.118 12047 1.119 12049 1.120 12051 1.121 12052 1.122 12053 1.123 12054 1.124 12055 1.125 12074 1.126 12076 1.127 12083 1.128 12084 1.129 12085 1.130 12086 1.131 12300 1.132 12301 1.133 12302 1.134 12303 1.135 12306 1.136 12307 1.137 12308 1.138 12309 1.139 12310 1.140 12311 1.141 12312 1.142 12314 1.143 12318 1.143.1 Receiving Gateway has no Registry behind it 1.143.2 Receiving Gateway has a Registry behind it 1.143.3 Test 12318 Patient ID 1.144 12320 1.145 12321 1.146 12322 1.147 12323 1.148 12324 1.149 12325 1.150 12326 1.151 12327 1.152 12328 1.153 12329 1.154 12331 1.155 12333 1.156 12334 1.157 12335 1.158 12336 1.159 12337 1.160 12338 1.161 12339 1.162 12340 1.163 12341 1.164 12342 1.165 12343 1.166 12345 1.167 12346 1.168 12347 1.169 12355 1.170 12358 1.171 12359 1.172 12360 1.173 12361 1.174 12362 1.175 12363 1.176 12364 1.177 12366 1.178 12368 1.179 12369 1.180 12370 1.181 12371 1.182 12372 1.183 12373 1.184 12374 1.185 Query - Testing the Document Registry 1.186 Query - Testing the Document Consumer 1.187 Stored Query - Testing the Document Registry 1.188 Query - Configuring the SQL queries supplied in the testkit 1.189 Syslog Tests 2 Contributed Content 2.1 Scan Document (CDA wrapped PDF)

Individual Tests

11710

Connection + IP Registration

The primary purpose of this test is to help manage the users of the Public Registry by associating a Vendor Name with an IP address. This allows the test managers to find your test data based on our displays. This is occasionally necessary to help answer questions. If you are testing a Document Repository then you need to download the XDS testkit to run all your tests and so you have the choice of running test 11710 or registering via the Test Log Browser. The instructions for registering via test 11710 are described below under Test Procedure. If you are testing a Document Registry then you have no interaction with the Public Registry and this test is not necessary. If you are testing a Document Source or Document Consumer actor then a new facility built into the Test Log Browser can be used instead of this test which gets you out of downloading and installing the xdstest2 testing tool. You can find documentation on using the Test Log Browser to register here.

References

None

Actors Tested

None

Resources

testkit/tests/11710

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Edit the file tests/11710/testplan.xml
3. Edit the following fields:
   • <Your Company Name> (include product name if testing more than one).
   • <Your Name>
   • <Your Email>
4. Send this metadata as a Submission Request by executing the following from a command prompt:
   • Run the test using xdstest
5. When reporting the results of this test in kudu, just create a simple text file indicating this step is successfully complete.
6. If you test from more than one machine and therefore run this multiple times, please spell the company name the same each time.

11728

Submit a Folder via XDS.a

Verify that the XDS.a Document Source can submit a Folder via Provide and Register Document Set-a transaction.

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/11728

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11728

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11729

Submit a Folder with an initial document via XDS.a

Verify that the XDS.a Document Source can submit a Folder and initial document via Provide and Register Document Set transaction.

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/11729

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11729

1. Submit a Submission Set containing a Single Folder with initial Document using the Provide and Register Document Set transaction
2. Report the test

11730

Add New Document to Existing Folder

This is an XDS.a test.

Add a Document to an existing Folder. The Folder is identified by its UUID which is obtained from a query of your choice.

This submission consists of:

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• a HasMember Association object linking the Submission Set to the Document
• a HasMember Association object linking the existing Folder (in Registry) with Document in submission
• a HasMember Association object linking the Submission Set to the Folder-Document Association
  • An ObjectRef identifying the Folder as an object already in the registry

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

Creation of a Folder to add the document to. Test 11729 describes this.

Resources

testkit/examples/11730

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Create a Folder per test 11729.
3. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11730

1. Identify the UUID of the Folder of interest with a query of your choosing
2. Formulate a submission as described above or use the example metadata found in examples/11730
   • If you use this example, the Folder is referenced symbolically as "$Folder$". This must be replaced with the actual UUID of the folder object in the registry. Addionally, an ObjectRef with its id set to this UUID must be present in the submission.
3. Have your Document Source send the submission
4. Verify that you get a successful RegistryResponse message in return.
5. Report the test

11733

Accept Register One Document via XDS.a

Verify that the XDS.a Document Registry can accept a Register Document Set-a transaction containing metadata for a Submission Set containing a single Document.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Your registry must support the GetSubmissionSetAndContents Stored Query to pass the evaluation step of this test

You will need to

None

Resources

testkit/tests/11733

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11734

Retrieve Document

Verify that Document Consumer can retrieve a document via the Retrieve Document transaction (HTTP Get).

References

ITI TF-2 3.17

Actors Tested

Document Consumer

Testing Document Consumer Actor

Using any available test data:

• test data

1. Perform queries as is appropriate for your document Consumer leading up to the retrieval of the document
2. Retrieve the document
3. No logging of results is necessary

11735

Accept Register Two Documents

Verify that the Document Registry can accept a valid SOAP over HTTP message containing valid metadata representing two documents. The metadata will contain a Submission Set and two XDSDocumentEntry objects.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Resources

testkit/tests/11735

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11736

Submit Replace/Transformation for Existing Document

It is not necessary for Document Sources or Document Repositories to demonstrate this test. Once test #11748 has been successfully passed, this test will automatically be passed as well.

11737

This test describes a mechanism in XDS which the ITI Technical Committee does not agree upon its usage. The existence of the 'Reference' value for SubmissionSetStatus is described in the Technical Framework but the exact mechanism for its use and the resulting interpretation have not been determined. As a result, this test has been discontinued.

Submit Add By-Reference to Submission Set

It is possible to add a document to a submission set that has a different patient ID. First, the document itself must be added to the registry by submitting it in a Submission Set. An example of this is shown in examples/11746. Then to add it to another Submission Set, one that possibly has a different patient ID, submit together or separately an association as follows:

<Association associationType="HasMember" 
	sourceObject="the submission set UUID" 
	targetObject="symbolic name or UUID of document">
    <Slot name="SubmissionSetStatus">
        <ValueList>
            <Value>Reference</Value>
        </ValueList>
    </Slot>
</Association>

where the SubmissionSetStatus is set to Reference. The new document and the association can be submitted together or separately.

Adding a Document to an existing Submission Set can be done in two ways. Given an existing Submission Set in the Registry:

1. Submit the new Document (of course submission must include Submission Set) and the Association linking it to the existing Submission Set
2. Submit the new Document. Submit the Assocation linking it to the existing Submission Set in a separate submission

References

ITI TF-2 3.14

Actors Tested

Document Source

Dependencies

None

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Compose Submission Set as described above
   • Also, see examples/11737/metadata.xml
   • where "Another_SubmissionSet" is replaced with the UUID of the target Submission Set (already present in the Registry).
3. Configure the Document Source to submit to
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository?testeval=11737
4. Do the Submit.
5. Verify that you get a successful RegistryResponse message in return
6. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11738

Submit via Offline Mode

Generate a Provide and Register transaction via Offline Mode.

References

ITI TF-2 3.14

Actors Tested

Document Source

Document Repository

Dependencies

None

Testing Document Source and Document Repository Actors No support facilities are available to test this option. The exception is that Eric provides an email server to use to relay offline message. Contact Eric for details. To demonstrate success, again, contact Eric.

11739

Retrieve with mutual TLS

Repeat test #11734 with mutual TLS enabled.

11740

Register with mutual TLS

Repeat any Register test over TLS

11741

Query with mutual TLS

Repeat any Query test with mutual TLS enabled.

References

ITI TF-2 3.15

Actors Tested

Document Registry

Document Consumer

Dependencies

None

11743

Provide and Register (XDS.a) with mutual TLS

Repeat test 11746 with mutual TLS enabled.

11746

Submit one document via XDS.a

Verify that the XDS.a Document Source can submit a single document via Provide and Register Document Set transaction.

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/11746

XDS Test Log Browser

Testing Document Source Actor Submit a Submission Set containing a single Document using the Provide and Register Document Set transaction

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/repositoryAonedoc

1. Report the test

11747

Submit two documents via XDS.a

Verify that the XDS.a Document Source can submit two documents together via the Provide and Register Document Set transaction.

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

None

You will need to

Allocate a Patient ID

Allocate unique IDs for Submission Set and Document objects

Resources

examples/11747 section of test kit

XDS Test Log Browser

Testing Document Source Actor

1. Configure your Document Source actor to submit to the Public Repository at EndPoint http://ihexds.nist.gov:9080/tf5/services/repositoryA2doc
2. Submit a Submission Set containing two Documents using the Provide and Register Document Set transaction
3. Log the results

11748

Replace Existing Document

Verify that Document Source can issue a document replacement. To replace a document, an original document must be discovered through a query. Its UUID must be extracted from the query results. The new document is composed along with a RPLC Association to link the new document to the old. The registry adaptor takes responsibility for deprecating the old document. More specifically, the following must be composed in a submission:

• an XDSSSubmissionSet object
• an XDSDocumentEntry object
• a HasMember Association linking Submission Set to the Document
• a RPLC Association linking the new Document to the existing document being replaced
• An ObjectRef pointing to the document being replaced

There must also be a single document included in the submission as an attachment.

References

ITI TF-2 3.14

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/11748

testkit/examples/11746 (to establish Document to be replaced)

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Testkit content testkit/examples/11746 may be used to establish a document in the registry to replace.
3. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11748

1. Report the test

11750

Submit Transformation for Existing Document

It is not necessary for Document Sources or Document Repositories to demonstrate this test. Once test #11748 has been successfully passed, this test will automatically be passed as well.

11751

Accept two documents via XDS.a

Verify that the XDS.a Document Repository can accept a submission containing two documents via the Provide and Register Document Set-a transaction and forward the updated metadata to the Public Registry.

References

ITI TF-2 3.15

ITI TF-2 3.14

Actors Tested

Document Repository

Dependencies

none

Resources

testkit/tests/11751

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

Submit a Submission Set containing two Documents using the Provide and Register Document Set transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set transaction

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryA2doc

1. Run and report the test using xdstest

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Correct content (Submission Set containing two Documents)
4. Correct hash and size computed by Repository actor and placed in metadata.

Evaluation by xdstest2

1. Evaluation query returns correct metadata

11801

Query for ObjectRefs

Verify that Document Consumer can query the Registry for ObjectRefs and that a Document Registry can service such a query.

Why does this exist? Any potential document listing can be very long. To use LeafClass queries to generate listing pages (pick lists) would be very slow as this requires the Registry to assemble metadata XML for each document. Starting with an ObjectRef query that returns just the list of identifiers for each document can be used to generate 'page at a time' listing. For each page, a full LeafClass query can be issued to get the content for display. 11801 (and 11802) are intended for debug usage only.

References

ITI TF-2 3.14

Actors Tested

Document Consumer

Document Registry

Dependencies

Test #11870 must be run before this test. It loads necessary test data.

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer send the query in test/11801/query.xml.
3. Verify that you get a successful RegistryResponse message in return containing 1 ObjectRef.
4. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit test/11801/test.properties
2. Change the URL parameter to point to your registry.
3. Run the test using xdstest.
4. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11802

Query for LeafClass

Verify that Document Consumer can query the Registry for LeafClass and that a Document Registry can service such a query. This is intended for debug purposes only.

References

ITI TF-2 3.14

Actors Tested

Document Consumer

Document Registry

Dependencies

Test 11870 must be run before this test

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer send the query in test/11802/query.xml.
3. Verify that you get a successful RegistryResponse message in return containing 1 ExtrinsicObject.
4. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit test/11802/test.properties
2. Change the URL parameter to point to your registry.
3. Run the test using xdstest.
4. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11827

Accept One Document via XDS.a

Verify that the XDS.a Document Repository can accept a SOAP with Attachments message containing metadata representing a Submission Set and a single document. The content of the document are include as an attachment to the message according to the SOAP with Attachments standard. Specifically, the metadata shall be augmented with the following attributes to match the included document:

• XDSDocumentEntry.size
• XDSDocumentEntry.hash
• XDSDocumentEntry.URI

and then forwarded on to the Public Registry in a XDS.a Register transaction. These attributes must be calculated and added correctly. The URI installed into XDSDocumentEntry.URI need not be publicly available on the Internet. See tests/11733 for an example of how to add these metadata attributes.

Warning: some testers have run the utility unix2dos on the entire test kit and it will break this test. The file attachment, my_document.txt, when modified by this utility will no longer match in size or hash.

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

XDS.a Document Repository

Dependencies

None

Resources

testkit/tests/11827 section of test kit which has two sections, submit and eval'

XDS Test Log Browser

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

Submit a Submission Set containing a single Document using the Provide and Register Document Set transaction to your XDS.a Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set transaction

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11827

1. Run and report the test using xdstest

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Correct content (Submission Set containing a single Document)
4. Correct hash and size computed by Repository actor and placed in metadata.

Evaluation by xdstest2

1. Evaluation query returns correct metadata

11870

Load test data set 1

Load test data into Registry to support query testing.

References

ITI TF-2 3.14

Actors Tested

None

Dependencies

None

Testing Document Registry Actor

1. Edit testdatga/11870/test.properties
2. Change the URL parameter to point to your registry
3. Edit testdata/11870/metadata.xml
   • Change $PatientId to a real patient ID globally
   • Change all uniqueIds (start with $uniqueId) to real uniqueIDs in your system
4. Run the test using xdstest.
5. Log the results: no logging required

This submission contains a single Submission Set, 3 Documents, and Associations to make the documents part of the Submission Set.

11871

Accept Document Replace via XDS.a

Verify that the XDS.a Document Registry can accept a Document Replace via the Register Document Set transaction. No transformations or addendum are present.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11871

Testing Document Registry Actor

Submit a Document Replace using the Register Document Set transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

Evaluation

1. Submit, rplc, eval steps must be successful
2. Within the eval step, the validate_deprecate test step must show that the original document is deprecated and the validate_new must show that the replacement document is approved (status = Approved).

11873

Accept Document Addendum via XDS.a

Verify that the XDS.a Document Registry can accept a Document Addendum via the Register Document Set transaction.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11873

Testing Document Registry Actor

Submit a Document Addendum using the Register Document Set transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query. An overview of this test is:

• Submit a submission set containing a single document. Do this twice.
• Replace (issue RPLC) for one of the documents
• Attempt addendum on both original documents. Creating an addendum on the replaced document must fail. Creating an addendum on the non-replaced document must succeed.
• Issue GetSubmissionSetandContents Stored Query on both addendum attempts. The plain addendum must succeed and the one involving the replace must fail. In this case succeed and fail simply refers to whether content is returned and not the status on the Stored Query.

The detailed steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11874

Accept Document Transformation via XDS.a

Verify that the XDS.a Document Registry can accept a Document Transformation via the Register Document Set transaction.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11874

Testing Document Registry Actor

Submit a Document Transformation using the Register Document Set transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query. An overview of this test is:

• Submit a submission set containing a single document. Do this twice.
• Replace (issue RPLC) for one of the documents
• Attempt transformation on both original documents. Creating a transformation on the replaced document must fail. Creating a transformation on the non-replaced document must succeed.
• Issue GetSubmissionSetandContents Stored Query on both transformation attempts. The plain transformation must succeed and the one involving the replace must fail. In this case succeed and fail simply refers to whether content is returned and not the status on the Stored Query.

The detailed steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11875

Accept Document Transform/Replace via XDS.a

Verify that the XDS.a Document Registry can accept a Document Transform Replace via the Register Document Set transaction. No transformations or addendum are present.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11875

Testing Document Registry Actor

Submit a Document Replace using the Register Document Set transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

Evaluation

1. Submit, rplc, eval steps must be successful
2. Within the eval step, the validate_deprecate test step must show that the original document is deprecated and the validate_new must show that the replacement document is approved (status = Approved).

11876

Reject Submission of Invalid Patient ID via XDS.a

This test allows an implementation of the Document Registry actor to show that it rejects submissions of documents that are registered to patients whose patient ID has not been received through the Patient Identity Feed transaction.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11876

Testing Document Registry Actor

Submit a Submission Set containing a single Document using the Register Document Set transaction to your Registry. The registry must reject the submission giving the XDSUnknownPatientId error code

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11877

Reject Submission Set, Patient ID does not match Document (XDS.a)

This test allows an implementation of the Document Registry actor to show that it rejects submissions where the Submission Set and Document have different Patient IDs.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11877

Testing Document Registry Actor

Submit a Submission Set containing a single Document using the Register Document Set transaction to your Registry. The metadata provided has different Patient IDs in the Submission Set and the Document metadata. The registry must reject the submission giving the XDSPatientIdDoesNotMatch error code. You may change the Patient IDs coded if that makes the test easier as long as they are different.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11878

Reject Submission, Patient ID on Replacement Document does not match Original

This test allows an implementation of the Document Registry actor to show that it rejects submissions of replacement documents where the patient ID of the replacement document does not match the patient ID of the original document.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11878

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11879

Accept Create Folder

Verify that the XDS.a Document Registry can accept the submission of a Folder.

This submission consists of:

• an XDSSubmissionSet object
• an XDSFolder object
• an HasMember Association object linking the Submission Set to the Folder

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Your registry must support the GetSubmissionSetAndContents Stored Query to pass the evaluation step of this test

Resources

testkit/tests/11879

Testing Document Registry Actor An overview of this test is:

• Submit a folder within a submission set to document registry
• Issue GetSubmissionSetAndContents to verify content in registry

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11880

Accept Create Folder with Initial Document

Verify that the XDS.a Document Registry can accept the submission of a Folder with a document.

This submission consists of:

• an XDSSubmissionSet object
• an XDSFolder object
• a HasMember Association object linking the Submission Set to the Folder
• a Document object
• a HasMember Association object linking the Folder to the Document

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Your registry must support the GetSubmissionSetAndContents and GetFolderAndContents Stored Queries to pass the evaluation step of this test

You will need to

None

Resources

testkit/tests/11880

Testing Document Registry Actor An overview of this test is:

• Submit above described metadata
• Issue GetSubmissionSetAndContents to verify content in registry

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11881

Accept Add New Document to Folder

Verify that the XDS.a Document Registry can accept a submission that contains a document which is added to an existing folder.

This submission consists of:

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• an HasMember Association linking the Submission Set to the Document
• an HasMember Association linking an existing Folder to this new Document

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Your registry must support the GetFolderAndContents Stored Query to pass the evaluation step of this test

Resources

teskit/tests/11881

Testing Document Registry Actor An overview of this test is:

• Submit an empty folder
• Submit a document with the association to link it to the folder
• Issue GetFolderandContents Stored Query to verify contents of Registry

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11882

Reject Add Document to Folder - Patient ID does not match

Verify that the XDS.a Document Registry will reject a submission that contains a document which is added to an existing folder with a different Patient ID.

This submission consists of:

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• an HasMember Association linking the Submission Set to the Document
• an HasMember Association linking an existing Folder to this new Document

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Your registry must support the GetFolderAndContents Stored Query to pass the evaluation step of this test

Resources

testkit/tests/11882

Testing Document Registry Actor An overview of this test is:

• Submit an empty folder
• Submit a document with the association to link it to the folder. The Patient ID on the Document does not match that on the Folder.
• Issue GetFolderandContents Stored Query to verify contents of Registry. The Document must not be a member of the Folder.

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11883

Submission Stored - All or Nothing (XDS.a)

A submission including a Submission Set and two documents is submitted to the Registry. One of the two documents is missing the URI attribute and will therefore cause an error. A stored query is then used to verify that no Submission Set nor documents are stored in the registry with status Approved.

References

ITI TF-2 3.14

Actors Tested

XDS.a Document Registry

Dependencies

None

You will need to

None

Resources

teskit/tests/11883

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

Evaluation by xdstest2

1. The xdstest2 tool will verify that:

the submission failed

the query returns no Submission Set or Documents

11884

Accept Add By-Reference to Submission Set

This tests a Document Registry actor's ability to accept add a document to a submission set by-reference.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Allocate a new patient ID
2. Make any initial submission which includes a Submission Set, test #11731 is a possibility
3. Submit to your Document Registry actor implementation via xdstest
4. For the next submission, use tests/11884, with different patient ID from first submission.
5. Submit to your Document Registry actor implementation via xdstest
6. Verify that you get a successful RegistryResponse message in return
7. Log the results: #Log_Results_of_Register_transaction_against_your_Registry. This must be run twice, once for each patient ID

11885

Reject Duplicate Document uniqueID with Different Hash (XDS.a)

Verify that the XDS.a Document Registry will

accept a duplicate XDSDocumentEntry, same XDSDocumentEntry.uniqueId, if the XDSDocumentEntry.hash is the same

reject if the hash is different

References

ITI TF-2 3.14

Actors Tested

XDS.a Document Registry

Dependencies

None

Resources

teskit/tests/11885

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

Evaluation by xdstest2

1. The xdstest2 tool will evaluate that the proper error message is returned from each test step.

11886

Pass Arbitrary Metadata

A Document Repository actor must be able to pass arbitrary metadata from the Document Source to the Document Registry. The only metadata modifications made by a Document Repository is to annotate XDSDocumentEntry objects with size, hash, and URI information.

This tests sends a collection of metadata artifacts through the Repository to the Registry. There they will be verified as complete and unaltered.

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

Document Repository

Testing Document Repository Actor

1. Start with the test data in tests/11886
2. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
3. Edit these values into the test submission (see #Patient_IDs_and_uniqueIds_in_test_material)
4. Edit the file test.properties to point to your repository and to show the correct patient ID
5. Configure your Document Repository so that the subsequent Register Transaction is sent to the Public Registry.
6. Run the test using xdstest.
7. Verify that you get a successful RegistryResponse message in return.
8. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11887

Return Errors from Registry (XDS.a)

This test demonstrates that a Document Repository returns errors from the Document Registry back to the Document Source. This test is a repeat of test 11877 which tests that a Registry rejects unknown Patient IDs. The Repository under test points to the Public Registry which generates the original error. The responsibility of the Repository is to return the errors to the Document Source.

References

ITI TF-2 3.14, 3.15

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/11887

Testing Document Repository Actor

1. Follow Generic Testing Procedure s Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistrya

1. Run and report the test using xdstest

11890

Load test data into Document Registry via Register.a transaction

This data does not contain valid references to documents in Repository. It is suitable for Stored Query testing only.

References

ITI TF-2 3.14

Actors Tested

None

Dependencies

None

Resources

testkit/testdata/11890

Loading test data

1. Follow Generic Testing Procedures Using xdstest

The results of this test should not be logged in Kudu.

11897

FindDocuments Stored Query.b

Test a Document Registry's implementation of the FindDocuments Stored Query.b.

This test has multiple parts where each part focuses on one or a collection of the parameters to the FindDocuments Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 11890 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11897

Testing FindDocuments Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11898

FindSubmissionSets Stored Query

Test a Document Registry's implementation of the FindSubmissionSets Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the FindSubmissionSets Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 11890 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11898

Testing FindSubmissionSets Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11901

GetDocuments Stored Query

Test a Document Registry's implementation of the GetDocuments Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetDocuments Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11901

Testing GetDocuments Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11902

GetFolders Stored Query

Test a Document Registry's implementation of the GetFolders Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetFolders Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11902

Overview of the test steps contained in the test plan

• uniqueid - query by uniqueid
• uuid - query by uuid

Testing GetFolders Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11903

GetAssociations Stored Query

Test a Document Registry's implementation of the GetAssociations Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetAssociations Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11903

Testing GetAssociations Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11904

GetDocumentsAndAssociations Stored Query

Test a Document Registry's implementation of the GetDocumentsAndAssociations Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetDocumentsAndAssociations Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11904

Testing GetDocumentsAndAssociations Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11905

GetSubmissionSets Stored Query

Test a Document Registry's implementation of the GetSubmissionSets Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetSubmissionSets Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11905

Testing GetSubmissionSets Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11906

GetSubmissionSetAndContents Stored Query.b

Test a Document Registry's implementation of the GetSubmissionSetAndContents Stored Query.b.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetSubmissionSetAndContents Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11906

Testing GetSubmissionSetAndContents Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11907

GetFolderAndContents Stored Query

Test a Document Registry's implementation of the GetFolderAndContents Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetFolderAndContents Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11907

Overview of the test steps contained in the test plan

• uniqueid - query by uniqueid
• uuid - query by uuid
• conf_code - query by uuid with filter on confidentiality code
• both_conf_code - query by uuid with multi-value filter on confidentiality code
• format_code - query by uuid with filter on format code

Testing GetFolderAndContents Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11908

GetFoldersForDocument Stored Query

Test a Document Registry's implementation of the GetFoldersForDocument Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetFoldersForDocument Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11908

Testing GetSubmissionSetAndContents Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11909

GetRelatedDocuments Stored Query.b

Test a Document Registry's implementation of the GetRelatedDocuments Stored Query.b.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetRelatedDocuments Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 12346 must be run before this test to establish the test data in your registry

Resources

testkit/tests/11909

Testing GetRelatedDocuments Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11936

Generic instructions for testing Document Consumer implementations of Stored Queries.

References

ITI TF-2 3.18

Actors Tested

Document Consumer

Dependencies

testkit/testdata/12328

Test Data

Test data for this test is pre-loaded on the Public Registry for your use. The Patient IDs currently available on the Public Registry server are documented here. When examining available test data note that some Patient IDs have real documents in the Repository and other do not. Choose wisely on your quest.

Test Procedure

1. Using above test data, test your Document Consumer's Stored Queries. Test any and all Stored Queries that your implementation requires. You must show evidence of testing at least one Stored Query.
2. Submit evidence of your work using instructions found here.

11937

See #11936

11938

See #11936

11939

See #11936

11940

See #11936

11941

See #11936

11942

See #11936

11943

See #11936

11944

See #11936

11945

See #11936

11946

See #11936

11947

See #11936

11948

See #11936

11952

Submit a Consent Document referencing a patientID and one or more Policy OIDs.

Tests Document Source

11953

Submit a Clinical Document which references an existing Consent Document.

Tests Document Source

11954

Query for a Consent protected Clinical Document

Tests Document Consumer

11955

Accept Submission of Clinical Document which references a Consent submitted earlier.

Tests Document Registry

Depends on test 11959

11956

Reject Register transaction of a Clinical Document with Confidentiality Code not represented by an Active Consent within the Registry actor.

Tests Document Registry

11957

Accept Stored Query which includes filtering on Confidentiality Codes. The Consents containing these Confidentiality Codes and the Clinical Documents referencing these Confidentiality Codes were submitted earlier in separate tests.

Tests Document Registry

11958

Accept Stored Query which does not include filtering on Confidentiality Codes

Tests Document Registry

11959

Load BPPC test data.

Tests Document Registry

11960

Stored Query does not return Clinical Documents if Consent has been revoked.

Tests Document Registry

Depends on Test 11959

11961

Stored Query does not return Clinical Documents if Consent has expired.

Tests Document Registry

Depends on Test 11959

See Test 11954 - Query for Clinical Document

11963

Accept Submission

Verify that the Document Recipient can accept an XDR-style transmission. This will be tested via manual upload from disk. There is currently no infrastructure to test ebMS.

References

ITI TF-2 3.14

Actors Tested

Document Recipient

Testing Document Recipient Actor

1. Use the test material in the test kit in tests/11963
2. Perform the manual import
3. Capture screen image showing
   • Status of transaction acceptance OR
   • Display of imported material
4. Log the screen capture in Kudu

11964

Send One Document

Compose XDR-style transmission of one or more documents. Submit this content to Kudu in a ZIP file.

References

ITI TF-2 3.14

Actors Tested

Document Source

The ZIP file shall contain the following files representing the content of an XDR-style transmission:

• METADATA.HDR - containing the header lines necessary for transmitting the metadata (the headers that would be present in the MIME Multipart-Part containing the metadata)
• METADATA.XML - containing the metadata of the submission
• Content to match the metadata:
  • Each piece of content is to be represented by two files: NAME.HDR and NAME.EXT where
    • NAME is replaced by a unique name within the submission which matches the URI element of the metadata.
    • EXT is replaced with the correct file extension for that file/media type.
• The header file shall contain the necessary MIME Multipart-Part header content necessary for transmitting this document. The content file shall contain the content byte-stream to be transmitted.

The metadata, header, and content portions of the submission shall be consistent by XDS rules.

11965

Accept XDM Content

This test supplies example XDM-style content for testing Portal Media Importer actors. No logging of test results is required.

References

ITI TF-2 3.32

Actors Tested

Portal Media Importer

Content can be found in tests/11965.

11966

Accept one document via XDS.b

Verify that the XDS.b Document Repository can accept a single document via the Provide and Register Document Set-b transaction and forward the updated metadata to the Public Registry.

References

ITI TF-2 3.41

ITI TF-2 3.42

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/11966

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

Submit a Submission Set containing a single Document using the Provide and Register Document Set-b transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set-b transaction.

1. Follow Generic Testing Procedure s Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11966

1. Run and report the test using xdstest

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Correct content (Submission Set containing a single Document)
4. Correct hash and size computed by Repository actor and placed in metadata.

Evaluation by xdstest2

1. Evaluation query returns correct metadata

11969

Submit a Folder via XDS.b

Verify that the XDS.b Document Source can submit a Folder via Provide and Register Document Set-b transaction.

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/11969

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11969

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11970

Submit a Folder with an initial document via XDS.b

Verify that the XDS.b Document Source can submit a Folder and initial document via Provide and Register Document Set-b transaction.

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/11970

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11970

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11971

Add New Document to Existing Folder

This is an XDS.b test.

Add a new Document to an existing Folder. The Folder is identified by its UUID which is obtained from a query of your choice.

This submission consists of:

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• a HasMember Association object linking the Submission Set to the Document
• a HasMember Association object linking the existing Folder (in Registry) with Document in submission
• a HasMember Association object linking the Submission Set to the Folder-Document Association
  • An ObjectRef identifying the Folder as an object already in the registry

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

Creation of a Folder to add the document to. Test 11970 describes this.

Resources

testkit/examples/11971

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Create a Folder per test 11970.
3. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11971

1. Identify the UUID of the Folder of interest with a query of your choosing
2. Formulate a submission as described above or use the example metadata found in examples/11971
   • If you use this example, the Folder is referenced symbolically as "$Folder$". This must be replaced with the actual UUID of the folder object in the registry. Addionally, an ObjectRef with its id set to this UUID must be present in the submission.
3. Have your Document Source send the submission
4. Verify that you get a successful RegistryResponse message in return.
5. Report the test

11972

Add Existing Document to Existing Folder using XDS.a

Add an existing Document to an existing Folder. The Folder and Document are identified by its UUID which is obtained from a query of your choice.

This submission consists of:

• an XDSSubmissionSet object
• a HasMember Association object linking the existing Folder (in Registry) with the existing Document
• a HasMember Association object linking the Submission Set to the above Association
• ObjectRefs identifying the existing Folder and Document as being objects already in the registry

Remember the Folder and Document must have the same Patient ID.

References

ITI TF-2 3.15

Actors Tested

Document Source

Resources

testkit/examples/11972

XDS Test Log Browser

Dependencies

Creation of a Folder to add the document to. Test 11728 describes this.

Submission of a Document to add to the Folder. Test 11746 describes this.

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11972

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11973

Add Existing Document to Existing Folder using XDS.b

Add an existing Document to an existing Folder. The Folder and Document are identified by its UUID which is obtained from a query of your choice.

This submission consists of:

• an XDSSubmissionSet object
• a HasMember Association object linking the existing Folder (in Registry) with the existing Document
• a HasMember Association object linking the Submission Set to the above Association
• a HasMember Association object linking the Submission Set to the above Association

Remember the Folder and Document must have the same Patient ID.

References

ITI TF-2 3.41

Actors Tested

Document Source

Resources

testkit/examples/11973

XDS Test Log Browser

Dependencies

Creation of a Folder to add the document to. Test 11969 describes this.

Submission of a Document to add to the Folder. Test 12049 describes this.

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11973

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11974

Replace Existing Document

Verify that Document Source can issue a document replacement. To replace a document, an original document must be discovered through a query. Its UUID must be extracted from the query results. The new document is composed along with a RPLC Association to link the new document to the old. The registry adaptor takes responsibility for deprecating the old document. More specifically, the following must be composed in a submission:

• an XDSSSubmissionSet object
• an XDSDocumentEntry object
• a HasMember Association linking Submission Set to the Document
• a RPLC Association linking the new Document to the existing document being replaced

There must also be a single document included in the submission as an attachment.

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

testkit/examples/12049 can be used to create the existing document

Resources

testkit/examples/11974

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11974

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11975

Submit Transformation for Existing Document

Verify that Document Source can issue a document transformation. To transform a document, an original document must be discovered through a query. Its UUID must be extracted from the query results. The new document is composed along with a XFRM Association to link the new document to the old. Unlike a replace, the old/original document is not deprecated.

More specifically, the following must be composed in a submission:

• an XDSSSubmissionSet object
• an XDSDocumentEntry object
• a HasMember Association linking Submission Set to the Document
• a XFRM Association linking the new Document to the existing document being replaced

There must also be a single document included in the submission as an attachment.

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

testkit/examples/12049 can be used to create the existing document

Resources

testkit/examples/11975

XDS Test Log Browser

Testing Document Source Actor

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/test11975

1. Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
2. Report the test

11979

Accept two documents via XDS.b

Verify that the XDS.b Document Repository can accept a submission containing two documents via the Provide and Register Document Set-b transaction and forward the updated metadata to the Public Registry.

References

ITI TF-2 3.41

ITI TF-2 3.42

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/11979

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

Submit a Submission Set containing two Documents using the Provide and Register Document Set-b transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set-b transaction

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryB2doc

1. Run and report the test using xdstest

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Correct content (Submission Set containing two Documents)
4. Correct hash and size computed by Repository actor and placed in metadata.

Evaluation by xdstest2

1. Evaluation query returns correct metadata

11980

Accept Document with size, hash and URI attributes via XDS.a

Verify that the XDS.a Document Repository can accept a single document via the Provide and Register Document Set transaction and forward the updated metadata to the Public Registry. The XDSDocumentEntry metadata is already populated with size, hash, and URI attributes. These must be overwritten with the correct values.

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/11980

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryAonedoc

1. Run and report the test using xdstest

11981

Accept Document with size, hash and URI attributes via XDS.b

Verify that the XDS.b Document Repository can accept a single document via the Provide and Register Document Set-b transaction and forward the updated metadata to the Public Registry. The XDSDocumentEntry metadata is already populated with size, hash, and URI attributes. These must be overwritten with the correct values.

References

ITI TF-2 3.41

ITI TF-2 3.42

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/11981

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forward metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryBonedoc

1. Run and report the test using xdstest

11982

Reject submissions where metadata and documents do not match (XDS.a)

Verify that the XDS.a Document Repository will reject submissions where there is a mismatch between metadata and the documents attached.

References

ITI TF-2 3.15

Actors Tested

XDS.a Document Repository

Dependencies

None

Resources

testkit/tests/11982

XDS Test Log Browser

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forward metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsrepositorya

1. Run and report the test using xdstest

Evaluation by xdstest2

1. The xdstest2 tool will evaluate that the proper error message is returned from each test step.

11983

Reject submissions where metadata and documents do not match (XDS.b)

Verify that the XDS.a Document Repository will reject submissions where there is a mismatch between metadata and the documents attached.

References

ITI TF-2 3.41

Actors Tested

XDS.b Document Repository

Dependencies

None

Resources

testkit/tests/11983

XDS Test Log Browser

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forward metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb

1. Run and report the test using xdstest

Evaluation by xdstest2

1. The xdstest2 tool will evaluate that the proper error message is returned from each test step.

11986

Return Errors from Registry (XDS.b)

This test demonstrates that a Document Repository-b returns errors from the Document Registry back to the Document Source. This test is a repeat of test 11997 which tests that a Registry rejects unknown Patient IDs. The Repository under test points to the Public Registry which generates the original error. The responsibility of the Repository is to return the errors to the Document Source.

References

ITI TF-2 3.41, 3.42

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/11986

Testing Document Repository Actor

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forward metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb

1. Run and report the test using xdstest

11990

Accept Register one document via XDS.b

Verify that the XDS.b Document Registry can accept a single document via the Register Document Set-b transaction.

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

Your registry must support the GetSubmissionSetAndContents Stored Query to pass the evaluation step of this test

Resources

testkit/tests/11990

Testing Document Registry Actor Submit a Submission Set containing a single Document using the Register Document Set-b transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11991

Accept Register two documents via XDS.b

Verify that the XDS.b Document Registry can accept a two documents via the Register Document Set-b transaction.

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11991

Testing Document Registry Actor Submit a Submission Set containing two Documents using the Register Document Set-b transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11992

Accept Document Replace via XDS.b

Verify that the XDS.b Document Registry can accept a Document Replace via the Register Document Set-b transaction. No transformations or addendum are present.

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11991

Testing Document Registry Actor

Submit a Document Replace using the Register Document Set-b transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11993

Accept Document Addendum via XDS.b

Verify that the XDS.b Document Registry can accept a Document Addendum via the Register Document Set transaction.

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11993

Testing Document Registry Actor

Submit a Document Addendum using the Register Document Set transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query. An overview of this test is:

• Submit a submission set containing a single document. Do this twice.
• Replace (issue RPLC) for one of the documents
• Attempt addendum on both original documents. Creating an addendum on the replaced document must fail. Creating an addendum on the non-replaced document must succeed.
• Issue GetSubmissionSetandContents Stored Query on both addendum attempts. The plain addendum must succeed and the one involving the replace must fail. In this case succeed and fail simply refers to whether content is returned and not the status on the Stored Query.

The detailed steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11994

Accept Document Transformation via XDS.b

Verify that the XDS.b Document Registry can accept a Document Transformation via the Register Document Set-b transaction.

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11994

Testing Document Registry Actor

Submit a Document Transformation using the Register Document Set transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query. An overview of this test is:

• Submit a submission set containing a single document. Do this twice.
• Replace (issue RPLC) for one of the documents
• Attempt transformation on both original documents. Creating a transformation on the replaced document must fail. Creating a transformation on the non-replaced document must succeed.
• Issue GetSubmissionSetandContents Stored Query on both transformation attempts. The plain transformation must succeed and the one involving the replace must fail. In this case succeed and fail simply refers to whether content is returned and not the status on the Stored Query.

The detailed steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11995

Accept Document Transform/Replace via XDS.b

Verify that the XDS.a Document Registry can accept a Document Transform Replace via the Register Document Set-b transaction. No transformations or addendum are present.

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11995

Testing Document Registry Actor

Submit a Document Replace using the Register Document Set-b transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11996

Reject Submission of Invalid Patient ID via XDS.b

This test allows an implementation of the Document Registry actor to show that it rejects submissions of documents that are registered to patients whose patient ID has not been received through the Patient Identity Feed transaction.

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11996

Testing Document Registry Actor

Submit a Submission Set containing a single Document using the Register Document Set-b transaction to your Registry. The registry must reject the submission giving the XDSUnknownPatientId error code

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11997

Reject Submission Set, Patient ID does not match Document (XDS.b)

This test allows an implementation of the Document Registry-b actor to show that it rejects submissions where the Submission Set and Document have different Patient IDs.

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11997

Testing Document Registry Actor

Submit a Submission Set containing a single Document using the Register Document Set-b transaction to your Registry. The metadata provided has different Patient IDs in the Submission Set and the Document metadata. The registry must reject the submission giving the XDSPatientIdDoesNotMatch error code. You may change the Patient IDs coded if that makes the test easier as long as they are different.

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

11999

Accept Create Folder

Verify that the XDS.b Document Registry can accept the submission of a Folder.

This submission consists of:

• an XDSSubmissionSet object
• an XDSFolder object
• an HasMember Association object linking the Submission Set to the Folder

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

Your registry must support the GetSubmissionSetAndContents Stored Query to pass the evaluation step of this test

Resources

testkit/tests/11999

Testing Document Registry Actor An overview of this test is:

• Submit a folder within a submission set to document registry
• Issue GetSubmissionSetAndContents to verify content in registry

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12000

Accept Create Folder with Initial Document

Verify that the XDS.b Document Registry can accept the submission of a Folder with a document.

This submission consists of:

• an XDSSubmissionSet object
• an XDSFolder object
• a HasMember Association object linking the Submission Set to the Folder
• a Document object
• a HasMember Association object linking the Folder to the Document

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Your registry must support the GetSubmissionSetAndContents and GetFolderAndContents Stored Queries to pass the evaluation step of this test

Resources

testkit/tests/12000

Testing Document Registry Actor An overview of this test is:

• Submit above described metadata
• Issue GetSubmissionSetAndContents to verify content in registry

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12001

Accept Add New Document to Folder

Verify that the XDS.b Document Registry can accept a submission that contains a document which is added to an existing folder.

This submission consists of:

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• an HasMember Association linking the Submission Set to the Document
• an HasMember Association linking an existing Folder to this new Document
• an HasMember Association linking the Submission Set to the above Association

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

Your registry must support the GetFolderAndContents Stored Query to pass the evaluation step of this test

Resources

testkit/tests/12001

Testing Document Registry Actor An overview of this test is:

• Submit an empty folder
• Submit a document with the association to link it to the folder
• Issue GetFolderandContents Stored Query to verify contents of Registry

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12002

Reject Add Document to Folder - Patient ID does not match

Verify that the XDS.b Document Registry will reject a submission that contains a document which is added to an existing folder with a different Patient ID.

This submission consists of:

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• an HasMember Association linking the Submission Set to the Document
• an HasMember Association linking an existing Folder to this new Document
• an HasMember Association linking the Submission Set to the above Association

References

ITI TF-2 3.41

Actors Tested

Document Registry

Dependencies

Your registry must support the GetFolderAndContents Stored Query to pass the evaluation step of this test

Resources

testkit/tests/12002

Testing Document Registry Actor An overview of this test is:

• Submit an empty folder
• Submit a document with the association to link it to the folder. The Patient ID on the Document does not match that on the Folder.
• Issue GetFolderandContents Stored Query to verify contents of Registry. The Document must not be a member of the Folder.

The test steps are:

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12004

Reject Duplicate Document uniqueID with Different Hash (XDS.b)

Verify that the XDS.b Document Registry will

accept a duplicate XDSDocumentEntry, with same XDSDocumentEntry.uniqueId, if XDSDocumentEntry.hash is the same

reject if the hash is different

References

ITI TF-2 3.41

Actors Tested

XDS.b Document Registry

Dependencies

None

Resources

testkit/tests/12004

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12005

Register with mutual TLS

Repeat test 11990 over TLS

12020

Retrieve Documents over TLS

Verify that the XDS.b Document Consumer can use the Retrieve Document Set transaction to retrieve documents from a Document Repository over a TLS channel.

References

ITI TF-2 3.43

Actors Tested

Document Consumer

Dependencies

None

Resources

Test data - pre-loaded into the Public Registry

Testing Document Repository Actor

Submit a Retrieve Document Set transaction to the Public Repository and successfully accept the return document. The request may be for one or more documents.

1. Follow Generic Testing Procedures Using Public Registry Server for declaring results.

12021

Accept Retrieve Document Set – two documents

Verify that the XDS.b Document Repository can properly respond to a Retrieve Document Set transaction requesting two documents.

References

ITI TF-2 3.43

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12021

Testing Document Repository Actor

Submit a Submission Set containing a single Document using the Provide and Register Document Set-b transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set-b transaction. With this document in your Repository, retrieve the document via the Retrieve Document Set transaction.

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb

1. Run and report the test using xdstest

Evaluation

1. Schema
2. RepositoryUniqueId matches (compares value from RetrieveDocumentSetRequest against value from RetrieveDocumentSetResponse)
3. DocumentUniqueId retrieved matches value submitted
4. mimeType matches
5. Content of document matches

12023

Retrieve Documents

Verify that the XDS.b Document Consumer can use the Retrieve Document Set transaction to retrieve documents from a Document Repository.

References

ITI TF-2 3.43

Actors Tested

Document Consumer

Dependencies

None

Resources

Test data - pre-loaded into the Public Registry

Testing Document Repository Actor

Submit a Retrieve Document Set transaction to the Public Repository and successfully accept the return document. The request may be for one or more documents.

1. Follow Generic Testing Procedures Using Public Registry Server for declaring results.

12024

Accept Retrieve

Verify that the XDS.a Document Repository can properly respond to a Retrieve transaction requesting a single document.

References

ITI TF-2 3.17

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12024

Overview

1. Submit a document
2. Query to get the URI
3. Retrieve via the URI and validate size, mimetype, hash

Testing Document Repository Actor

Submit a Submission Set containing a single Document using the Provide and Register Document Set transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set transaction. With this document in your Repository, retrieve the document via the Retrieve Document Set transaction.

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistrya

1. Run and report the test using xdstest

Evaluation

1. Retrieve runs without error
2. Mime type returned as Content-Type
3. Mime type matches the submission
4. Document size is correct
5. Hash of retrieved document matches submission

12028

Accept Retrieve Document Set – single document via TLS

Verify that the XDS.b Document Repository can properly respond to a Retrieve Multiple Documents transaction requesting a single document over a TLS channel.

References

ITI TF-2 3.43

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12028

Testing Document Repository Actor

Submit a Submission Set containing a single Document using the Provide and Register Document Set-b transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set-b transaction. With this document in your Repository, retrieve the document via the Retrieve Document Set transaction.

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb

1. Run and report the test using xdstest

Evaluation

1. Schema
2. RepositoryUniqueId matches (compares value from RetrieveDocumentSetRequest against value from RetrieveDocumentSetResponse)
3. DocumentUniqueId retrieved matches value submitted
4. mimeType matches
5. Content of document matches
6. Communication to the Repository is over a TLS channel

12029

Accept Retrieve Document Set – single document

Verify that the XDS.b Document Repository can properly respond to a Retrieve Multiple Documents transaction requesting a single document.

References

ITI TF-2 3.43

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12029

Testing Document Repository Actor

Submit a Submission Set containing a single Document using the Provide and Register Document Set-b transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via the Register Document Set-b transaction. With this document in your Repository, retrieve the document via the Retrieve Document Set transaction.

1. Follow Generic Testing Procedures Using xdstest
2. Have your Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb

1. Run and report the test using xdstest

Evaluation

1. Schema
2. RepositoryUniqueId matches (compares value from RetrieveDocumentSetRequest against value from RetrieveDocumentSetResponse)
3. DocumentUniqueId retrieved matches value submitted
4. mimeType matches
5. Content of document matches

12030

Audit Logging of Provide and Register

Follow generic instructions found here

12031

Audit Logging of Provide and Register

Follow generic instructions found here

12037

Accept Retrieve Document Set by Integrated Source/Repository – two documents

Verify that the XDS.b Integrated Document Source/Repository can properly respond to a Retrieve Multiple Documents transaction requesting two documents.

References

ITI TF-2 3.43

Actors Tested

Integrated Source/Repository

Dependencies

Test 12038 establishes the test data need to run this test

Resources

testkit/tests/12038 section of test kit

Testing Integrated Source/Repository Actor

The detailed instructions are found in testkit/tests/12037/readme.txt. The overview is to re-run test 12038 after editing the testplan.xml file and adding the second document submitted in 12038 to the retrieve request.

12038

Accept Retrieve Document Set by Integrated Source/Repository – single document

Verify that the XDS.b Integrated Document Source/Repository can properly respond to a Retrieve Multiple Documents transaction requesting a single document.

References

ITI TF-2 3.43

Actors Tested

Integrated Source/Repository

Dependencies

Resources

testkit/tests/12038

Testing Integrated Source/Repository Actor

The detailed instructions are found in testkit/tests/12038/readme.txt. The overview is to create two documents in your repository and identify the unique IDs. One of the documents is retrieved using the testplan in tests/12038 and the xdstest tool. Results of the testplan and Test Log message IDs are logged to Kudu. The data created in this test is used for other Integrated Source/Repository tests.

12045

Accept Retrieve Document

Verify that the XDS.a Integrated Source/Repository can properly respond to a Retrieve transaction requesting a single document.

References

ITI TF-2 3.17

Actors Tested

Integrated Source/Repository

Dependencies

None

Resources

testkit/tests/12045

Testing Integrated Source/Repository Actor

1. Follow test instructions found in testkit/tests/12045/readme.txt

Evaluation

1. Query runs without error
2. Retrieve runs without error
3. Correct Mime type returned as Content-Type
4. Mime type matches the submission (according to <ExpectedMimeType/>)
5. Document size is correct (according to <ReferenceDocument/>)
6. Hash of retrieved document matches submission (according to <ReferenceDocument/>)

12046

Provide and Register-b (XDS.b and XDR) with mutual TLS

Repeat test 12049 with mutual TLS enabled.

12047

Submit two documents via XDS.b or XDR

Verify that the XDS.b Document Source can submit two documents together via the Provide and Register Document Set-b transaction.

This transaction is identical for the Document Source implementing XDR.

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/12047

XDS Test Log Browser

Testing Document Source Actor Submit a Submission Set containing two Documents using the Provide and Register Document Set-b transaction

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/repositoryB2doc

1. Report the test

12049

Submit one document via XDS.b or XDR

Verify that the XDS.b Document Source can submit a single document via Provide and Register Document Set-b transaction.

Document Sources implementing XDR use this same test because the transaction is the same.

References

ITI TF-2 3.41

Actors Tested

Document Source

Dependencies

None

Resources

testkit/examples/12049

XDS Test Log Browser

Testing Document Source Actor Submit a Submission Set containing a single Document using the Provide and Register Document Set-b transaction

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/repositoryBonedoc

1. Report the test

12051

Register one document via XDS.b

Verify that the XDS.b Combined Document Source / Document Repository can register a single document via Register Document Set-b transaction.

References

ITI TF-2 3.42

Actors Tested

Integrated Document Source / Document Repository

Dependencies

None

Resources

examples/12051 section of test kit

XDS Test Log Browser

Testing Document Source Actor Submit a Submission Set containing a single Document using the Register Document Set-b transaction to the Public Registry.

1. Follow Generic Testing Procedures Using Public Registry Server
2. Configure your Combined Document Source / Document Repostory actor to send to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryBonedoc

1. Report the test

12052

Register One Document via XDS.a with mutual TLS

Verify that the XDS.a Integrated Source/Repository can register a document over mutual TLS.

References

ITI TF-2 3.14

ITI TF-2 3.19

Actors Tested

Integrated Document Source / Document Repository

Dependencies

None

Resources

XDS Test Log Browser

Testing Integrated Source/Repository Actor

1. Have your Source/Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryAonedoc

1. Report the test

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. TLS secure connection used

12053

Register One Document via XDS.b with mutual TLS

Verify that the XDS.b Integrated Source/Repository can register a document over mutual TLS.

References

ITI TF-2 3.42

ITI TF-2 3.19

Actors Tested

XDS.b Integrated Source/Repository

Dependencies

None

Resources

XDS Test Log Browser

Testing Integrated Source/Repository Actor

1. Have your Source/Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryBonedoc

1. Report the test

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. TLS secure connection used

12054

Register Two Documents via XDS.a

Verify that the XDS.a Integrated Source/Repository can register two documents in a single submission set.

References

ITI TF-2 3.14

Actors Tested

XDS.a Integrated Source/Repository

Dependencies

None

Resources

XDS Test Log Browser

Testing Integrated Source/Repository Actor

1. Have your Source/Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryA2doc

1. Report the test

Evaluation by the Public Registry

1. Schema
2. Metadata Validator

12055

Register Two Documents via XDS.b

Verify that the XDS.b Integrated Source/Repository can register two documents in a single submission set.

References

ITI TF-2 3.41

Actors Tested

XDS.b Integrated Source/Repository

Dependencies

None

Resources

XDS Test Log Browser

Testing Integrated Source/Repository Actor

1. Have your Source/Repository forwards metadata to the WS Endpoint based on this pattern

http://ihexds.nist.gov:PORT/EVENT/services/registryB2doc

1. Report the test

Evaluation by the Public Registry

1. Schema
2. Metadata Validator

12074

Audit Logging of Stored Query

Follow generic instructions found here

12076

Audit Logging of Retrieve Multiple

Follow generic instructions found here

12083

Accept Retrieve Document Set by Integrated Source/Repository – retrieve one document over TLS

Verify that the XDS.b Integrated Document Source/Repository can properly respond to a Retrieve Multiple Documents transaction requesting one document when the connection is over a TLS channel.

Repeat test 12038 using TLS.

12084

Submission Stored - All or Nothing (XDS.b)

A submission including a Submission Set and two documents is submitted to the Registry. One of the two documents is missing the repositoryUniqueId attribute and will therefore cause an error. A stored query is then used to verify that no Submission Set nor documents are stored in the registry with status Approved.

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/12084

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

Evaluation by xdstest

1. The xdstest2 tool will verify that:

the submission failed

the query returns no Submission Set or Documents

12085

Provide and Register (XDS.a) with mutual TLS

Repeat any Provide and Register test with mutual TLS enabled.

12086

Provide and Register-b (XDS.b) with mutual TLS

Repeat 11966 with mutual TLS enabled.

12300

FindDocuments XGQ for LeafClass

An Initiating Gateway actor implementation issues a FindDocuments Cross Gateway Query (XGQ) to the Public Registry's Responding Gateway requesting LeafClass (full metadata) be returned.

References

ITI TF-2 3.38

Actors Tested

Initiating Gateway

Dependencies

Public Registry Server

Resources

Test Data Description (test 12318)

Current Patient ID to use is documented here.

XDS Test Log Browser

Example Cross Gateway Query request in examples/12300/testplan.xml (contents of /TestPlan/TestStep/StoredQueryTransaction/Metadata element). For help interpreting the test plan look here.

Testing Tools (see Test Kit Download)

Test Procedure

1. Configure your Initiating Gateway to send Cross Gateway Query transactions to EndPoint http://ihexds.nist.gov:EVENT/YEAR/services/test12300 on the Public Registry Server. See here for explanation of EVENT and YEAR in the endpoint.
2. Issue a FindDocuments XGQ with
   • returnType = LeafClass
   • no home attribute (documented in profile as homeCommunityId)
   • Patient ID to use is documented here.
3. You must receive back 2 ExtrinsicObject elements (XDSDocumentEntry objects)
4. Upon success log your results using procedures documented here

12301

Cross Gateway Retrieve of a single document

Issue Cross Gateway Retrieve for a single document based on metadata returned in test 12300. The metadata returned for 12300 contains two ExtrinsicObjects representing two documents. You can choose either for retrieval. The Cross Gateway Retrieve must be MTOM coded since the response will have to be so.

References

ITI TF-2 3.39

Actors Tested

Initiating Gateway

Dependencies

Public Registry Server

Resources

Metadata returned from test 12300

XDS Test Log Browser

Example Cross Gateway Retrieve request in examples/12301/testplan.xml (contents of /TestPlan/TestStep/RetrieveTransaction/Metadata element) in Testing Tools (see Test Kit Download). For help interpreting the test plan look here.

Test Procedure

1. After successfully executing test 12300, extract from the results
   • home attribute (documented as homeCommunityId)
   • XDSDocumentEntry.uniqueId attribute from one of the documents returned in metadata
   • XDSDocumentEntry.repositoryUniqueId attribute from the same document
2. Configure your Initiating Gateway to send Cross Gateway Retrieve transactions to EndPoint http://ihexds.nist.gov:EVENT/YEAR/services/rg on the Public Registry Server. The request must be MTOM encoded.
3. Issue a Cross Community Retrieve transaction with the above 3 attributes
4. Verify that 1 document is returned
5. Upon success log your results using procedures documented here

12302

FindDocuments XGQ for LeafClass

Repeat test 12300 over TLS.

12303

FindDocuments XGQ for LeafClass

Repeat test 12301 over TLS.

12306

FindDocuments XGQ for ObjectRef

An Initiating Gateway actor implementation issues a FindDocuments Cross Gateway Query (XGQ) to the Public Registry's Receiving Gateway requesting ObjectRefs (document references) be returned.

References

ITI TF-2 3.38

Actors Tested

Initiating Gateway

Dependencies

Public Registry Server

Resources

Test Data Description (test 12318)

Current Patient ID to use is documented here.

XDS Test Log Browser

Example Cross Gateway Query request in examples/12306/testplan.xml (contents of /TestPlan/TestStep/StoredQueryTransaction/Metadata element). For help interpreting the test plan look here.

Testing Tools (see Test Kit Download)

Test Procedure

1. Configure your Initiating Gateway to send Cross Gateway Query transactions to EndPoint http://ihexds.nist.gov:EVENT/YEAR/services/test12306 on the Public Registry Server. See here for explanation of EVENT and YEAR in the endpoint.
2. Issue a FindDocuments XGQ with
   • returnType = ObjectRef
   • no home attribute (documented in profile as homeCommunityId)
   • Patient ID to use is documented here.
3. You must receive back 2 ObjectRef elements
4. Upon success log your results using procedures documented here

12307

GetDocuments XGQ for LeafClass

Initiate a GetDocuments Cross-Gateway Query (XGQ) to the Public Registry's Responding Gateway for documents discovered in test 12306. Request LeafClass be returned.

This test follows the pattern than an initial query for documents should always request ObjectRefs since it cannot be known how many documents will be returned. Test 12306 issued the FindDocuments query receiving back ObjectRefs. For this test, have your Initiating Gateway issue a follow-on GetDocuments Stored Query for the two documents discovered in test 12306.

References

ITI TF-2 3.38

Actors Tested

Initiating Gateway

Dependencies

Public Registry Server

Resources

Test Data Description (test 12318)

Test Data Description (test 12306)

XDS Test Log Browser

Example Cross Gateway Query request in examples/12307/testplan.xml (contents of /TestPlan/TestStep/StoredQueryTransaction/Metadata element). For help interpreting the test plan look here.

Testing Tools (see Test Kit Download)

Test Procedure

1. Configure your Initiating Gateway to send Cross Gateway Query transactions to EndPoint http://ihexds.nist.gov:EVENT/YEAR/services/test12307 on the Public Registry Server. See here for explanation of EVENT and YEAR in the endpoint.
2. Issue a GetDocuments XGQ with
   • returnType = LeafClass
   • home attribute must be the value returned from the FindDocuments SQ (documented in profile as homeCommunityId)
3. You must receive back 2 ExtrinsicObject elements
4. Upon success log your results using procedures documented here

12308

Cross Gateway Retrieve of a multiple document

Issue Cross Gateway Retrieve for a multiple documents based on metadata returned in test 12300. The metadata returned for 12300 contains two ExtrinsicObjects representing two documents. You must issue a single Retrieve Multiple Documents transaction for both documents. The Cross Gateway Retrieve must be MTOM coded since the response will have to be so.

References

ITI TF-2 3.39

Actors Tested

Initiating Gateway

Dependencies

Public Registry Server

Resources

Metadata returned from test 12300

XDS Test Log Browser

Example Cross Gateway Retrieve request in examples/12301/testplan.xml (contents of /TestPlan/TestStep/RetrieveTransaction/Metadata element) in Testing Tools (see Test Kit Download). For help interpreting the test plan look here.

Test Procedure

1. After successfully executing test 12300, extract from the results
   • home attribute (documented as homeCommunityId)
   • XDSDocumentEntry.uniqueId attribute from both documents returned in metadata
   • XDSDocumentEntry.repositoryUniqueId attribute for each document
2. Configure your Initiating Gateway to send Cross Gateway Retrieve transactions to EndPoint http://ihexds.nist.gov:EVENT/YEAR/services/rg on the Public Registry Server. The request must be MTOM encoded.
3. Issue a Cross Community Retrieve transaction with the above 3 attributes
4. Verify that 2 documents are returned
5. Upon success log your results using procedures documented here

12309

FindDocuments XGQ for ObjectRef

Receiving Gateway accepts FindDocuments Cross Gateway Query requesting ObjectRefs be returned. ObjectRefs are simple references to XDS Metadata objects. They are small, in their XML form, and easy to pass even when large number of objects must be listed.

References

ITI TF-2 3.38

Actors Tested

Receiving Gateway

Dependencies

Test 12318 must be run before this test

Resources

tests/12309 section of test kit

xdstest2 testing tool

Other Testing Tools

Test Procedure

Submit a Cross Gateway Query transaction to your Receiving Gateway implementation using the xdstest2 tool.

1. Configure and run the test plan from the test kit to perform the Cross Gateway Query
2. Evaluate the results.
3. Log the results. You need to return the log.xml file.

12310

FindDocuments XGQ for LeafClass

Responding Gateway accepts FindDocuments Cross Gateway Query requesting LeafClass be returned. A LeafClass request returns the full XDS Metadata for the objects identified in the query. Requesting too may objects in this form can lead to XML processing issues.

References

ITI TF-2 3.38

Actors Tested

Responding Gateway

Dependencies

Test 12318 must be run before this test

Resources

tests/12310 section of test kit

xdstest2 testing tool

Other Testing Tools

Test Procedure

Submit a Cross Gateway Query transaction to your Responding Gateway implementation using the xdstest2 tool.

1. Configure and run the test plan from the test kit to perform the Cross Gateway Query
2. Evaluate the results.
3. Log the results. You need to return the log.xml file.

12311

GetDocuments XGQ for LeafClass

Responding Gateway accepts GetDocuments Cross Gateway Query requesting LeafClass be returned. A FindDocuments query has already been run (test 12309) and returned ObjectRefs matching a particular Patient Id. This query retrieves metadata for one or more documents discovered through the FindDocuments query.

A LeafClass request returns the full XDS Metadata for the objects identified in the query. Requesting too may objects in this form can lead to XML processing issues.

References

ITI TF-2 3.38

Actors Tested

Responding Gateway

Dependencies

Test 12318 must be run before this test

Test 12309 must be run before this test

Resources

tests/12311 section of test kit

xdstest2 testing tool

Other Testing Tools

Test Procedure

Submit a Cross Gateway Query transaction to your Responding Gateway implementation using the xdstest2 tool.

1. Configure and run the test plan from the test kit to perform the Cross Gateway Query
2. Evaluate the results.
3. Log the results. You need to return the log.xml file.

12312

Cross Gateway Retrieve

A Cross Gateway Retrieve transaction is sent to the Responding Gateway being tested. The parameters of the retrieve are taken from metadata returned in test 12311.

References

ITI TF-2 3.39

Actors Tested

Responding Gateway

Dependencies

Test 12311 must be run before this test

Resources

tests/12312 section of test kit

xdstest2 testing tool

Other Testing Tools

Test Procedure

Submit a Cross Gateway Retrieve transaction to your Responding Gateway implementation using the xdstest2 tool.

1. Configure and run the test plan from the test kit to perform the Cross Gateway Query
2. Evaluate the results.
3. Log the results. You need to return the log.xml file.

12314

FindDocuments XGQ for ObjectRef

Repeat 12309 over TLS.

12318

Receiving Gateway Test initialization

Establish test data in systems behind Receiving Gateway. There are two sets of instructions.

Receiving Gateway has no Registry behind it

These instructions apply to Responding Gateways that do not have an XDS Affinity domain (and therefore no XDS Registry and Repository actors) behind them. This test data must have the following characteristics:

• Single Patient ID
• Metadata for two documents
  • Metadata coding shall conform to Public Registry Affinity Domain configuration
  • Metadata is required to conform to Schema and Metadata requirements as evaluated by Metadata Validator tool.
  • Must be returned consistently for each Cross Gateway Query request (metadata for a document is static)
• Two documents matching metadata
  • uniqueId of document matches metadata XDSDocumentEntry object
  • Size, hash, and mimeType attributes in metadata must match document content
  • MimeType must be renderable in a typical web browser without special plugins. If mimeType if text/xml then style sheet must be exist, document must have appropriate processing instruction referencing style sheet, and style sheet must be reference-able. (in other words, text/xml must display through style sheet)

The tests that rely on this procedure to establish the testdata for query/retrieve need the log.xml file that would be generated if you had a Registry/Repository actors behind the gateway. To enable the tool automation:

• Retrieve your two documents via your own tools and place into testkit/testdata/12318/my_document.txt and testkit/testdata/12318/summary.xml. The testplans are built to reference these two document to verify size and hash post retrieval.
• Run this test, using xdstest, against the Public Registry
• Hand edit the log.xml file filling in the following details:
  • /TestResults/TestStep/ProvideAndRegisterTransaction/AssignedPatientId - fill in your Patient ID in all sections
  • /TestResults/TestStep/ProvideAndRegisterTransaction/AssignedUids - fill in your unique IDs in all sections

Now the tests that depend on this test can be run and will pull the Patient ID and uniqueIDs as necessary.

Receiving Gateway has a Registry behind it

This test also applies to the Public Registry. The section testdata/12318 of the testkit contains the necessary submission to initialize this data. This has been used to initialize the Public Registry. Initiating Gateway tests reference this data. If you have a Registry behind your Receiving Gateway you can create the test data as described in the previous section or use the testdata/12318 section of the test kit. If you use the test kit, configure the test by inserting your own endpoint into the <RegistryEndpoint/> element.

The test kit data contains two documents with metadata. One document is simple test (about 5 lines) and the second is a Patient Summary Record.

Test 12318 Patient ID

Current Patient ID in the Public Registry

The Patient IDs available are documented here.

References

ITI TF-2 3.38 and ITI TF-2 3.39

Actors Tested

None

Dependencies

None

Resources

None

Test Procedure

None

12320

Registry SOAP Pattern

Test an XDS.b Document Registry implementation to prove it can accept a SIMPLE SOAP message. This message type is use for both the Stored Query and Register.b transactions.

References

ITI TF-2 3.18 and 3.41

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12320

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12321

Repository SOAP Pattern

Test an XDS.b Document Repository implementation to prove it can accept an Optimized MTOM/XOP and Unoptimized MTOM/XOP SOAP messages. These message types are used for both the Provide and Register-b and Retrieve Multiple Documents transactions.

References

ITI TF-2 3.41 and 3.43

Actors Tested

Document Repository

Dependencies

Public Registry Server

Resources

testkit/tests/12321

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12322

Folder lastUpdateTime

Test an XDS.a Document Registry implementation to prove it can properly manage the XDSFolder.lastUpdateTime attribute.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12322

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12323

Folder lastUpdateTime

Test an XDS.b Document Registry implementation to prove it can properly manage the XDSFolder.lastUpdateTime attribute.

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12323

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12324

Accept Document Replace, Document in Folder

A Document Registry (XDS.a), when accepting a Document Replace, must find all Folders the original document is a member of and add the replacement document to those folders.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12324

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12325

Add Existing document to existing folder

This test validates a Registry's ability to perform a basic Folder operation, adding a Document already in Registry to a Folder also already in Registry.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12324

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12326

Add Existing document to existing folder

This test validates a Registry's ability to perform a basic Folder operation, adding a Document already in Registry to a Folder also already in Registry.

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12326

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12327

Accept Document Replace, Document in Folder

A Document Registry (XDS.b), when accepting a Document Replace, must find all Folders the original document is a member of and add the replacement document to those folders.

References

ITI TF-2 3.42

Actors Tested

Document Registry

Dependencies

Public Registry Server

Resources

testkit/tests/12327

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12328

Install test data for XDS.a Query and Retrieve tests. This test uses Provide and Register.a to submit data. The target repository must be configured to point to a registry.

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

None

Dependencies

testkit/testdata/12328

Performing test data installation

1. Follow Generic Testing Procedures Using xdstest

12329

Allocate Patient ID

This test is used to initialize the xdstest tool with a Patient ID allocated from the Public Registry server. This test will need to be rerun when you install a new copy of the xdstoolkit. It uses the pidallocate service on the Public Registry to create the Patient ID and saves it into the xdstest section of the xdstoolkit. This is necessary as a precursor for tests that send to the Public Registry which requires the use of a known patient id.

Only run this test if you run another test that sends to the Public Registry through your Document Repository and a Patient ID is not known to the Registry error occurs.

References

None

Actors Tested

None

Dependencies

none

Resources

testkit/tests/12329

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Do not report this test.

12331

Accept ASync Stored Query

A Stored Query request is sent to a Document Registry actor over asynchronous web services. Besides handling the Stored Query correctly, the asynchronous web service must be handled properly.

References

Asynchronous Web Services Exchange

Actors Tested

Document Registry

Dependencies

Test testkit/testdata/11890 which loads test data

Resources

testkit/testdata/11890

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12333

Accept one document via Asynchronous XDS.b

A Provide and Register.b request is sent to a Document Repository actor over asynchronous web services. Besides handling the Provide and Register.b correctly, the asynchronous web service must be handled properly. The metadata must be updated properly and an asynchronous Register.b transaction must be sent to the Public Registry.

References

ITI TF-2 3.41

ITI TF-2 3.42

Asynchronous Web Services Exchange

Test 11966 (this is the asynchronous version of test 11966)

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12333

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Testing Document Repository Actor

Submit a Submission Set containing a single Document using an asynchronous Provide and Register Document Set-b transaction to your Repository. Your Repository forwards the metadata on to the Public Registry via an asynchronous Register Document Set-b transaction.

• One of two configurations must be used.
  • If your Document Repository is outside the firewall or your firewall is configured to allow the return message through, configure the Repository to forward metadata to

http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrybas

• • Otherwise, install and configure Synapse (directions here) and forward metadata (Register-b transaction) to Synapse.
• Follow Generic Testing Procedures Using xdstest. Remember that your Document Repository will initiate a new connection back to the xdstest machine. If these processes are running of different machines, it is possible that the xdstest machine may block the returning connection if not properly configured.
• Run and report the test using xdstest

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Correct content (Submission Set containing a single Document)
4. Correct hash and size computed by Repository actor and placed in metadata.
5. Web Service interaction is asynchronous (non-anonymous ReplyTo SOAP Header present)

Evaluation by xdstest2

1. Evaluation query returns correct metadata
2. Asynchronous Web Service interaction completes properly

12334

Accept ASync Register.b

A Register.b request is sent to a Document Registry actor over asynchronous web services. Besides handling the Register.b correctly, the asynchronous web service must be handled properly.

References

Asynchronous Web Services Exchange

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/12334

Test Procedure

1. Follow Generic Testing Procedures Using xdstest. Remember that your Document Registry will initiate a new connection back to the xdstest machine. If these processes are running of different machines, it is possible that the xdstest machine may block the returning connection if not properly configured.
2. Run and report the test using xdstest

12335

Accept ASync RetrieveDocumentSet

A RetrieveDocumentSet request is sent to a Document Repository actor over asynchronous web services. Besides handling the Retrieve correctly, the asynchronous web service must be handled properly.

References

Asynchronous Web Services Exchange

Actors Tested

Document Repository

Dependencies

Test testkit/testdata/11890 which loads test data

Resources

testkit/tests/12335

Asynchronous server testing

Test Procedure

1. Follow Generic Testing Procedures Using xdstest. Remember that your Document Repository will initiate a new connection back to the xdstest machine. If these processes are running of different machines, it is possible that the xdstest machine may block the returning connection if not properly configured.
2. Run and report the test.

12336

ASync FindDocuments XGQ for ObjectRef

Receiving Gateway accepts asynchronous FindDocuments Cross Gateway Query requesting ObjectRefs be returned. Besides handling the Cross-Gateway Query correctly, the asynchronous web service must be done correctly.

References

ITI TF-2 3.38

Actors Tested

Receiving Gateway

Dependencies

Test 12318 must be run before this test

Resources

tests/12336 section of test kit

xdstest testing tool

Other Testing Tools

Test Procedure

Submit an asynchronous Cross Gateway Query transaction to your Receiving Gateway implementation using the xdstest tool.

1. Configure and run the test plan from the test kit to perform the Cross Gateway Query
2. Evaluate the results.
3. Log the results. You need to return the log.xml file.

12337

Accept ASync Cross-Gateway Retrieve

A Cross-Gateway Retrieve request is sent to a Responding Gateway actor over asynchronous web services. Besides handling the Retrieve correctly, the asynchronous web service must be handled properly.

References

Asynchronous Web Services Exchange

Actors Tested

Responding Gateway

Dependencies

Test testkit/testdata/12318 which loads test data

Resources

testkit/tests/12337

Asynchronous server testing

Test Procedure

1. Follow Generic Testing Procedures Using xdstest. Remember that your Responding Gateway will initiate a new connection back to the xdstest machine. If these processes are running of different machines, it is possible that the xdstest machine may block the returning connection if not properly configured.
2. Run and report the test.

12338

Generate Async Provide and Register-b

A Provide and Register.b request is sent by your Document Source to the Public Repository actor over asynchronous web services. Besides handling the Provide and Register.b correctly, the asynchronous web service must be handled properly.

References

ITI TF-2 3.41

Asynchronous Web Services Exchange

Actors Tested

Document Source

Dependencies

None

Resources

testkit/tests/12333 is an example, generates this interaction for testing Document Repositories

test #12329 to allocate a Patient ID on the Public Registry (initializes xdstoolkit)

Asynchronous server testing

Testing Document Source Actor

Submit a Submission Set containing a single Document using an asynchronous Provide and Register Document Set-b transaction to the Public Repository.

• One of two configurations must be used.
  • If your Document Source is outside the firewall or your firewall is configured to allow the return message through, configure the Document Source to send to

http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositorybas

• • Otherwise, install and configure Synapse (directions here) and send the Provide and Register-b transaction to Synapse (which will forward to the Public Repository).
• Initiate the Provide and Register.b transaction from your Document Source.
• Run and report the test.

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Correct content (Submission Set containing a single Document)
4. Correct hash and size computed by Repository actor and placed in metadata.
5. Web Service interaction is asynchronous (non-anonymous ReplyTo SOAP Header present)

12339

Generate Async Stored Query

A Stored Query request is sent by your Document Consumer to the Public Registry actor over asynchronous web services. Besides handling the Stored Query correctly, the asynchronous web service must be handled properly.

References

ITI TF-2 3.18

Asynchronous Web Services Exchange

Actors Tested

Document Consumer

Dependencies

None

Resources

testkit/tests/12331 is an example, generates this interaction for testing Document Registries

Look XDS_Test_Management#Test_Data here for available test data

Asynchronous server testing

Testing Document Consumer Actor

Submit a Stored Query of your choice to the Public Registry.

• One of two configurations must be used.
  • If your Document Source is outside the firewall or your firewall is configured to allow the return message through, configure the Document Source to send to

http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrybas

• • Otherwise, install and configure Synapse (directions here) and send the Stored Query transaction to Synapse (which will forward to the Public Registry).
• Initiate the Stored Query transaction from your Document Source.
• Run and report the test. To pass this test you must find your results with the Test Log Browser and upload the EVS file into Kudu.

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Web Service interaction is asynchronous (non-anonymous ReplyTo SOAP Header present)

12340

Generate Async Cross-Gateway Query

A Cross-Gateway Query request is sent by your Initiating Gateway to the Responding Gateway actor on the Public Registry server over asynchronous web services. Besides handling the Cross-Gateway Query correctly, the asynchronous web service must be handled properly.

References

ITI TF-2 3.38

Asynchronous Web Services Exchange

Actors Tested

Initiating Gateway

Dependencies

None

Resources

testkit/tests/12336 is an example, generates this interaction for testing Responding Gateways

Look here for available test data

Asynchronous server testing

Testing Initiating Gateway Actor

Submit a Cross-Gateway Query of your choice to the Responding Gateway actor on the Public Registry server.

• One of two configurations must be used.
  • If your Initiating Gateway is outside the firewall or your firewall is configured to allow the return message through, configure the Initiating Gateway to send to

http://ihexds.nist.gov:EVENT/YEAR/services/rgas

• • Otherwise, install and configure Synapse (directions here) and send the Cross-Gateway Query transaction to Synapse (which will forward to the Public Registry server).
• Initiate the Cross-Gateway Query transaction from your Initiating Gateway.
• Run and report the test.

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Web Service interaction is asynchronous (non-anonymous ReplyTo SOAP Header present)

12341

Generate ASync Cross-Gateway Retrieve

A Cross-Gateway Retrieve request is sent by an Initiating Gateway actor over asynchronous web services to the Responding Gateway actor on the Public Registry server. Besides handling the Retrieve correctly, the asynchronous web service must be handled properly.

References

Asynchronous Web Services Exchange

Actors Tested

Initiating Gateway

Dependencies

None

Resources

testkit/tests/12337 shows an example XGR

Available test data

Asynchronous server testing

Testing Initiating Gateway Actor

Submit a Cross-Gateway Retrieve to the Responding Gateway actor on the Public Registry server.

• One of two configurations must be used.
  • If your Initiating Gateway is outside the firewall or your firewall is configured to allow the return message through, configure the Initiating Gateway to send to

http://ihexds.nist.gov:EVENT/YEAR/services/rgas

• • Otherwise, install and configure Synapse (directions here) and send the Cross-Gateway Retrieve transaction to Synapse (which will forward to the Public Registry server).
• Initiate the Cross-Gateway Retrieve transaction from your Initiating Gateway.
• Run and report the test.

Evaluation by the Public Registry

1. Schema
2. Metadata Validator
3. Web Service interaction is asynchronous (non-anonymous ReplyTo SOAP Header present)

12342

Stored Query in the presence of XCA

An implementation of the Document Consumer actor must take into account that the environment it is deployed into may include the use of the XCA profile. As such, all Document Consumer implementations must properly manage the homeCommunityId attribute. This test validates this operation. This test provides a special endpoint on the Public Registry that acts like an Initiating Gateway. Queries to it return homeCommunityId attribute. Secondary queries, those that do not have Patient ID as a parameter, require homeCommunityId as a parameter.

References

ITI TF-2 3.18.4.1.2.3.8 Use of homeCommunityId

Actors Tested

Document Consumer

Dependencies

none

Resources

Test data - pre-loaded into the Public Registry (see data loaded from 12344)

Required Endpoint You must test against a special endpoint on the Public Registry:

http://ihexds.nist.gov:EVENT/YEAR/services/xcaregistry

Look here for information about Public Registry endpoints, especially about the correct values for EVENT and YEAR.

This endpoint acts like an Initiating Gateway that forwards to the local Registry. It requires homeCommunityId to be present in all Stored Queries that do not have Patient ID as a parameter.

Testing Document Consumer Actor

The general requirements for a Document Consumer is that it show it can properly manage the homeCommunityId when in the presence of an XCA environment.

1. You must test all Stored Queries and combinations of Stored Queries that your implementation utilizes against this endpoint.
2. Report your results following the instructions here

12343

Retrieve Documents in the presence of XCA

An implementation of the Document Consumer actor must take into account that the environment it is deployed into may include the use of the XCA profile. As such, all Document Consumer implementations must properly manage the homeCommunityId attribute. This test validates this operation as applied to the Retrieve Document Set transaction.

References

ITI TF-2 3.43.4.1.2 Message Semantics

Actors Tested

Document Consumer

Dependencies

Test #12342 which is a Stored Query operating in the same environment.

Required Endpoint You must test against a special endpoint on the Public Repository:

http://ihexds.nist.gov:EVENT/YEAR/services/xcarepository

Look here for information about Public Registry endpoints, especially about the correct values for EVENT and YEAR. Pay close attention to the information regarding homeCommunityId.

Testing Document Consumer Actor

1. Issue a Stored Query to access metadata for a document of interest following instructions in test #12342.
2. Based on this metadata, submit a Retrieve Document Set transaction to the Public Repository based on metadata from test #12342 and successfully accept the return document. The request may be for one or more documents. The request must include the homeCommunityId parameter.
3. Submit results using instructions found here.

12345

Install test data for XDS.b Query and Retrieve tests. This test uses Provide and Register.b to submit data. The target repository must be configured to point to a registry.

Note that this test data is identical to the data loaded by test 12328. These two tests differ only by which version of Provide and Register is used to perform the submission.

References

ITI TF-2 3.41

ITI TF-2 3.42

Actors Tested

None

Dependencies

testkit/testdata/12345

Performing test data installation

1. Follow Generic Testing Procedures Using xdstest

12346

Load test data into Document Registry via Register.b transaction

This data does not contain valid references to documents in Repository. It is suitable for Stored Query testing only. Test 12346 and 12374 load identical metadata but into different Patient IDs.

References

ITI TF-2 3.42

Actors Tested

None

Dependencies

None

Resources

testkit/testdata/12346

Loading test data

1. Follow Generic Testing Procedures Using xdstest

The results of this test should not be logged in Kudu.

12347

FindDocuments Stored Query.a

Test a Document Registry's implementation of the FindDocuments Stored Query.a.

This test has multiple parts where each part focuses on one or a collection of the parameters to the FindDocuments Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 11890 must be run before this test to establish the test data in your registry

Resources

testkit/tests/12347

Testing FindDocuments Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12355

GetSubmissionSetAndContents Stored Query.a

Test a Document Registry's implementation of the GetSubmissionSetAndContents Stored Query.a.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetSubmissionSetAndContents Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 11890 must be run before this test to establish the test data in your registry

Resources

testkit/tests/12355

Testing GetSubmissionSetAndContents Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12358

GetRelatedDocuments Stored Query.a

Test a Document Registry's implementation of the GetRelatedDocuments Stored Query.a.

This test has multiple parts where each part focuses on one or a collection of the parameters to the GetRelatedDocuments Stored Query.

References

ITI TF-4 3.18

Actors Tested

Document Registry

Dependencies

Test 11890 must be run before this test to establish the test data in your registry

Resources

testkit/tests/12358

Testing GetRelatedDocuments Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12359

XDS.a Retrieve MIME Type

Test a Document Repository implementation's ability to reproduce new MIME Types.

At Connectathons, many XDS.a Document Repository actors struggle with tests because they are poorly prepared to respond to new MIME Types. This test forces the use of a new an foolish mime type text/goofy which the Repository must reproduce in responding to the Retrieve.a transaction. To see other MIME types you may struggle with, visit http://ihexds.nist.gov:9080/xdsref/codes/codes.xml, towards the bottom, where other important mime types are listed.

References

ITI TF-2 3.17

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12359

Testing GetRelatedDocuments Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12360

XDS.b Retrieve MIME Type

Test a Document Repository implementation's ability to reproduce new MIME Types.

At Connectathons, many XDS.b Document Repository actors struggle with tests because they are poorly prepared to respond to new MIME Types. This test forces the use of a new an foolish mime type text/goofy which the Repository must reproduce in responding to the Retrieve.b transaction. To see other MIME types you may struggle with, visit http://ihexds.nist.gov:9080/xdsref/codes/codes.xml, towards the bottom, where other important mime types are listed.

References

ITI TF-2 3.43

Actors Tested

Document Repository

Dependencies

None

Resources

testkit/tests/12360

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12361

Load test data for testing FindDocumentsForMultiplePatients

This data does not contain valid references to documents in Repository. It is suitable for Stored Query testing only.

References

ITI TF-2 3.51

Actors Tested

None

Dependencies

None

Resources

testkit/testdata/12361

Loading test data

1. Follow Generic Testing Procedures Using xdstest

The results of this test should not be logged in Kudu.

12362

XDS.a vs XDS.b Retrieve

The Technical Framework states that the Document Repository broadcasts which retrieve transactions it supports by the metadata it sends to the Document Registry. If an XDSDocumentEntry is sent to the registry containing the attribute XDSDocumentEntry.URI then the Document Repository is agreeing to support the XDS.a Retrieve transaction [ITI-17] for its retrieval. If an XDSDocumentEntry is sent to the registry containing the attribute XDSDocumentEntry.repositoryUniqueId then the Document Repository is agreeing to support the XDS.b Retrieve Document Set transaction [ITI-43]. Remember that the Provide and Register transaction (.a or .b) may deliver to the Document Repository XDSDocumentEntry objects already containing these attributes which the Document Repository must update or remove to fulfill its contract.

References

ITI TF-2 3.43

ITI TF-2 3.17

Actors Tested

Document Repository

Dependencies

None

Resources

None

Test Procedure

1. Inspect your software to ensure this rule is obeyed. If software inspection is difficult then run test 12359 (XDS.a) and/or 12360 (XDS.b) and inspect the metadata your repository sent to the Public Registry. It can be found in the test log (log.xml) file 12359/query/log.xml or 12360/query/log.xml. In one of these files inspect the attributes /TestResults/TestStep/StoredQueryTransaction/Result/AdhocQueryResponse/RegistryObjectList/ExtrinsicObject/Slot[name='URI'] and /TestResults/TestStep/StoredQueryTransaction/Result/AdhocQueryResponse/RegistryObjectList/ExtrinsicObject/Slot[name='repositoryUniqueId']
2. Mark your test completed in Kudu/Gazelle. There is nothing to upload.

12363

Demonstrate use of at least one SQ

A Document Consumer must demonstrate the use of at least one Stored Query. The individual XDS.a and XDS.b Stored Query consumer tests are all shown as Optional. This test allows a Document Consumer to show they can successfully use at least one.
As results for this test in kudu, upload a text file which indicates which stored queries your system has tested and will provide test results for.

References

ITI TF-4 3.18

Actors Tested

Document Consumer

Dependencies

Any XDS.a or XDS.b Stored Query test

Resources

none

12364

FindDocumentsForMultiplePatients Stored Query

Test a Document Registry's implementation of the FindDocumentsForMultiplePatients Stored Query.

This test has multiple parts where each part focuses on one or a collection of the parameters to the FindDocumentsForMultiplePatients Stored Query.

References

ITI TF-4 3.51

Actors Tested

Document Registry

Dependencies

Test 12361 must be run before this test to establish the test data in your registry

Resources

testkit/tests/12364

Testing FindDocumentsForMultiplePatients Stored Query

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12366

Generic instructions for testing Document Consumer implementations of FindDocumentsForMultiplePatients.

References

ITI TF-2 3.51

Actors Tested

Document Consumer

Dependencies

testkit/testdata/12361

Test Data Test data for this test is pre-loaded on the Public Registry for your use. The Patient IDs currently available on the Public Registry server are documented here. When examining available test data note that some Patient IDs have real documents in the Repository and other do not. Choose wisely on your quest.

This test data set consists of two submissions each with a unique Patient ID.

Patient ID xxx contains three DocumentEntry objects with codes:
Document01) MPQ-classcode-1, MPQ-eventcode-1, MPQ-hcftcode-1
Document02) MPQ-classcode-1, MPQ-eventcode-2, MPQ-hcftcode-2
Document03) MPQ-classcode-1, MPQ-eventcode-2, MPQ-hcftcode-2
Patient ID yyy contains one DocumentEntry objects with codes
Document01) MPQ-classcode-1, MPQ-eventcode-1, MPQ-hcftcode-1

Test Procedure

1. Using above test data, test your Document Consumer's Stored Queries. Test any and all Stored Queries that your implementation requires. You must show evidence of testing at least one Stored Query.
2. Submit evidence of your work using instructions found here.

12368

Testing the XDSResultNotSinglePatient Error.

The Document Registry must never return full metadata (LeafClass) for more than one Patient ID in a single response. When ObjectRefs are requested, there is no restriction since PII is not being disclosed.

References

ITI TF-6, table 4.1-11 Error Codes

ITI Transaction 18

Actors Tested

Document Registry

Dependencies

testkit/testdata/12374

testkit/testdata/12346

Test Data

Each of these tests (in the testdata section) contributes test data from different Patient IDs.

Test Procedure

Each section tests a different combination of (ObjectRef vs LeafClass) against (DocumentEntry OR Folder OR SubmissionSet)

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12369

Testing the XDSRepositoryMetadataError Error as applied to supplied size and hash attributes.

If size or hash attribute is supplied in the Provide and Registry transaction, it must match the supplied document. XDSRepositoryMetadataError is returned if the values do not match.

References

ITI TF-6, table 4.1-5

Actors Tested

Document Registry

Dependencies

None

Test Data

None

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12370

Test the Registry actors management of a Association Documentation Classifications.

Lifecycle management type associations may include a special Classification that labels the reason for the lifecycle operation. These reasons are formatted as Classifications and are part of the Affinity Domain configuration. Since they are part of the Affinity Domain configuration they are validated against that configuration.

References

ITI TF-6, section 4.1.6.1

Actors Tested

Document Registry

Dependencies

None

Test Data

None

Test Procedure

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

12371

Accept one document via XDR

Verify that the XDR Document Recipient can accept a single document via the Provide and Register Document Set-b transaction. There are no requirements on what the Document Recipient does with the metadata and document.

References

ITI TF-2 3.41

Actors Tested

Document Recipient

Dependencies

None

Resources

testkit/tests/12371

This test uses the XDS Toolkit (xdstest tool and testkit data) to issue a Provide and Register.b transaction to your Document Recipient actor. You will have to install the toolkit (testkit data comes inside) and use xdstest to run test 12371 which will issue the PnR transaction to your Document Recipient. The toolkit will require configuration: the xdstoolkit/xdstest/actors.xml file will need editing to create your site definition. Transaction definitions for pr.b and pr.b with secure=1 along with the PidAllocateEndpoint section are the only required settings within the site. There is an example site named xdr.example already available you can start with.

Example request and response is documented here.

Testing Document Recipient Actor

1. Follow Generic Testing Procedure s Using xdstest
2. Run and report the test using xdstest

Evaluation by xdstest2

1. The correct response to a Provide and Register.b is returned.

12372

Accept one document via XDR over TLS

Repeat test 12371 over TLS.

12373

Accept two documents via XDR

Repeat test 12371 with the payload containing two instead of one document.

12374

Load test data into Document Registry via Register.b transaction

This data does not contain valid references to documents in Repository. It is suitable for Stored Query testing only. Test 12346 and 12374 load identical metadata but into different Patient IDs.

References

ITI TF-2 3.42

Actors Tested

None

Dependencies

None

Resources

testkit/testdata/12374

Loading test data

1. Follow Generic Testing Procedures Using xdstest

The results of this test should not be logged in Kudu.

Query - Testing the Document Registry

This test procedure is used for all Queries.

Verify that a Document Registry can service each query type.

References

ITI TF-2 3.16

Actors Tested

Document Registry

Dependencies

Test 11870 must be run before this test to establish test data

Testing Document Registry Actor

1. Edit the test.properties file in the appropriate directory in tests/ (directory is test number).
   • Change the URL parameter to point to your registry.
2. Configure the SQL (in metadata.xml in the test directory) to include only the query parameters you need to use. See #Query - Configuring the SQL queries supplied in the testkit for instructions.
3. Run the tests using xdstest.
4. Verify that you get a successful RegistryResponse messages in return containing ExtrinsicObject(s)
5. Log the results: #Log_Results_of_Query_or_Stored_Query_transaction_against_your_Registry

Query - Testing the Document Consumer

Verify that Document Consumer can use the Query facility.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Dependencies

None

Testing Document Consumer Actor

1. When building your Document Consumer, you may reference the SQL provided in the test kit. You will need to configure the SQL (in metadata.xml in the test directory) to include only the query parameters you need to use. See #Query - Configuring the SQL queries supplied in the testkit for instructions.
2. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
3. Have your Document Consumer issue the Query. Examples are found in tests/ by the test number
4. Log the results: #Log_Results_of_Query_or_Stored_Query_transactions_tested_against_the_Public_Registry

Stored Query - Testing the Document Registry

The testing of all Stored Queries follows the same instructions. Note that their are different test scripts for XDS.a and XDS.b in the testkit. The individual test number points you to the correct script.

References

ITI TF-2 3.18

Actors Tested

Document Registry

Dependencies

test #11890 - load test data set 3

Testing Document Registry Actor

1. Follow Generic Testing Procedures Using xdstest
2. Run and report the test using xdstest

Query - Configuring the SQL queries supplied in the testkit

The SQL queries supplied with the test kit (tests 11910 - 11922) have extra information in the metadata.xml file that must be edited out before using. To edit:

1. Decide what optional parameters to the query you want to use
   • The file contains psuedo-comments starting with the pound character (#) and ending with end-of-line.
   • A comment containing the name of an optional parameter indicates that that line is necessary in the query if that optional parameter is used. An example of an optional parameter name is $XDSDocumentEntryConfidentialityCode.
2. Delete all lines containing comments which contain parameter names you do not wish to be in your query (filter out unwanted parameters)
3. Delete the remaining comments (not the line, just the comment part)
4. You should be left with SQL imbedded in XML. This SQL will still contain parameter names embedded in the SQL statements
5. Subtitute your values for the parameter names

Syslog Tests

General instructions for testing syslog

References

None

Actors Tested

Document Source, Document Consumer, Document Registry, Document Repository

Dependencies

None

You will need to

None

Resources

Syslog Browser available at http://129.6.24.109:9080/SyslogBrowser/index.html

Testing For each actor under test, direct Syslog submissions to IP: 129.6.24.109 PORT: 8087

Logging Results Log in Kudu the Message Number which can be found at the top of the Message Display panel (right half of screen)

Contributed Content

Scan Document (CDA wrapped PDF)

In the Public Registry:

XDSDocumentEntry.uniqueId = 1.2.3.4.100000022002209036.1196211173506.1

URI = http://129.6.24.109:9080/Repository/1.2.3.4.100000022002209036.1196211173506.1.xml