XDS Test Kit 2009-2010 Test Descriptions

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 xdstest testing tool (part of the XDS Toolkit). 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.

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 12346 must be run before this test to establish the test data in your registry

Resources

testkit/testdata/12346

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

FindDocuments Stored Query and 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

FindSubmissionSets Stored Query.

See #11936 for details.

11938

FindFolders Stored Query

See #11936 for details.

11939

GetAll Stored Query

See #11936 for details.

11940

GetDocuments Stored Query

See #11936 for details.

11941

GetFolders Stored Query.

See #11936 for details.

11942

GetAssociations Stored Query

See #11936 for details.

11943

GetDocumentsAndAssociations Stored Query

See #11936 for details

11944

GetSubmissionSets Stored Query

See #11936 for details

11945

GetSubmissionSetAndContents Stored Query

See #11936 for details

11946

GetFolderAndContents Stored Query

See #11936 for details

11947

GetFoldersForDocument Stored Query

See #11936 for details

11948

GetRelated Stored Query

See #11936 for details

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

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 xdstest

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

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 xdstest

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

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 xdstest

1. The xdstest 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

1. 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

1. 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. The DocumentEntry being added to the Folder must have a Patient ID that is acceptable to the Registry (received through the Patient Identity Feed or manually loaded).

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.

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 xdstest 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 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.

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

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

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

12313

Cross Gateway Retrieve - multiple documents

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. This retrieve requests multiple documents.

References

ITI TF-2 3.39

Actors Tested

Responding Gateway

Dependencies

Test 12311 must be run before this test

Resources

tests/12313 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 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.

12314

FindDocuments XGQ for ObjectRef

Repeat 12309 over TLS.

12315

Retrieve Single Document over TLS

Repeat 12312 over TLS.

12318

Responding Gateway Test initialization

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

Responding 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.

Responding 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 Repository/Registry behind your Responding Gateway you can create the test data using the testdata/12318 section of the test kit. Configure your Repository in actors.xml and run 12318 against that site (within actors.xml your Repository is defined within a site). Your Repository should be forwarding the Register transaction to your Registry.

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 xdstest

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

Test testkit/testdata/12310 which issues a Cross Community FindDocuments query

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 Repository

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 xdstest

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.

12375

Accept XDR Provide and Register.b with Limited Metadata

Repeat test 12371 with the payload conforming to the Limited Metadata requirements and are properly labeled.

12376

Accept XDR Provide and Register.b with Limited Metadata but without Limited Metadata Label

Repeat test 12371 with the payload conforming to the Limited Metadata requirements and are not properly labeled.

12377

Validate XDM Zip format against Message Validator

The XDS Toolkit contains a tab labeled Message Validator. Use this tool to upload your XDM Zip file, select the correct message type and validate. There are no results to upload into Gazelle.

Alternatively, create a zip file of the XDM media content and then use the XDM validator here: https://ttpedge.sitenv.org/ttp/#/validators/xdm

12378

Validate XDR Provide and Register message against Message Validator

The XDS Toolkit contains a tab labeled Message Validator. Use this tool to upload an XDR PnR message (captured via TCPMON or equivalent), select the correct message type and validate. There are no results to upload into Gazelle.

12379

Extra Metadata

Section ITI-TF 4.2.3.1.4 defines the composition and handling of Extra Metadata, ebRIM Slots not defined in XD* metadata. The XDS Document Registry actor is required to implement Extra Metadata by either:

1. Accepting, not storing and returning the XdsExtraMetadataNotSaved warning code
2. Accepting, storing and returning the extra metadata in query responses.

This test tests the required handling by the XDS Registry actor.

References

4.2.3.1.4 Extra Metadata Attributes

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/12379

Testing Document Registry Actor

Follow Generic Testing Procedures Using xdstest

15800

MU - Simple DocumentEntry update

Tests ability of Document Registry to accept a metadata update which changes a few simple attributes of a DocumentEntry. This exercises the basic operation of the Update DocumentEntry Metadata operaton as defined in section 3.57.4.1.3.3.1 of the Metadata Update Supplement

References

ITI TF-2 3.57

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/15800

Pre-Connectathon Tests tab under GUI Toolkit

Note - the execution of this test has not been tested using the older command line tool xdstest. Use the GUI Toolkit only.

Testing Document Registry Actor

1. Follow the instructions displayed by the toolkit
2. Submit zipped log.xml files for evaluation.

15801

MU - Simple DocumentEntry update

Tests ability of Document Administrator to generate a metadata update which changes a few simple attributes of a DocumentEntry. This exercises the basic operation of the Update DocumentEntry Metadata operaton as defined in section 3.57.4.1.3.3.1 of the Metadata Update Supplement

References

ITI TF-2 3.57

Actors Tested

Document Administrator

Dependencies

None

Resources

GUI Toolkit - Public Registry copy or private downloaded copy

Testing Document Administrator Actor

Perform the following steps using the GUI Toolkit:

• Create a Document Registry simulator with Update_Metadata_Option set to true (help)

• This can be done with the GUI Toolkit installed on the Public Registry Server or with a downloaded copy of the GUI Toolkit installed in your facility

• Submit a single DocumentEntry to the Registry simulator

• This can be done using:
  • Your product (note the Repository simulator which might accept a Provide and Register does not yet exist, you must generate a Register transaction)
  • The GUI Toolkit - Home => Connectathon Tools => Registry Test Data
• The Simulator Control page of the GUI Toolkit provides the endpoint for the Registry simulator

• Issue a Stored Query to the Registry simulator to get the original DocumentEntry back

• This is optional within the profile but highly recommended
• The Simulator Control page of the GUI Toolkit provides the endpoint for the Registry simulator

• Review the section below on Simulator Endpoints. Configure your Document Administrator actor to use the validating endpoint
• Submit an update to the DocumentEntry, changing at least one attribute from the original. The uniqueId, objectType, and logicalId must not be changed from the original. The PatientId must not be changed (this is a requirement of the test, not of the Metadata Update supplement).

Obtaining Simulator Feedback

Each message sent to a simulator can be viewed in the Simulator Message View tab (help).

Simulator Endpoints

On the Simulator Control tab, an endpoint is listed for the Update transaction. This is a non-validating endpoint meaning that the endpoint will accept and perform a Metadata Update but no special validators are executed to assist with testing. For this test you need to use a special validating version of the endpoint that adds validation steps which give feedback on this specific operation, DocumentEntry Update.

The non-validating endpoint for update looks like:

http://host:port/xdstools2/simulator/simid/registry/update

where host and port are dependent on which copy of the toolkit you are using. Simid is provided by the Simulator Control tab of the toolkit. For this operation, use the following form of the endpoint:

http://host:port/xdstools2/simulator/simid/registry/update/UpdateDocumentEntry

The suffix, /UpdateDocumentEntry, triggers a validation step - validating that the update transaction contained an Update DocumentEntry operation as described in section 3.57.4.1.3.3.1 of the Metadata Update supplement.

15802

MU - Update DocumentEntry AvailabilityStatus

Tests ability of Document Registry to accept a metadata update which changes the availabilityStatus attribute of a DocumentEntry. This exercises the basic operation of the Update DocumentEntry AvailabilityStatus operaton as defined in section 3.57.4.1.3.3.2 of the Metadata Update Supplement

References

ITI TF-2 3.57

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/15802

Pre-Connectathon Tests tab under GUI Toolkit

Note - the execution of this test has not been tested using the older command line tool xdstest. Use the GUI Toolkit only.

Testing Document Registry Actor

1. Follow the instructions displayed by the toolkit
2. Submit zipped log.xml files for evaluation.

15803

MU - Update DocumentEntry AvailabilityStatus

Tests ability of Document Administrator to generate a metadata update which changes the availabilityStatus attribute of a DocumentEntry. This exercises the basic operation of the Update DocumentEntry Metadata operaton as defined in section 3.57.4.1.3.3.2 of the Metadata Update Supplement

References

ITI TF-2 3.57

Actors Tested

Document Administrator

Dependencies

None

Resources

GUI Toolkit - Public Registry copy or private downloaded copy

Testing Document Administrator Actor

Perform the following steps using the GUI Toolkit:

• Create a Document Registry simulator with Update_Metadata_Option set to true (help)

• This can be done with the GUI Toolkit installed on the Public Registry Server or with a downloaded copy of the GUI Toolkit installed in your facility
• The Simulator Control page of the GUI Toolkit provides the endpoints for the Registry simulator (Register, Update, and Stored Query transaction endpoints)

• Submit a DocumentEntry to the Registry simulator. This will be the target of attempts to change its availabilityStatus

• This can be done using:
  • A Register transaction from your product
  • The GUI Toolkit - Home => Connectathon Tools => Registry Test Data which will generate a Register transaction containing a DocumentEntry

• Issue a Stored Query to the Registry simulator to get the original DocumentEntry back

• This is optional within the profile but highly recommended

• Submit an Update DocumentEntry Status operation on the DocumentEntry.

• Review the section test 15801 - Simulator Endpoints. Configure your Document Administrator actor to use the validating endpoint /UpdateDocumentEntryStatus
• Change the status from Approved to Deprecated

• Open the Simulator Message View tab in the GUI Toolkit

• Find your Update message (should be the first on the list unless you have been doing other work)
• Download the message using the Download Message link in the bottom left corner of the window. This will download a ZIP file containing the details of the message.
• Submit this ZIP as evidence of your testing
• Note that the last few lines of the Log window should look like:

SoapWrapperRegistryResponseSim
   ValidationContext: Request;MU;Updateable;MetadataPatterns:[UpdateDocumentEntryStatus]
        Wrapping response in SOAP Message

• The MetadataPatterns tag showing UpdateDocumentEntryStatus

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