Submit a [[Metadata_Patterns#Document_Addendum|Document Addendum]] using the [[XDS_Transactions#Register_Document_Set|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.

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.

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.

Within the eval step, the validate_deprecate test step must show that the original document is deprecated and the validate_new must show that the replacement document is approved (status = Approved).

11876

Reject Submission of Invalid Patient ID via XDS.a

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

11877

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Resources

testkit/tests/11877

Testing Document Registry Actor

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

11878

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

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

11883

Submission Stored - All or Nothing (XDS.a)

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

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

11886

Pass Arbitrary Metadata

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

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

11887

Return Errors from Registry (XDS.a)

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

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.

11955

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.

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.

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.

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.

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)

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)

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.

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.

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.

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.

11997

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.

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

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.

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.

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.

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.

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.

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.

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)

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.

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.

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.

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.

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.

12314

12315

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:

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.

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.

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.

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)

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.

12334

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.

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.

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.

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)

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

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

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.

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.

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.

12359

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.

12360

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.

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

12366

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.

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)

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.

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.

12375

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.

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.

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

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

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:

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

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

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.

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