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
- Follow Generic Testing Procedures Using xdstest
- Edit the file tests/11710/testplan.xml
- Edit the following fields:
- <Your Company Name> (include product name if testing more than one).
- <Your Name>
- <Your Email>
- Send this metadata as a Submission Request by executing the following from a command prompt:
- When reporting the results of this test in kudu, just create a simple text file indicating this step is successfully complete.
- 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
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
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
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
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
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
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
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
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
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
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
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
- 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.
- 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.
- Follow Generic Testing Procedure s Using xdstest
- Have your Repository forwards metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11966
Evaluation by the Public Registry
- Schema
- Metadata Validator
- Correct content (Submission Set containing a single Document)
- Correct hash and size computed by Repository actor and placed in metadata.
Evaluation by xdstest
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11969
- Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11970
- Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Create a Folder per test 11970.
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11971
- Identify the UUID of the Folder of interest with a query of your choosing
- 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.
- Have your Document Source send the submission
- Verify that you get a successful RegistryResponse message in return.
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11973
- Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11974
- Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/test11975
- Submit a Submission Set containing a single Folder using the Provide and Register Document Set-a transaction
- 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
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forwards metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/registryB2doc
Evaluation by the Public Registry
- Schema
- Metadata Validator
- Correct content (Submission Set containing two Documents)
- Correct hash and size computed by Repository actor and placed in metadata.
Evaluation by xdstest
- 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
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forwards metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/registryAonedoc
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
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forward metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/registryBonedoc
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
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forward metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb
Evaluation by xdstest
- 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
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forward metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb
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.
11991
Accept Register two documents via XDS.b
Verify that the XDS.b Document Registry can accept a two documents via the Register Document Set-b transaction.
References
- ITI TF-2 3.41
Actors Tested
- Document Registry
Dependencies
- None
Resources
- testkit/tests/11991
Testing Document Registry Actor
- Submit a Submission Set containing two Documents using the Register Document Set-b transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.
11992
Accept Document Replace via XDS.b
Verify that the XDS.b Document Registry can accept a Document Replace via the Register Document Set-b transaction. No transformations or addendum are present.
References
- ITI TF-2 3.41
Actors Tested
- Document Registry
Dependencies
- None
Resources
- testkit/tests/11991
Testing Document Registry Actor
- Submit a Document Replace using the Register Document Set-b transaction to your Registry. Then validate the state of your Registry using the GetSubmissionSetAndContents Stored Query.
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:
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:
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.
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
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.
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:
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:
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:
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:
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
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.
- 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.
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forwards metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb
Evaluation
- Schema
- RepositoryUniqueId matches (compares value from RetrieveDocumentSetRequest against value from RetrieveDocumentSetResponse)
- DocumentUniqueId retrieved matches value submitted
- mimeType matches
- 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.
- 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.
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forwards metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb
Evaluation
- Schema
- RepositoryUniqueId matches (compares value from RetrieveDocumentSetRequest against value from RetrieveDocumentSetResponse)
- DocumentUniqueId retrieved matches value submitted
- mimeType matches
- Content of document matches
- 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.
- Follow Generic Testing Procedures Using xdstest
- Have your Repository forwards metadata to the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/xdsregistryb
Evaluation
- Schema
- RepositoryUniqueId matches (compares value from RetrieveDocumentSetRequest against value from RetrieveDocumentSetResponse)
- DocumentUniqueId retrieved matches value submitted
- mimeType matches
- 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
- Follow test instructions found in testkit/tests/12045/readme.txt
Evaluation
- Query runs without error
- Retrieve runs without error
- Correct Mime type returned as Content-Type
- Mime type matches the submission (according to <ExpectedMimeType/>)
- Document size is correct (according to <ReferenceDocument/>)
- 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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/repositoryB2doc
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
- Follow Generic Testing Procedures Using Public Registry Server
- Configure the WS Endpoint based on this pattern
http://ihexds.nist.gov:PORT/EVENT/services/repositoryBonedoc
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.
- Follow Generic Testing Procedures Using Public Registry Server
- 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
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
Testing Integrated Source/Repository Actor
http://ihexds.nist.gov:PORT/EVENT/services/registryAonedoc
Evaluation by the Public Registry
- Schema
- Metadata Validator
- 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
Testing Integrated Source/Repository Actor
http://ihexds.nist.gov:PORT/EVENT/services/registryBonedoc
Evaluation by the Public Registry
- Schema
- Metadata Validator
- 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
Testing Integrated Source/Repository Actor
http://ihexds.nist.gov:PORT/EVENT/services/registryA2doc
Evaluation by the Public Registry
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
Testing Integrated Source/Repository Actor
http://ihexds.nist.gov:PORT/EVENT/services/registryB2doc
Evaluation by the Public Registry
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
Evaluation by xdstest
- 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
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
- 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.
- Issue a FindDocuments XGQ with
- returnType = LeafClass
- no home attribute (documented in profile as homeCommunityId)
- Patient ID to use is documented here.
- You must receive back 2 ExtrinsicObject elements (XDSDocumentEntry objects)
- 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
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
- 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
- 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.
- Issue a Cross Community Retrieve transaction with the above 3 attributes
- Verify that 1 document is returned
- 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
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
- 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.
- Issue a FindDocuments XGQ with
- returnType = ObjectRef
- no home attribute (documented in profile as homeCommunityId)
- Patient ID to use is documented here.
- You must receive back 2 ObjectRef elements
- 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
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
- 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.
- Issue a GetDocuments XGQ with
- returnType = LeafClass
- home attribute must be the value returned from the FindDocuments SQ (documented in profile as homeCommunityId)
- You must receive back 2 ExtrinsicObject elements
- 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
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
- 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
- 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.
- Issue a Cross Community Retrieve transaction with the above 3 attributes
- Verify that 2 documents are returned
- 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.
- Configure and run the test plan from the test kit to perform the Cross Gateway Query
- Evaluate the results.
- 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.
- Configure and run the test plan from the test kit to perform the Cross Gateway Query
- Evaluate the results.
- 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
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.
- Configure and run the test plan from the test kit to perform the Cross Gateway Query
- Evaluate the results.
- 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.
- Configure and run the test plan from the test kit to perform the Cross Gateway Query
- Evaluate the results.
- 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.
- Configure and run the test plan from the test kit to perform the Cross Gateway Query
- Evaluate the results.
- 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
Resources
- testkit/tests/12320
Test Procedure
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
Resources
- testkit/tests/12321
Test Procedure
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
Resources
- testkit/tests/12322
Test Procedure
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
Resources
- testkit/tests/12323
Test Procedure
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
Resources
- testkit/tests/12324
Test Procedure
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
Resources
- testkit/tests/12324
Test Procedure
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
Resources
- testkit/tests/12326
Test Procedure
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
Resources
- testkit/tests/12327
Test Procedure
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
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
- Follow Generic Testing Procedures Using xdstest
- 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
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
- Schema
- Metadata Validator
- Correct content (Submission Set containing a single Document)
- Correct hash and size computed by Repository actor and placed in metadata.
- Web Service interaction is asynchronous (non-anonymous ReplyTo SOAP Header present)
Evaluation by xdstest
- Evaluation query returns correct metadata
- 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
- 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.
- 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
- 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.
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.
- Configure and run the test plan from the test kit to perform the Cross Gateway Query
- Evaluate the results.
- 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
- 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.
- 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
- Schema
- Metadata Validator
- Correct content (Submission Set containing a single Document)
- Correct hash and size computed by Repository actor and placed in metadata.
- 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
- Schema
- Metadata Validator
- 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
- Schema
- Metadata Validator
- 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
- Schema
- Metadata Validator
- 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.
- You must test all Stored Queries and combinations of Stored Queries that your implementation utilizes against this endpoint.
- 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
- Issue a Stored Query to access metadata for a document of interest following instructions in test #12342.
- 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.
- 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
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
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
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
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
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
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
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
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
- 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']
- 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
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
- 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.
- 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)
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
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
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
Evaluation by xdstest
- 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
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:
- Accepting, not storing and returning the XdsExtraMetadataNotSaved warning code
- 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
- Follow the instructions displayed by the toolkit
- 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
- This can be done using:
- 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
- Follow the instructions displayed by the toolkit
- 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
- This can be done using:
- 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
- Edit the test.properties file in the appropriate directory in tests/ (directory is test number).
- Change the URL parameter to point to your registry.
- 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.
- Run the tests using xdstest.
- Verify that you get a successful RegistryResponse messages in return containing ExtrinsicObject(s)
- 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
- 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.
- Configure the Document Consumer under test to send to the URL
- http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
- Have your Document Consumer issue the Query. Examples are found in tests/ by the test number
- 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
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:
- 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.
- Delete all lines containing comments which contain parameter names you do not wish to be in your query (filter out unwanted parameters)
- Delete the remaining comments (not the line, just the comment part)
- You should be left with SQL imbedded in XML. This SQL will still contain parameter names embedded in the SQL statements
- 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