From IHEWiki

Contents 1 How to Report Results 1.1 Log Results of Provide and Register or Register transaction tested against the Public Registry Repository 1.2 Log Results of Query or Stored Query transactions tested against the Public Registry 1.3 Log Results of Register transaction against your Registry 1.4 Log Results of Query or Stored Query transaction against your Registry 1.5 Result Reporting - Server Testing using xdstest 1.6 Result Reporting - Server Testing using xdstest and the public registry 1.7 The Test Management Tool - how to report results to the Test Managers 2 Patient IDs and uniqueIds in test material 3 Using the Public Registry 3.1 Allocating new Patient IDs for Testing 3.2 Allocating uniqueIDs for testing 4 Individual Tests 4.1 11710 4.2 11720 4.3 11721 4.4 11728 4.5 11729 4.6 11730 4.7 11731 4.8 11732 4.9 11733 4.10 11734 4.11 11735 4.12 11736 4.13 11737 4.14 11738 4.15 11739 4.16 11740 4.17 11741 4.18 11742 4.19 11743 4.20 11744 4.21 11746 4.22 11747 4.23 11748 4.24 11749 4.25 11750 4.26 11751 4.27 11763 4.28 11764 4.29 11765 4.30 11766 4.31 11801 4.32 11802 4.33 11803 4.34 11804 4.35 11805 4.36 11806 4.37 11807 4.38 11808 4.39 11809 4.40 11810 4.41 11811 4.42 11812 4.43 11813 4.44 11814 4.45 11827 4.46 11870 4.47 11871 4.48 11876 4.49 11877 4.50 11878 4.51 11879 4.52 11880 4.53 11881 4.54 11882 4.55 11883 4.56 11884 4.57 11885 4.58 11886 4.59 11887 4.60 Query - Configuring the SQL queries supplied in the testkit 4.61 Query - Testing the Document Registry 4.62 Query - Testing the Document Consumer 4.63 Stored Query - Testing the Document Registry 4.64 Stored Query - Testing the Document Consumer 4.65 11890 4.66 11951 4.67 11952 4.68 11953 4.69 11954 4.70 11955 4.71 11956 4.72 11957 4.73 11958 4.74 11959 4.75 11960 4.76 11961 4.77 11962 4.78 11963 4.79 11964 4.80 11965 4.81 11949 4.82 11950 4.83 Test Data Description

How to Report Results

Log Results of Provide and Register or Register transaction tested against the Public Registry Repository

When testing the Provide & Register transaction or the Register transaction against the Public Registry/Repository:

• Log the patientId used in the submission (if it is unique - only used in one submission)

OTHERWISE

• Log the XDSSubmissionSet.uniqueId attribute of the submission

Instructions on how to log test results can be found at #The_Test_Management_Tool_-_how_to_report_results_to_the_Test_Managers

Log Results of Query or Stored Query transactions tested against the Public Registry

When testing the Query Registry transaction or Stored Query transaction against the Public Registry:

Log the following informtion about the test execution:

• patientId you queried against
• approximate time (including time zone)

Instructions on how to log test results can be found at #The_Test_Management_Tool_-_how_to_report_results_to_the_Test_Managers

Log Results of Register transaction against your Registry

The following details shall be logged to the test management tool:

• file log.msg generated by xdstest, it will contain:
  • Patient ID used in testing. It must be unique for the test. You must edit this field (patientid=) into the test.properties file
  • Request sent to the server.
  • RegistryResponse XML response from the server.

If xdstest generates the files request.msg and result.msg instead of log.msg, you need to download the newer version of xdstest from here

Also, you must run the GetAll Query (or Stored Query) to show what was deposited in your Registry. If you use:

• Query
  • GetAll is actually a collection of queryies each producing a log.msg file. Zip this collection of files (after renaming to make unique file names) and submit the zip file.
• Stored Query
  • The result will be a single log.msg file. Log this file.
• In either case, when using the GetAll query, the returnType must be "LeafClass" and status must be ('Approved', 'Deprecated')

Instructions on how to log test results can be found at #The_Test_Management_Tool_-_how_to_report_results_to_the_Test_Managers

Log Results of Query or Stored Query transaction against your Registry

This test will be run using the command line tool xdstest. xdstest is run from a test directory. It produces a file log.msg which records the transaction. To document the completion of the test:

• The file log.msg must be logged as evidence of successful test completion

Instructions on how to log test results can be found at #The_Test_Management_Tool_-_how_to_report_results_to_the_Test_Managers

Result Reporting - Server Testing using xdstest

This is to be used when using xdstest to test your Registry actor implementation.

The following details shall be logged to the test management tool:

• file log.msg generated by xdstest, it will contain:
  • Patient ID used in testing. It must be unique for the test. You must edit this field (patientid=) into test.properties
  • Request sent to the server.
  • RegistryResponse XML response from the server.

If xdstest generates the files request.msg and result.msg instead of log.msg, you need to download the newer version of xdstest from here

• If the test being reported is a submission then include:
  • Response from a GetAll query ( 11806)(returnType="LeafClass") issued against the patientId used.
  • In this query, you must use $status = ('Approved', 'Deprecated')

You can use xdstest and test 11806 (modifying the patient ID used in the test) to retrieve this data.

In situations where you must upload more that one file to the test management tool, each file must have a unique name or it will not upload. If you are uploading 2 log.msg files, just give them multiple names like log1.msg, log2.msg.

Result Reporting - Server Testing using xdstest and the public registry

This is to be used when using xdstest to test your Repository actor implementation.

The following details shall be logged to the test management tool:

• file log.msg generated by xdstest, it will contain:
  • Patient ID used in testing. It must be unique for the test. You must edit this field (patientid=) into test.properties
  • Request sent to the server.
  • RegistryResponse XML response from the server.

If xdstest generates the files request.msg and result.msg instead of log.msg, you need to download the newer version of xdstest from here

The Test Management Tool - how to report results to the Test Managers

The Test Management Tool, called Kudu, is a web site that you will use to record the results of your testing. Each required test for each company is presented as a separate web page inside the tool. In this area a vendor can upload log files to document the results of a test. In the XDS test procedures, when asked to 'log the following information' we are refering to uploading files into Kudu.

Patient IDs and uniqueIds in test material

All test and example metadata provided in the testkit has the patientId and uniqueIds coded as variables. These variables look like

• $PatientId
• $uniqueId01, $uniqueId02 ...

To use, real patientIDs and uniqueIds must be allocated and be inserted in metadata replacing the variables.

Using the Public Registry

The Public Registry is used to support XDS testing. There are several rules to follow when testing against this combined Document Registry and Document Repository actor implementation.

1. All patient IDs must be registered. Many tests require the use of a unique Patient ID for the test. XDSSubmissionSet, XDSDocuentEntry, and XDSFolder all have attributes for patientID.
2. All XDSSubmissionSet, XDSDocumentEntry, and XDSFolder objects must contain uniqueId attributes that are unique in this registry.

The following sections document how to follow these rules.

Allocating new Patient IDs for Testing

The Registry actor, per the XDS Profile specification, validates patient IDs against against those received in the Patient Identify Feed. To get credit for successfully runnning a test, you must use a unique patient ID for that test run. No other submissions may be made against that patient ID. This assists with test validation. The patient ID is submitted as part of your test results.

To generate a unique patient ID for a test instance, go to the Patient ID Allocator service.

Allocating uniqueIDs for testing

The public registry implementation, according to the XDS Profile, validates the uniqueness of the uniqueId attributes of Documents, Folders, and Submission Sets. Contact your regional Test Manager to be assigned an OID base to be used for constructing uniqueIds.

Individual Tests

11710

NIST Connection + IP Registration

Test a vendor’s ability to connect to the NIST Test Site and to register the IP address of the vendor’s test machine.

This test is to be run from each machine that a vendor will use for testing against the NIST Test Site. Failing to run this test first will cause the vendor to not get credit for later testing since this is not only a connectivity test but also a way to register a vendor name against an IP address. This registration is used later to validate vendor test results.

References

None

Actors Tested

None

Test Procedure

1. Edit the file test/11710/metadata.xml
2. Edit the following fields:</li>
   • <Your Company Name> (include product name is testing more than one).
   • <Your Name>
   • <Your Email>
3. Send this metadata as a Submission Request by executing the following from a command prompt:
   • Change directory to test/11710
   • run xdstest
4. Success/Failure message will confirm the results.
5. This test does not need to be reported to the Test Manager.
6. If you test from more than one machine and therefore run this multiple times, please spell the company name the same each time.

11720

Metadata Validation Tool

XDS Schema and XDS Metadata Validator engine available as a web portal to support testing of registry metadata. This is not a reportable test but instead a reference to a development/debug tool.

References

Tables 3.14.4.1-5 through 3.14.4.1-7 of ITI TF-2

Actors Tested

None

Test Procedure

1. Assemble Repository Submission Metadata or Registry Submission Metadata in a file.
2. Bring up Validator in your web browser.
3. Select type of submission (Registry or Repository)
4. Select submission file
5. Submit button

The web portal validates your metadata with the XDS/ebXML Registry v2.1 Schema and XDS Metadata Validator and return results. This Schema/Validator pair is also installed on the NIST Public Registry. This validation is run on every submission.

11721

Basic Transport

This test can be used to test any SOAP transport. It supports tests labeled 11721 and 11814.

Test basic transport mechanisms, HTTP and SOAP, for transferring metadata without mutual TLS authentication. Document Repository makes an HTTP connection to Document Registry. A simple SOAP package is transferred containing simple non-metadata XML. The Registry may return an error message because the payload is not metadata. This is acceptable.

References

ITI TF-2 3.14

Actors Tested

Document Registry OR Document Repository

Testing Document Registry Actor

1. Edit test/11721/test.properties
2. Change the URL parameter to point to your registry or repository
3. Run the test using xdstest
4. Do not log the results. This test is for debugging SOAP implementations only.

11728

Create Folder

Create an XDSFolder in the Registry.

This submission consists of:

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

References

ITI TF-2 3.14

Actors Tested

Document Source

Dependencies

None

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository?testeval=11728
3. Formulate a submission as described above using the metadata in examples/11728 as an example
4. Have your Document Source send the submission
5. Verify that you get a successful RegistryResponse message in return.
6. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11729

Create Folder with Initial Document

Create an XDSFolder with an Initial Document in the Repository and Registry. The Submission Set includes a document that is the initial contents of the Folder.

This submission consists of:

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

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

None

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository?testeval=11729
3. Formulate a submission as described above. Example is available in examples/11729.
4. Have your Document Source send the submission
5. Verify that you get a successful RegistryResponse message in return.
6. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11730

Add Document to Folder

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

This submission consists of:

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

References

ITI TF-2 3.15

Actors Tested

Document Source

Dependencies

Creation of a Folder to add the document to. Test 11728 can be used for this purpose.

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Create a Folder per test 11728.
3. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository?testeval=11730
4. Identify the UUID of the Folder of interest with a query of your choosing
5. Formulate a submission as described above or use the example metadata found in examples/11730
   • If you use this example, the Folder is referenced symbolically as "$Folder01". 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.
6. Have your Document Source send the submission
7. Verify that you get a successful RegistryResponse message in return.
8. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11731

Register One Document

Verify that the Document Repository can generate a valid SOAP over HTTP message containing valid metadata representing a single document. The metadata will be validated against both the ebXML Registry Schema, XDS metadata rules and the ebXML Registry metadata requirements. The metadata must contain a Submission Set and a single XDSDocumentEntry.

References

ITI TF-2 3.14

Actors Tested

Document Repository

Testing Document Repository Actor and Integrated Document Source/ Document Repository actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Configure the Repository under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/registry?testeval=11731
3. For Repository actors and Integrated Document Source/ Document Repository actors that offer the External Document Source option, use test/11731:
   • Edit the patient ID and unique ID attributes
   • Configure test.properties to send to your repository
   • Run the test using xdstest
   • Log the results: #Log_Results_of_tests_against_a_Document_Repository_using_xdstest
4. For Integrated Document Source/ Document Repository actors that do not offer the External Document Source option:
   • Generate a Register transaction equivalent to the above
   • Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository
5. Verify that you get a successful RegistryResponse message in return.

11732

Register Two Documents

Verify that the Document Repository can generate a valid SOAP over HTTP message containing valid metadata representing a Submission Set and two documents. The metadata will be validated against both the ebXML Registry Schema, XDS metadata rules and the ebXML Registry metadata requirements. The metadata must contain a Submission Set and two XDSDocumentEntry objects.

References

ITI TF-2 3.14

Actors Tested

Document Repository

Testing Document Repository Actor and Integrated Document Source/ Document Repository actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Configure the Repository under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/registry?testeval=11732
3. For Repository actors and Integrated Document Source/ Document Repository actors that offer the External Document Source option, use test/11732:
   • Edit the patient ID and unique ID attributes
   • Configure test.properties to send to your repository
   • Run the test using xdstest
   • Log the results: #Log_Results_of_tests_against_a_Document_Repository_using_xdstest
4. For Integrated Document Source/ Document Repository actors that do not offer the External Document Source option:
   • Generate a Register transaction equivalent to the above
   • Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository
5. Verify that you get a successful RegistryResponse message in return.

11733

Accept Register One Document

Verify that the Document Registry can accept a valid SOAP over HTTP message containing valid metadata and a single document. The metadata will contain a Submission Set and a single XDSDocumentEntry.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Testing Document Registry Actor

1. Edit test/11733/metadata.xml
   • Edit the patient ID attributes and uniqueId attributes for your registry
2. Edit test/11733/test.properties
   • Change the URL parameter to point to your registry.
3. Run the test using xdstest.
4. Log the results: #Log_Results_of_Register_transaction_against_your_Registry

11734

Retrieve Document

Verify that Document Repository can respond to a request to retrieve a document via HTTP Get.

References

ITI TF-2 3.17

Actors Tested

Document Repository

Testing Document Repository Actor

1. Load a PDF file into your repository using any method. There is a sample PDF include in the test data for this test.
2. Retrieve document from your favorite browser. This need not be via the Document Consumer actor, it is perfectly acceptable to type the URL into your browser.
3. See that PDF is faithfully reproduced
4. Log the results: There are no details to log for this test, just note its completion

Note: A PDF file is used for this test since PDF viewers are rather picky about data stream truncation and correct MIME Type.

11735

Accept Register Two Documents

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Testing Document Registry Actor

1. Edit test/11735
   • Edit the patient ID attributes and uniqueId attributes for your registry
2. Edit test/11735/test.properties
   • Change the URL parameter to point to your registry.
3. Run the test using xdstest.
4. Log the results: #Log_Results_of_Register_transaction_against_your_Registry

11736

Submit Replace/Transformation for Existing Document

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

11737

Submit Add By-Reference to Submission Set

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

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

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

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

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

References

ITI TF-2 3.14

Actors Tested

Document Source

Dependencies

None

Testing Document Source Actor

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

11738

Submit via Offline Mode

Generate a Provide and Register transaction via Offline Mode.

References

ITI TF-2 3.14

Actors Tested

Document Source

Document Repository

Dependencies

None

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

11739

Retrieve with mutual TLS

Repeat any Retrieve test with mutual TLS enabled.

References

ITI TF-2 3.17

Actors Tested

Document Consumer

Document Repository

Dependencies

None

Testing Document Consumer Actor

1. Rerun any Retrieve test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Repository Actor

1. Rerun any Retrieve test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11740

Register with mutual TLS

Repeat any Register test with mutual TLS enabled.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Document Repository

Dependencies

None

Testing Document Repository Actor

1. Rerun any Register test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Rerun any Register test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11741

Query with mutual TLS

Repeat any Query test with mutual TLS enabled.

References

ITI TF-2 3.15

Actors Tested

Document Registry

Document Consumer

Dependencies

None

Testing Document Consumer Actor

1. Rerun any Query test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Rerun any Register test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11742

Generate Basic Transport - Document Source

Test basic transport mechanisms, HTTP and SOAP, for transferring metadata without mutual TLS authentication between a Document Source actor and the public repository. Document Source makes an HTTP connection to public repository. A simple SOAP package is transferred containing simple non-metadata XML.

References

ITI TF-2 3.14

Actors Tested

Document Source

Testing Document Source Actor

1. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/test?testid=11742
2. Have your Document Source send a SOAP over HTTP message with arbitrary content
3. Verify that you get a valid SOAP message back, it may contain an error message from the repository. If you are using a SOAP parser to accept the response, the response will not parse correctly. That is ok.
4. Results of this test should not be submitted. It is for testing/debug of SOAP implemenations only.

11743

Provide and Register with mutual TLS

Repeat any Provide and Register test with mutual TLS enabled.

References

ITI TF-2 3.15

Actors Tested

Document Repository

Document Source

Dependencies

None

Testing Document Source Actor

1. Rerun any Provide and Register test with mutual TLS enabled
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Repository Actor

1. Rerun any Provide and Register test with mutual TLS enabled
2. Log the results: Submit log information from your Repository that shows that the Provide and Register was over mutual TLS

11744

Accept Basic Transport - Document Repository

Test basic transport mechanisms, HTTP and SOAP, for transferring metadata without mutual TLS authentication between the test tool xdstest and a Document Repository Actor. xdstest makes an HTTP connection to Document Repository. A simple SOAP package is transferred containing simple non-metadata XML.

References

ITI TF-2 3.14

Actors Tested

Document Repository

Testing Document Repository Actor

1. Edit test/11744/test.properties
   • Change the URL parameter to point to your repository
2. Run the test using xdstest
3. Do not log the results, this is for testing/debug only.

11746

Submit One Document

Verify that the Document Source can generate a valid SOAP over HTTP message containing valid metadata and a single document. The metadata will be validated against both the ebXML Registry Schema, XDS metadata rules and the ebXML Registry metadata requirements. The metadata must contain

• an XDSSubmissionSet object
• an XDSDocumentEntry object
• a HasMember Association linking them.

The submission must contain a document that matches the metadata (MIME Type).

References

ITI TF-2 3.14

Actors Tested

Document Source

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Configure the Document Source under test to use this patient ID and to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository?testeval=11746
3. Have your Document Source send a SOAP over HTTP message containing metadata which includes a Submission Set and a single document. The document must be attached.
   • An example is found in the test kit in examples/11746
4. Verify that you get a successful RegistryResponse message in return.
5. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11747

Submit Two Documents

Verify that the Document Source can generate a valid SOAP over HTTP message containing valid metadata and a two documents. The metadata will be validated against both the ebXML Registry Schema, XDS metadata rules and the ebXML Registry metadata requirements. The metadata must contain

• an XDSSubmissionSet object
• two XDSDocumentEntry objects
• two HasMember Association objects linking the Submission Set with the two Documents.

The submission must contain two documents that match the metadata.

References

ITI TF-2 3.14

Actors Tested

Document Source

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository
3. Have your Document Source send a SOAP over HTTP message containing metadata which includes a Submission Set and two documents. The documents must be attached.
   • An example is found in the test kit in examples/11747
4. Verify that you get a successful RegistryResponse message in return.
5. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11748

Replace Existing Document

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

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

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

References

ITI TF-2 3.14

Actors Tested

Document Source

Dependencies

None

Testing Document Source Actor

1. Allocate a new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Create a Document to be replaced. Test 11746 can be used.
3. Using a query of your choice, discover the UUID of the Document to be replaced
4. Compose metadata to perform the replacement.
   • Set the patientId on the Submission Set and document
   • Set uniqueIds in all objects as needed
   • Set the targetObject attribute on the RPLC Association object to the UUID of the document submitted by 11746
   • Add an ObjectRef for the UUID of the document to indicate that an object already in the registry is being referenced
   • An example is found in the test kit in examples/11748
5. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/repository?testeval=11748
6. Have your Document Source send the metadata and replacement document
7. Verify that you get a successful RegistryResponse message in return
8. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11749

Life-cycle Management

Verify that Document Source can issue the three variations on life-cycle management: transformation, addendum, replace with transformation. For each variation, 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 an APND, XFRM, or XFRM_RPLC Association to link the new document to the old. The registry adaptor takes responsibility for deprecating the old document for the XFRM_RPLC (replace with transform) type. More specifically, the following must be composed in a submission:

• Submission Set
• New Document Metadata
• A HasMember Association linking Submission Set to the XDSDocumentEntry
• APND, XFRM, or XFRM_RPLC Association linking the new document to the existing document (in registry, discovered by query) being replaced
• An ObjectRef pointing to the document being replaced

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

References

ITI TF-2 3.14

Actors Tested

Document Source

Dependencies

Must be able to run 11807 - GetDocument query (or equivalent).

Testing Document Source Actor

1. Allocate new patient IDs as needed (see #Allocating_new_Patient_IDs_for_Testing)
2. Rerun test 11746 with a new patientId for this test. This creates a document to be manipulated via life-cycle management.
3. Use the GetDocument query ( test 11807), retrieve the UUID of the document just submitted by 11746
4. Compose metadata to perform the replacement. An example can be found in 11752/metadata.xml
   • Set the patientId on the Submission Set and document
   • Add an APND Association linking the new document to the one discovered via query.
     • Set the targetObject attribute on the APND Association object to the UUID of the document submitted by 11746
     • Add an ObjectRef for the UUID of the document to indicate that an object already in the registry is being referenced
5. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/repository
6. Have your Document Source send the metadata and the APND document
7. Verify that you get a successful RegistryResponse message in return
8. Log the results: #Result_Reporting_-_Client_Testing_against_server

11750

Submit Transformation for Existing Document

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

11751

Accept Two Documents

Verify that the Document Repository can accept a valid SOAP over HTTP message containing valid metadata and two documents. The Document Repository shall generate a Register Transaction to the public registry. The metadata shall contain a Submission Set and two XDSDocumentEntry objects. The submission must contain two documents that match the metadata.

References

ITI TF-2 3.14

Actors Tested

Document Repository

Testing Document Repository Actor

1. Allocate new patient ID and uniqueIDs (see #Using_the_Public_Registry)
2. Edit these values into the test submission (see #Patient_IDs_and_uniqueIds_in_test_material)
3. Test material found in test/11751 will be used for this test
4. Edit test/11751/test.properties
   • Change the URL parameter to point to your repository.
   • Set the patient ID
5. Configure your repository so that the resulting Register Transaction goes to the public registry at
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/yr3a/registry
6. Run the test using xdstest.
7. Log the results: #Log_Results_of_Provide_and_Register_or_Register_transaction_tested_against_the_Public_Registry_Repository

11763

Submit Example HL7 Lab

Submit an example of your HL7 Lab message for review.

References

None

Actors Tested

Document Source

Dependencies

None

Testing Document Consumer Source

1. Submit, as a log entry, an example of your HL7 Lab

11764

Submit Example PDF

Submit an example of your PDF Document for review.

References

None

Actors Tested

Document Source

Dependencies

None

Testing Document Consumer Source

1. Submit, as a log, an example of your PDF document for review.

11765

Submit Example Wrapped PDF

Submit an example of your PDF Document wrapped in a CDA R2 wrapper for review.

References

None

Actors Tested

Document Source

Dependencies

None

Testing Document Consumer Source

1. Submit example document as a log to this test

11766

Submit Example XDS-MS/CDA R2

Submit an example of your XDS-MS/CDA R2 for review.

References

None

Actors Tested

Document Source

Dependencies

None

Testing Document Consumer Source

1. Submit your example as a log for this test.

11801

Query for ObjectRefs

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

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

References

ITI TF-2 3.14

Actors Tested

Document Consumer

Document Registry

Dependencies

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

Testing Document Consumer Actor

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

Testing Document Registry Actor

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

11802

Query for LeafClass

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

References

ITI TF-2 3.14

Actors Tested

Document Consumer

Document Registry

Dependencies

Test 11870 must be run before this test

Testing Document Consumer Actor

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

Testing Document Registry Actor

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

11803

FindDocuments Query

Verify that Document Consumer can use the FindDocuments query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in
   • 11803/find_documents.xml.

1. Verify that you get successful RegistryResponse messages in return containing ExtrinsicObject(s).
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11803.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return containing ExtrinsicObject(s)
4. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11804

FindSubmissionSets Query

Verify that Document Consumer can use the FindSubmissionSets query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in
   • 11804/find_submission_sets.xml.

1. Verify that you get successful RegistryResponse messages in return containing RegistryPackages(s).
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11804.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return containing RegistryPackages(s)
4. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11805

FindFolders Query

Verify that Document Consumer can use the FindFolders query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in
   • 11805/find_folders.xml.

1. Verify that you get successful RegistryResponse messages in return containing RegistryPackages(s).
2. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11805.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return containing RegistryPackages(s)
4. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11806

GetAll Query

Verify that Document Consumer can use the GetAll query and that a Document Registry can service such a query.

To run efficiently, this query must be broken down into 3 queries:

1. Query for ExtrinsicObjects (XDSDocumentEntry)
2. Query for RegistryPackages (XDSSubmissionSet and XDSFolder)
3. Query for Associations linking the objects

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the queries in
   • 11806a/get_all_1.xml.
   • 11806b/get_all_2.xml.
   • 11806c/get_all_3.xml.
3. Verify that you get successful RegistryResponse messages in return containing, in total, 1 ExtrinsicObject, 1 Submission Set, and 1 Association.
4. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11806a 11806b and 11806c.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return containing, in total, 1 ExtrinsicObject, 1 Submission Set, and 1 Association.
4. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11807

GetDocument Query

Verify that Document Consumer can use the GetDocument query and that a Document Registry can service such a query.

References

ITI TF-2 3.14

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test #11870 must be run before this test to establish test data

Testing Document Consumer Actor

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

Testing Document Registry Actor

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

11808

GetSubmissionSetContents Query

Verify that Document Consumer can use the GetSubmissionSetContents query and that a Document Registry can service such a query.

This query allows the Document Consumer to specify the documents by UUID (native to Registry standard) or uniqueId (native to health care environment). This Query test offers opportunity to test either.

To run efficiently, this query must be broken down into 3 queries:

1. Query for XDSSubmissionSet
2. Query for Documents
3. Query for XDSFolders

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the queries in
   • uuid/11808a/get_submission_set_contents_1.xml
   • uuid/11808b/get_submission_set_contents_2.xml
   • uuid/11808c/get_submission_set_contents_3.xml

To use these queries, the parameter $uniqueId must be changed to a real value

AND

• uniqueId/11808a/get_submission_set_contents_1.xml
• uniqueId/11808b/get_submission_set_contents_2.xml
• uniqueId/11808c/get_submission_set_contents_3.xml

To use these queries, the parameter $uuid must be changed to a real value

1. Verify that you get successful RegistryResponse messages in return
2. containing XDSSubmissionSet, Document and XDSFolder.
3. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11808a 11808b and 11808c.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return
4. containing XDSSubmissionSet, Document and XDSFolder.
5. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11809

GetFolderContents Query

Verify that Document Consumer can use the GetFolderContents query and that a Document Registry can service such a query.

To run efficiently, this query must be broken down into 3 queries:

1. Query for XDSFolder
2. Query for XDSSubmissionSet
3. Query for Documents

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the queries in
   • uuid/11809a/get_folder_contents_1.xml
   • uuid/11809b/get_folder_contents_2.xml
   • uuid/11809c/get_folder_contents_3.xml

AND

• uniqueId/11809a/get_folder_contents_1.xml
• uniqueId/11809b/get_folder_contents_2.xml
• uniqueId/11809c/get_folder_contents_3.xml

1. Verify that you get successful RegistryResponse messages in return
2. containing XDSSubmissionSet, Document and XDSFolder.
3. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11809a 11809b and 11809c.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return
4. containing XDSSubmissionSet, Document and XDSFolder.
5. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11810

GetFoldersForDocument Query

Verify that Document Consumer can use the GetFolderForDocument query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in
   • uuid/11810/get_folders_for_document.xml

AND

• uniqueId/11810/get_folders_for_document.xml

1. Verify that you get successful RegistryResponse messages in return
2. containing XDSFolder(s).
3. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11810.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return
4. containing XDSFolder(s).
5. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11811

GetAddendums Query

Verify that Document Consumer can use the GetAddendums query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in
   • uuid/11811/get_addendums.xml

AND

• uniqueId/11811/get_addendums.xml

1. Verify that you get successful RegistryResponse messages in return
2. containing ExtrinsicObject(s).
3. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11811.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return
4. containing ExtrinsicObject(s).
5. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11812

GetHistory Query

Verify that Document Consumer can use the GetHistory query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in

• uuid/11812/get_history.xml

AND

• uniqueId/11812/get_history.xml

1. Verify that you get successful RegistryResponse messages in return
2. containing ExtrinsicObject(s).
3. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11812.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return
4. containing ExtrinsicObject(s).
5. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11813

GetTransformations Query

Verify that Document Consumer can use the GetTransformations query and that a Document Registry can service such a query.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Document Registry

Dependencies

When testing Document Registry actor, test 11870 must be run before this test to establish test data

Testing Document Consumer Actor

1. Configure the Document Consumer under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/portals/query
2. Have your Document Consumer issue the query in

• uuid/11813/get_transformations.xml

AND

• uniqueId/11813/get_transformations.xml

1. Verify that you get successful RegistryResponse messages in return
2. containing ExtrinsicObject(s).
3. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Registry Actor

1. Edit the test.properties file in 11813.
   • Change the URL parameter to point to your registry.
2. Run the tests using xdstest.
3. Verify that you get a successful RegistryResponse messages in return
4. containing ExtrinsicObject(s).
5. Log the results: #Result_Reporting_-_Server_Testing_using_xdstest

11814

Basic Transport

Test basic transport mechanisms, HTTP and SOAP, for transferring metadata without mutual TLS authentication. Document Consumer makes an HTTP connection to Document Registry. A simple SOAP package is transferred containing simple non-metadata XML. The Registry may return an error message because the payload is not metadata. This is acceptable.

References

ITI TF-2 3.14

Actors Tested

Document Consumer

Document Registry

Testing Document Consumer Actor

1. Configure the Document Source under test to send to the URL
   • http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/test?testid=11814
2. Have your Document Source send a SOAP over HTTP message with arbitrary content
3. Verify that you get a valid SOAP message back, it may contain an error message from the repository. If you using a SOAP parser, errors in parsing are likely. This test is intended to support folks using simpler tools. The parsing error is acceptable.
4. Log the results: #Result_Reporting_-_Client_Testing_against_server

Testing Document Repository Actor

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

11827

Accept One Document

Verify that the Document Repository can accept a SOAP over HTTP message containing metadata and a single document. The metadata shall be augmented with the following attributes to match the included document:

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

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

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

Document Repository

Testing Document Repository Actor

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

11870

Load test data set 1

Load test data into Registry to support query testing.

References

ITI TF-2 3.14

Actors Tested

None

Dependencies

None

Testing Document Registry Actor

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

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

11871

Accept Document Replace

This test procedure also applies to tests 11873, 11874, 11875 which deal with Addendum, Transformation, and Replace with Transformation. In the test description below, replace RPLC as an Association type with the correct Association type for the other tests.

A Document Registry must be able to accept a submission that performs a document replace. Such a submission consists of metadata for a single document and an Association object of type RPLC. This document is to replace a document already in the registry. The Registry Adaptor takes responsibility for recognizing the RPLC operation and labeling the replaced document with status=Deprecated. Since this is a Registry Transaction, no actual documents are involved, just document metadata. For more discussion on Document Replacement see test #11748.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Allocate a new patient ID
2. Register a document via a Register Transaction to your Document Registry actor using any method. Test #11731 is one option.
3. Construct a new Submission Set consisting of an XDSDocumentEntry and a RPLC Association. The Submission Set and XDSDocumentEntry must be assigned the same patient ID as the document in the previous step.
4. Discover the UUID of the document submitted in step 2 via a query of your choice.
5. Insert an ObjectRef into the submission with this UUID. This tells the registry engine that a reference is being made from the submission back to the registry.
6. Add an Association object to the submission with
   • associationType of RPLC (or APND, XFRM, or XFRM_RPLC)
   • sourceObject referencing the new XDSDocumentEntry already placed in the submission
   • targetObject should contain the UUID from step 4
7. Submit the submission to your registry using xdstest.
8. Log the results via #Log_Results_of_Register_transaction_against_your_Registry

11876

Reject Submission of Invalid Patient ID

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Identify a patient ID that has not been received through Patient Identity Feed transaction.
2. Submit metadata via a Register Transaction to your Document Registry actor using xdstest.
   • Set the patient ID to a non-existing patient ID
3. Log the results showing the error message returned via #Log_Results_of_Register_transaction_against_your_Registry

11877

Reject Submission Set, Patient ID does not match Document

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Use test material in tests/11877
2. Edit XDSDocumentEntry.patientId attribute, set to a valid and registered patient ID for your registry
3. Edit XDSSubmissionSet.patientId attribute, set to a valid and registered patient ID for your registry. It must be different than XDSDocumentEntry.patientId
4. Submit this via a Register Transaction to your Document Registry actor using xdstest.
5. Log the results showing the error message returned via #Log_Results_of_Register_transaction_against_your_Registry. This must be run twice, once for each of the two patientIds

11878

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

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. In the first submission, a simple document submission (see #11731 for example) set XDSSubmissionSet.patientId and XDSDocumentEntry.patientId to the same value
2. In the second submission, (tests/11878) set XDSSubmissionSet.patientId and XDSDocumentEntry.patientId to the same value, different from the first submission
3. Submit this via a Register Transaction to your Document Registry actor using xdstest.
4. Log the results showing the error message returned via #Log_Results_of_Register_transaction_against_your_Registry. This must be run twice, once for each of the two patientIds

11879

Accept Create Folder

Verify that the Document Registry can accept a valid SOAP over HTTP message containing valid metadata for the creating of Folder.

This submission consists of:

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Allocate a new patient ID
2. Edit test/11879/test.properties
   • Change the URL parameter to point to your registry.
   • Set the patient ID
3. Edit the metadata included in this test:
   • Setting the patient ID into the Submission Set and Document metadata
   • Assign the necessary unique IDs
4. Run the test using xdstest.
5. Log the results: #Log_Results_of_Register_transaction_against_your_Registry

11880

Accept Create Folder with Initial Document

This test demonstrates that a Document Registry actor implementation can create a folder with an initial document.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Allocate a new patient ID
2. Edit 11880/test.properties
   • Change the URL parameter to point to your Registry.
3. Edit 11880/metadata.xml
   • Assign uniqueIds
   • Assign patient ID
4. Run the test using xdstest.
5. Log the results: #Log_Results_of_Register_transaction_against_your_Registry

11881

Accept Add Document to Folder

This test demonstrates that a Document Registry actor implementation can add a document to a folder. This can happen in two ways. First a submission set can be sent to the registry containing a document and the association to add the document to a folder. Second, the document could already exist in the registry in which case only the association need to be added. In this case, no Submission Set is included.

The following metadata must be submitted as is or as part of a document (in submission set) submission. In either case, the UUID of the folder must be discovered via query. If the document already exists then its UUID must also be discovered by query.

        <ObjectRef id="UUID for a folder in the registry"/>
        <Association 
            associationType="HasMember" 
            sourceObject="UUID for a folder in the registry" 
            targetObject="theDocument"/>
        </Association>

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Allocate a new patient ID (see #Allocating_new_Patient_IDs_for_Testing)
2. Edit 11881/test.properties
   • Change the URL parameter to point to your Registry.
3. Edit 11881/metadata.xml
   • Assign uniqueIds
   • Assign patient ID
4. Run the test using xdstest.
5. Log the results: #Log_Results_of_Register_transaction_against_your_Registry

11882

Reject Add Document to Folder - Patient ID does not match

Documents added to a Folder are required to be assigned to the same patient ID. This test allows a Document Registry actor implementation to show that it follows this constraint.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Rerun test 11881 with an incorrect patient ID (does not match)
2. Log the results: #Log_Results_of_Register_transaction_against_your_Registry, showing that the submission was reject with a reasonable error message. This must be run twice, once for each patient ID.

11883

Submission Stored - All or Nothing

Partial storage of a Submission Set is not permitted in XDS. A Submission Set is accepted and stored successfully or is rejected in whole. In this test, an existing two-document submission is altered to introduce an error. Specifically, the patient ID attribute is removed from the second document. A query is then issued to show that no change has been made to the registry.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Rerun test 11735 after editing the metadata so that the one classification object for one of the documents does match (coding scheme name, code, and code name must normally match each other and be included in the configuration of the Affinity Domain)
2. Show that your Registry actor throws an error with a reasonable error message and that the entire submission was reject. This is demonstrated through the logs requried for test 11735.

11884

Accept Add By-Reference to Submission Set

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

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

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

11885

Reject Duplicate Document uniqueID with Different Hash

The XDS Profile accepts duplicate document submissions as long as the hash field of the XDSDocumentEntry object is identical.

References

ITI TF-2 3.14

Actors Tested

Document Registry

Dependencies

None

Testing Document Registry Actor

1. Allocate a new patient ID
2. Allocate a single uniqueId for this test
3. Using tests/11885
   • Edit in patient ID
   • Edit in the uniqueID
   • Submit this via a Register Transaction to your Document Registry actor using xdstest.
   • The Registry actor must accept this submission
4. Using tests/11885 again
   • Edit in same patient ID
   • Edit in same uniqueID
   • Edit in different hash
   • Submit this via a Register Transaction to your Document Registry actor using xdstest.
   • The Registry actor must reject this submission and return a reasonable error message.
5. Log the results showing the error message returned via #Log_Results_of_Register_transaction_against_your_Registry

11886

Pass Arbitrary Metadata

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

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

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

Document Repository

Testing Document Repository Actor

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

11887

Return Errors from Registry

References

ITI TF-2 3.14

ITI TF-2 3.15

Actors Tested

Document Repository

Testing Document Repository Actor

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

Query - Configuring the SQL queries supplied in the testkit

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

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

Query - Testing the Document Registry

This test procedure is used for all Queries.

Verify that a Document Registry can service each query type.

References

ITI TF-2 3.16

Actors Tested

Document Registry

Dependencies

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

Testing Document Registry Actor

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

Query - Testing the Document Consumer

Verify that Document Consumer can use the Query facility.

References

ITI TF-2 3.16

Actors Tested

Document Consumer

Dependencies

None

Testing Document Consumer Actor

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

Stored Query - Testing the Document Registry

The testing of all Stored Queries follows the same instructions.

References

ITI TF-2 3.18

Actors Tested

Document Registry

Dependencies

test #11870 - load test data set 1

test #11910 - load test data set 2

test #11890 - load test data set 3 (Folders)

Testing Document Registry Actor

1. Identify the directory in the test kit that supports the query of interest. As an example, test 11900 (GetAll query) can be found in directory tests/11900.
2. Edit the file test.properties to point to your Registry by editing the value of the url property.
3. Execute the test by running xdstest in that directory
4. Report the results using the directions at #Log Results of Register transaction against your Registry

Note that tests 11897 (FindDocuments) and 11898 (FindSubmissionSets) each have multiple parts (identified by sub-directory parta, partb, etc). 11897 has 3 parts and 11898 has 2 parts. For these two tests, each part must be tested against your registry and reported.

Stored Query - Testing the Document Consumer

The testing of all Stored Queries follows the same instructions.

References

ITI TF-2 3.18

Actors Tested

Document Consumer

Dependencies

none

Testing Document Consumer Actor

1. Execute stored query against Public Registry.
2. Report your results following the instructions at # Log_Results_of_Query_or_Stored_Query_transactions_tested_against_the_Public_Registry

See #Stored Query - Testing the Document Registry for details on test data.

11890

Load test data set 3

Load test data into Registry to support query testing.

References

ITI TF-2 3.14

Actors Tested

None

Dependencies

None

Testing Document Registry Actor

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

This submission contains a single Submission Set, 1 Document, 2 Folders and Associations to make the documents part of the Submission Set and part of both Folders.

11951

Load test data set 2

Load test data into Registry to support query testing.

References

ITI TF-2 3.14

Actors Tested

None

Dependencies

None

Testing Document Registry Actor

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

This submission contains a single Submission Set, 1 Document, and Association to make the document part of the Submission Set.

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

11962

Submit XDM content for evaluation

References

ITI TF-2 3.32

Actors Tested

Portable Media Creator

Generate a ZIP file containing a single Submission Set and two documents in XDM format. Document type and details of metadata are not constrained. Please use the Metadata Validator to check your metadata before submitting. Use the Register Transaction setting.

Test will be evaluated based on fullness of metadata (required fields present), correct linkage between metadata and documents, correct directory structure, and correct content in support files (README.TXT and INDEX.HTM).

ZIP file shall be uploaded into Kudu as a 'log file'.

11963

Accept Submission

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

References

ITI TF-2 3.14

Actors Tested

Document Recipient

Testing Document Recipient Actor

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

11964

Send One Document

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

References

ITI TF-2 3.14

Actors Tested

Document Source

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

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

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

11965

Accept XDM Content

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

References

ITI TF-2 3.32

Actors Tested

Portal Media Importer

Content can be found in tests/11965.

11949

Stored Query for ObjectRefs

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

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

References

ITI TF-2 3.18

Actors Tested

Document Consumer

Document Registry

Dependencies

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

Testing Document Consumer Actor

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

Testing Document Registry Actor

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

11950

Stored Query for LeafClass

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

References

ITI TF-2 3.18

Actors Tested

Document Consumer

Document Registry

Dependencies

Test 11870 must be run before this test

Testing Document Consumer Actor

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

Testing Document Registry Actor

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

Test Data Description

The table below briefly describes the test data loaded into the Public Registry for testing. The same data is available in tests #11870, #11910, and #11890 for use in vendor registries.

All patientIds have Assigning Authority of 1.3.6.1.4.1.21367.2005.3.7 so that a patientId shown below in short form as NIST-test-10 is really NIST-test-10^^^&1.3.6.1.4.1.21367.2005.3.7&ISO

All uniqueIds are shown without their 1.3.6.1.4.1.21367.2005.3.999. prefix.

All Confidentiality Codes are shown without their 1.3.6.1.4.1.21367.2006.7. prefix.

PatientId	SS uniqueId	Doc uniqueId	Doc confidentialityCode	Fol uniqueId	Description
NIST-test-10	672				Three document submission
		669	101
		670	104
		671	101
NIST-test-10	674				Single document submission
		673	101
NIST-test-11	676				Two folders and one document submission
		675	101
				677
				678