MESA/Acquisition Modality

Acquisition Modality Test Cases

Modality Tests

Introduction

This document describes several tests for Acquisition Modality systems. The tests depend on the Integration Profiles supported by the Modality. The Display Consistency tests are defined in a separate document: Display Consistency Test Plan for Image Creators.

Configuration

The Modality scripts use an ASCII configuration file to identify parameters such as host names and port numbers. The configuration file is named mod_test.cfg and is included in the directory $MESA_TARGET/mesa_tests/rad/actors/mod. Edit the file and change entries (host name, port number) which pertain to your system. Your system is identified by entries that begin with TEST.

For IHE Basic Security tests, all messages are exchanged using TLS. MESA servers are run on the same ports but with the TLS option. The configuration file that identifies your information is mod_secure.cfg. This separate file allows you to use different port numbers for secure and standard configurations. You may decide to use the same port numbers for both types of communication. The MESA software will only use all secure or all standard communication for a test; we do not mix communication protocols.

This version of the software assumes the AE title of your modality is MODALITY1. That will be the Scheduled AE title and the AE title we assume you use when you send images, mpps events and storage commitment requests. Please use this AE title for your modality.

Modalities will communicate with two MESA servers during these tests. Parameters for the tests are listed below. Worklist queries should be sent to the MESA MWL Server. All other messages (storage, storage commitment, MPPS) should be sent to the MESA Image Manager.

The file $MESA_TARGET/runtime/imgmgr/ds_dcm.cfg is used to configure the MESA Image Manager . The only parameter users should change is the LOG_LEVEL value. Log levels are defined in Starting MESA Servers. DICOM configuration parameters are listed in the table below.

MESA Image Manager	MESA_IMG_MGR	2350
MESA MWL Server	MESA_MWL	2250
MESA Audit Record Repostiory		4000

There is a one-time setup step to run before any tests are started. DICOM UIDs and other identifiers have seed values which are stored in the MESA databases. You should reset the UIDs one time before you start the tests. If you decide to rerun tests, you should not have to reset the UIDs. If you decide to reload the Modality Worklist, you will get different Study Instance UIDs (which is probably the behavior that you want). To set the UIDs for the first time or reset them at a later time:

   perl  scripts/reset_uids.pl

Starting the MESA Servers

These instructions assume you are using a terminal emulator on Unix systems or an MS DOS command window under Windows 2000 or Windows XP. Each test uses a command line interface; there is no graphical user interface. Before you start the test procedure, you need to start the MESA Order Placer and MESA Order Filler servers. Make sure the appropriate database is running (PostgreSQL, SQL Server). To start the MESA servers:

1. Enter the Modality exam folder: $MESA_TARGET/mesa_tests/rad/actors/mod or $MESA_TARGET/mesa_tests/card/actors/mod 2. Execute the appropriate script to start the servers:

    scripts/start_mesa_servers.csh(Unix)     
    
    scripts\start_mesa_servers.bat  (Windows)

Log levels are set for the MESA Image Manager in the file:

$MESA_TARGET/runtime/rpt_manager/ds_dcm.cfg. /Log levels are:

0. no logging

1. errors

2. warnings

3. verbose

4. conversational (really verbose)

When you are finished running one or more tests, you can stop the servers:

   scripts/stop_mesa_servers.csh  (Unix) 

   scripts\stop_mesa_servers.bat  (Windows)

Log files are stored in $MESA_TARGET/logs. For the security tests, the MESA servers are started with different scripts. These are scripts/start_mesa_secure.csh and scripts\start_mesa_secure.bat. The log levels are the same as for the standard tests. The MESA servers are stopped using these scripts:scripts/stop_mesa_secure.csh and scripts\stop_mesa_secure.bat.

Submission of Results

Test descriptions below inform the reader to “submit results to the Project Manager”. This is does not mean “email”. The current submission process should be documented by the Project Manager, but will not include emailing files directly to the Project Manager.

Individual Tests

Modality Worklist Values

The table below gives a terse summary of the modality tests for scheduled workflow. The table uses a notation for procedure steps and action items such as X1/X1_A1. That means the procedure step is X1 and the corresponding action item is X1_A1. You will not see X1 in the modality worklist, but you will see the action item X1_A1. Some procedure steps have two action items. For example, the procedure step X4B has associated action items X4B_A1 and X4B_A2.

The individual test sections below should provide a more complete description of each test and what the modality is expected to produce.

Test	Description	Requested Procedure	SPS / Action Items	PPS / Action Items	PPS
201	Unscheduled	none	none	X1/X1_A1	1
211	Simple Case	P1	X1 / X1_A1	X1 / X1_A1	1
213	Simple Case	P8	X8A / X8A_A1 X8B / X8B_A1	X8A / X8A_A1 X8B / X8B_A1	2
214	Simple	P4	X4 A / X4A_A1 X4B / X4B_A1, X4B_A2	X4A / X4A_A1 X4B / X4B_A1, X4B_A2	2
215	Simple but perform different procedure	P10	X10/X10_A1	X2/X2_A1	1
221	Group Case	P3	X3A / X3A_A1 X3B / X3B_A1	X3A/X3_A1, X3B_X3B_A1	1
222	Group Case	P6 P7	X6 / X6_A1 X7/ X7_A1	X6 / X6_A1 X7/ X7_A1	1
231	Append Case	P5	X5 / X5_A1	X5 / X5_A1 X1 / X1_A1	2
241	Abandoned Case	P2	X2 / X2_A1	Abandoned	1

Seeding Modality Worklist Values

We assume you are using an interactive terminal or terminal emulator and are logged on to the MESA test system. Change directory to $MESA_TARGET/mesa_tests/rad/actors/mod or $MESA_TARGET/mesa_tests/card/actors/mod .

Before you run any tests, you need to produce the MESA test data (modality worklist and comparison data). For radiology cardiology and eye care tests, once the MESA servers have been started, create the test data as follows:

   perl  2xx/2xx.pl

This is a one-time step that should not have to be repeated.

General Test Instructions

The test scripts assume that you produce images and series that correspond exactly to the test instructions. For example, if the test requires two Performed Procedure Steps, the scripts expect the modality to produce two sets of MPPS messages and two corresponding series of images. If you run a test once and produce incorrect data, you will need to clear the MESA system of those messages before you run the test a second time. If you do not clear the system, the test scripts will likely evaluate the incorrect data again. To clear the Image Manager, use this command:

   perl  scripts/clear_img_mgr.pl

You should not have to clear the Image Manager if you complete one test (say 201) and are starting a different test (211). When you clear the Image Manager, you lose your ability to run the evaluation for a test you have already completed. However, this does not clear the text files with the results from the previous tests. Therefore, the general procedure to follow is:

1. Run a test to completion.

2. Obtain the results by running the proper script. These results will stay in place.

3. Start a new test; if you need to clear the Image Manager to complete the new test, your old results are not affected. However, you cannot run the evaluation scripts for old tests after clearing the Image Manager.

Modality Test: Connectathon codes for Orders and Procedures

NOTE: This test is now deprecated and replaced by https://gazelle.ihe.net/content/preloadcodesforhl7anddicom

For the Connectathon Radiology & Cardiology workflow tests we define a set of codes for Orders, Requested Procedures & Scheduled Procedures needed for HL7 and DICOM messages exchanged by Order Placer, Order Filler and Acquisition Modality actors.

1. Prior to the connectathon, you must load the codes relevant to your modality onto your test system. They are taken from this set: http://gazelle.ihe.net/examples/Bern2012-orderHierarchy.xml
   1. Note that these codes are also used in the Order Manager tool and have remained unchanged since 2012 for North American & European Connectathons.
2. If there are codes missing that you need to support your workflow, please contact the Connectathon Technical Project Manager.

Evaluation

There are no results files to upload for this test. Preloading these prior to the Connectathon is intended to save you precious time during Connectathon week.

Modality Test 201: Unscheduled Case

Unscheduled cases imply that there is no Modality Worklist available to the Modality. In this test, you should produce a study according to the table below. The following table lists the patient demographics. Because this is an unscheduled case, your Modality will provide the Study Instance UID.

Test	Description	Requested Procedure	SPS / Protocol Code Items	PPS / Protocol Code Items
201	Simple Case	None	None	X1 / X1_A1

Attribute	Value
Patient Name	WHITE^CHARLES
Patient ID	583020
Patient DOB	19980704
Patient Sex	M

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

3. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commitment_nevents.pl

If you need to rerun these tests, you can start again at step 2.

Evaluation

1. Compare your results to expected results:

   perl 201/eval_201.pl [output level]  <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 201/mir_mesa_201.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 211: Simple Case, One SPS

This test is for one Requested Procedure (P1) leading to one Scheduled Procedure Step with one Protocol Item (X1_A1). The modality is expected to perform one Performed Procedure Step as scheduled. Producing the Performed Protocol Code Sequence in the MPPS data is required if the modality supports the “Assisted Acquisition Protocol Setting” option. If the modality supports that option, set the “Protocol Flag” to “1” in Evaluation Step 1 below. Otherwise, set the value to 0.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^211. This entry should have one Scheduled Procedure Step with one Protocol Code: X1_A1.

5. Perform the one procedure as defined in the MWL.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commitment_nevents.pl

If you need to rerun these tests, you can start again at step 2.

Evaluation

1. Compare your results to expected results:

   perl  211/eval_211.pl <output level> <AE Title MPPS SCU> [Protocol Flag] [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output), and <Protocol Flag> is 0 or 1. Follow with the optional keyword Japanese if using that version of the software.

2.The evaluation output is found in 211/mir_mesa_211.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Gazelle tool.

Supplemental Information

Note: You might want to read the instructions for Modality Test 281 and extract the images required for that test. After this test has been completed, you could skip most of the steps in Test 281 and just harvest the images produced in this test.

Modality Test 213: Simple Case, Two SPS

Starting with this test, you no longer need to send Storage Commitment events. If you choose to do so (because your system does that automatically), the MESA system will accept your messages, but will not evaluate them. If you want the MESA system to respond with the proper N-Event reports, you can do so using the same script described in the tests above:

   perl scripts/send_storage_commitment_nevents.pl

This test is for one Requested Procedure (P8) leading to two Scheduled Procedure Steps each with a single Protocol Item (X8A_A1 and X8B_A1). Producing the Performed Protocol Code Sequence in the MPPS data is required if the modality supports the “Assisted Acquisition Protocol Setting” option. If the modality supports that option, set the “Protocol Flag” to “1” in step 6 below. Otherwise, set the value to 0.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^213. This entry should have two Scheduled Procedure Steps each with a single Protocol Item (X8A_A1, X8B_A1).

5. Perform the two SPS as described in the MWL.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

Evaluation

1. Compare your results to expected results:

   perl  213/eval_213.pl <output level> <AE Title MPPS SCU> [Protocol Flag]  [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1= errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 213/mir_mesa_213.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

If you need to rerun these tests, you can start again at step 3.

Supplemental Information

Modality Test 214: Simple Case, Two SPS

This test is for one Requested Procedure (P4) leading to two Scheduled Procedure Steps. The first SPS uses a single Protocol Code Item; the second SPS uses two Protocol Code Items. The modality is expected to perform both Scheduled Procedure Steps and include all Protocol Code Items. Producing the Performed Protocol Code Sequence in the MPPS data is required if the modality supports the “Assisted Acquisition Protocol Setting” option. If the modality supports that option, set the “Protocol Flag” to “1” in step 6 below. Otherwise, set the value to 0.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^214. This entry should have two Scheduled Procedure Steps; as described above, one step will have one Protocol Item and the second step will have two Protocol Items.

5. Perform the two SPS as described in the MWL.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

Evaluation

1. Compare your results to expected results:

   perl 214/eval_214.pl output_level AE_Title_MPPS_SCU Protocol_Flag [Japanese]

where

• output_level is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output).
• AE_Title_MPPS_SCU is the Application Entity title of your modality.
• Protocol_Flag = 1 if you support the “Assisted Acquisition Protocol Setting” option, 0 if not.
• Follow with the optional keyword Japanese if using that version of the software.

If you need to rerun these tests, you can start again at step 3.

2. The evaluation output is found in 214/mir_mesa_214.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 215: Perform Different Procedure

In this test, the MWL entry is for Requested Procedure P10 with Protocol Item X10_A1. At the modality, we decide to perform procedure P2 with Protocol Item X2_A1. Procedure P10 is not performed.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^215. This entry should have one Scheduled Procedure Step with a single Protocol Item.

5. Perform procedure P2 with Protocol Item X2_A1 rather than the scheduled X10_A1.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

Evaluation

1. Compare your results to expected results:

   perl 215/eval_215.pl <output  level> <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

If you need to rerun these tests, you can start again at step 3.

2. The evaluation output is found in 215/mir_mesa_215.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 218: Billing and Material Option

Test 218 exercises the Billing and Material Management Option for Acquisition Modalties (see IHE TF Vol II: section 4.7.4.1.2.3). With this option, a modality must provide one or more of the values listed in Vol II: Table 4.7-2.

References

Instructions

1. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

2. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

3. Obtain the MWL entry for patient MODALITY^218.

4. Perform the one Scheduled Procedure Step as entered in the worklist. Generate appropriate MPPS messages and fill in one or more of these sequences:

0040 0320 Billing Procedure Step Sequence

0040 0321 Film Consumption Sequence

0040 0324 Billing Supplies and Devices Sequence

5. The table below lists the values to supply for the coded items in the sequences

Attribute Name	Tag	Value
Billing Procedure Step Sequence	(0040,0320)
> Code Value	(0008,0100)	BP1001
> Coding Scheme Designator	(0008,0102)	IHEDEMO
>Code Meaning	(0008,0104)	Billing Procedure 1001
Film Consumption Sequence	(0040,0321)
>Number of Films	(2100,0170)	1
>Medium Type	(2000,0030)	CLEAR FILM
>Film Size ID	(2000,0050)	8INX10IN
Billing Supplies and Devices Sequence	(0040,0324)
> Billing Item Sequence	(0040,0296)
>> Code Value	(0008,0100)	SUP_X109
>> Coding Scheme Designator	(0008,0102)	IHEDEMO
>> Code Meaning	(0008,0104)	Catheter
>Quantity Sequence	(0040,0293)
>>Quantity	(0040,0294)	2

Evaluation

1. To Evaluate your MPPS messages:

   perl  218/eval_218.pl <log level> <AE Title MPPS SCU>

2. The evaluation output is found in 218/mir_mesa_218.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 221: Group Case, One Scheduled Procedure

In this test, a single Requested Procedure (P3) is expanded by the Order Filler into two Scheduled Procedure Steps, each with a single Protocol Item (X3A_A1, X3B_A1). The modality performs the group case by combining these two SPS. Because this is taken from a single Requested Procedure, the modality should use the Study Instance UID found in the MWL.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^221. This entry should have two Scheduled Procedure Steps each with a single Protocol Item.

5. Group the two SPS together and perform a single acquisition. That means you produce one series of images and one set of MPPS messages. The order of the Scheduled Procedure steps in the MPPS messages and composite objects (images) should not matter. This is a group case and there is no implied order of SPS items.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

Evaluation

1. Compare your results to expected results:

   perl 221/eval_221.pl <output level> <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 221/mir_mesa_221.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 222: Group Case, Two Scheduled Procedure

This test is optional for modalities in IHE Year 3 or later. In this test, two Requested Procedures (P6, P7) are scheduled by the MESA Order Filler as two separate Scheduled Procedure Steps. Each SPS has one Protocol Item. The modality performs the group case by combining these two SPS. Because this is taken from two Requested Procedures, the modality should produce a new Study Instance UID. The Referenced Study UIDs are still copied from the MWL entries.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^222. This entry should have two Scheduled Procedure Steps each with a single Protocol Item.

5. Group the two SPS together and perform a single acquisition. That means you produce one series of images and one set of MPPS messages. The order of the Scheduled Procedure steps in the MPPS messages and composite objects (images) should not matter. This is a group case and there is no implied order of SPS items.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

If you need to rerun these tests, you can start again at step 2.

Evaluation 1. Compare your results to expected results:

   perl 222/eval_222.pl <output level> <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 222/mir_mesa_222.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 231: Append Case

In the Append Case, the modality first performs the procedures as listed in the MWL and then adds another procedure at a later time. In this test, the scheduled Requested Procedure is P5 with a Protocol Code Item X5_A1. The appended step will use the same Protocol Code Item: X5_A1. This test is when the Append Case is used to take a second set of images. For example, the first set is to be discarded because of some artifact. In previous versions of this test, the modality was expected to perform a step that was different than the value on the Modality Worklist. That has been changed in this document to use the same step. Producing the Performed Protocol Code Sequence in the MPPS data is required if the modality supports the “Assisted Acquisition Protocol Setting” option. If the modality supports that option, set the “Protocol Flag” to “1” in step 7 below. Otherwise, set the value to 0.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^231. This entry should have one Scheduled Procedure Step for Procedure P5.

5. Peform the Procedure P5 as listed in the MWL.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

7. Now perform the append step. Perform the same step that is found in the Modality Worklist. Send the MPPS events and images to the MESA Image Manager as abaove.

Evaluation 1. Compare your results to expected results:

   perl  231/eval_231.pl <output level> <AE Title MPPS SCU> <Protocol Code Flag> [language flag]

where

• <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output)
• <AE Title MPPS SCU> is the Application Entity title of your modality
• <Protocol Code Flag>: 0 -> do not evaluate MPPS Performed Protocol Code Sequence, 1-> do evaluate MPPS Performed Protocol Code Sequence
• [language flag]: Use the keyword Japanese if using that version of software

[language flag] is optional. All other parameters are required.

2. The evaluation output is found in 231/mir_mesa_231.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 241: Abandoned Case

In the Abandoned Case, the modality retrieves the MWL entry and abandons the case by setting the status in the MPPS messages to discontinued. We assume that the modality does not produce any images in this test (but we do not test for that).

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^241. This entry should have one Scheduled Procedure Step for Procedure P2.

5. Abandon this procedure by sending MPPS events with status of DISCONTINUED to the MESA Image Manager.

If you need to rerun these tests, you can start again at step 2.

Evaluation

1. Compare your results to expected results:

   perl 241/eval_241.pl <output level> <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the

amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 241/mir_mesa_241.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 242: Exception Management

The Exception Management test is similar to test 241, Abandoned Case. With the Exception Management option, the modality should include the Modality Procedure Step Discontinuation Reason Code Sequence (0040, 0281). In this test, we require that you discontinue one procedure step with a specific code value/reason.

References

Instructions

1. Start the MESA servers as described in Starting MESA Servers.

2. Make sure you have seeded the MWL with values: Seeding Modality Worklist Values

3. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

4. btain the MWL entry for the patient: MODALITY^242. This entry should have one Scheduled

5. Procedure Step for requested procedure P1.

6. Abandon this procedure by sending MPPS events with status of DISCONTINUED to the MESA Image Manager. You need to include the sequence (0040 0281) with the specific code value: 110505, Patient refused to continue procedure.

If you need to rerun these steps, you can start again at step 2.

Evaluation

7. Compare your results to expected results:

   perl 242/eval_242.pl <output  level> <AE Title MPPS SCU> [Japanese]

2. The evaluation output is found in 242/mir_mesa_242.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality Test 251: Storage Commitment Association Negotiation

This is a test of association negotiation with your modality (or Evidence Creator). An Image Manager that wants to send Storage Commitment N-Event reports will initiate a DICOM association with your modality and should propose to be an SCP of the Storage Commitment SOP Class (Push Model). In this test, one association will be proposed. The MESA Image Manager proposes the SCP role. Your modality should accept this association and proposed presentation context.

References

Instructions

1. Start your server process that accepts Image Manager Storage Commitment association requests.

2. Run the evaluation script for this test. This script sends the appropriate association requests and records results in 251/grade_251.txt:

   perl 251/eval_251.pl [-v]

3. The evaluation output is found in 251/mir_mesa_251.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Gazelle tool.

Supplemental Information

Modality Test 271: Patient Update Tests

In these tests, you will retrieve a DICOM Modality Worklist with patient demographic information. The worklist entries on the server will be modified, and you will be asked to obtain the updated demographics for use in procedures. You will not need to update demographics after an exam has started.

Instructions

1. Start the MESA servers as described in Starting MESA Servers.

2. Obtain the MWL entry for the patient: MODALITY^271. This entry should have one Scheduled Procedure Step for requested procedure P1. 3. Run the perl script for test 271. This script will tell you to query for the existing worklist, prompt you for a new patient name, update the worklist and tell you to query the worklist again.

   perl 271/271_mod.pl

4. There is no evaluation script for this test. You will be able to tell if your worklist has been updated with the proper name.

Modality Test 281: Example Images and other DICOM objects

July-2016 - This test description has been replace by https://gazelle.ihe.net/content/evsdicomobjectevaluation

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare those other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples 2-3 weeks before the usual test deadlines.

Instructions

• Determine a representative set of images for your imaging modality that would help other actors understand your content. We do not expect you to generate images for every combination of parameters; pick one set of parameters. However, if your system supports more than one SOP class, or can use more than one transfer syntax, we expect you to upload representative samples for each.

• Assuming you have this ability, render the images you produced as a reference. The goal is for an Image Display actor to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

• Upload sample objects and the screen capture snapshot into Gazelle under Connectathon -> List of Samples. On the Samples to share tab, upload your sample image(s) under the "DICOM_OBJECTS" entry.

• • Some image sets are too large to upload into gazelle. If you encounter this, please contact the Connectathon Technical Project Manager to for instructions on alternatives.

• Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as the result file for this test.

• As Image Display actors render your data, you may receive a request for interpretation or directives from the Connectathon Technical Project Manager to repair attributes. This may prove to be an iterative process.

• You may submit more than one set.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure the worklist entries for step 211 have been created (see test 211).

3. Clear the MESA Image Manager.

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^211. This entry should have one Scheduled Procedure Step with one Protocol Code: X1_A1.

5. Perform the one procedure as defined in the MWL.

6. Send the appropriate images to the MESA Image Manager.

7. Locate the images stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

8. Assuming you have this ability, render the images you produced as a reference. The goal is for an Image Display actor to examine your rendered images and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

9. Continue with step D above.

Evaluation There is no specific evaluation for this test. Feedback comes as your partner Image Display and Image Manager partners test with your images in their lab.

Modality Test 282: Example GSPS Objects

In this “test”, you use the MESA tools to collect GSPS object and then send those objects to the Project Manager for distribution to other vendors. These are the objects that you would expect to use in the demonstration. The MWL entries will use the MWL codes for the simple 211 case. If your modality produces both images and GSPS objects, use the same samples for both test 281 and test 282 if possible. Do load data for both tests. If your images already contain LUTs with P-Values, upload the images and skip creating extra GSPS objects.

References

Instructions

The instructions below assume that you send data to the MESA servers and then extract them. If you find it easier to write your own DICOM Part 10 files, then do so.

1. Start the MESA servers as described in Starting MESA Servers.

2. Clear the MESA Image Manager.

   perl scripts/clear_img_mgr.pl

3. Obtain the MWL entry for the patient: MODALITY^211. This entry should have one Scheduled Procedure Step with one Protocol Code: X1_A1.

4. Perform the one procedure as defined in the MWL.

5. Send the appropriate images or GSPS objects to the MESA Image Manager.

6. Locate the objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

7. Assuming you have this ability, render the objects you produced as a reference. The goal is for an Image Display actor to examine your rendered images/GSPS objects and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

8. Upload images/GSPS objects and the screen capture snapshot into gazelle under Connectathon-->List of samples. Select your system name and Add a GSPS 'Sample to share'. (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

9. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as the result file for this test.

Evaluation

As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Supplemental Information

Test 285: DICOM SOP Classes

In this test, you list the DICOM SOP classes and transfer syntaxes that are supported by your system. The goal of this test is to publish this list of SOP classes well in advance of Connectathon events so that other systems who might process your objects will not be surprised.

Instructions

You can complete this test one of two ways:

1. Upload your DICOM Conformance Statement, or a link to your DICOM CS, into Gazelle. Under Gazelle menu Registration-->Manage Systems click on the name of your test system. Then on the System Summary tab, you will be able to add your DICOM CS, or add its link.

--or--

2. Create a text file named <gazelle_system_name>_285.txt. In the text file, enter your organization name, system name and date. List the DICOM SOP Classes and Transfer syntaxes your Modality supports. Upload that text file into the Gazelle as the results for test 285.

Evaluation

There is no formal evaluation for this test. The purpose is to notify Connectathon technical managers and vendor participants of the SOP Classes & Transfer Syntaxes to expect from you.

Test 511: Key Image Note 511

In this test, the Acquisiton Modality will create a Key Image Note that refers to a single image.

References

Instructions

1. Start the MESA servers as described above.

2. Clear the MESA Image Manager.

   perl scripts/clear_img_mgr.pl

3. Create one series of images with patient name: CRTHREE^PAUL and patient ID: CR3. Assume this is the unscheduled case (no MWL). Send the image or images to the MESA Image Manager.

4. Create a Key Image Note with the parameters described below. Send the DICOM composite object to the MESA Image Manager.

Evaluation

1. Evaluate the contents of your Key Image Note as follows:

   perl 511/eval_511.pl [-v]

2. Locate the composite objects stored by the MESA Image Manager. These should be in $MESA_STORAGE/instances. Tar or zip the files for the images and Key Image Note.

3. If the file is small enough, you may upload it into gazelle as results for this test. If the file is too large, send an email to the Project Manager stating that you are ready to submit results. Do not email the zipped objects. You will receive a response containing instructions for submitting your objects to an ftp site or sending in a CD.

Supplemental Information

If you need to send the note a second time, you should clear the MESA Image Manager first. This will allow the evaluation software to examine your latest object.

   perl  scripts/clear_img_mgr.pl

Template Identifier	2010:DCMR
Document Title	113000:DCM:Of Interest
HAS OBS CONTEXT	CODE 121005:DCM:Observer Type = 121006:DCM:Person
HAS OBS CONTEXT	PNAME 121008:DCM:Person Observer Name = MOORE^STEVE
CONTAINS TEXT	113012:DCM:Key Object Description = Key Object Test 511
Image Reference	Should refer to one image

Test 512: Key Image Note 512

In this test, Acquisition Modalities will create a Key Image Note that refers to two images from one series.

References

Instructions

1. Create/modify the SQL script to identify the Evidence Creator under test.

2. Start the MESA servers as described in Starting the MESA Servers above.

3. The steps below are run from the directory $MESA_TARGET/mesa_tests/rad/actors/imgcrt.

4. Load the data sets into the MESA Image Manager.

   perl 5xx/load_img_mgr.pl

5. Retrieve the study for the patient CTFIVE^JIM.

6. Create a Key Image Note with the parameters described below. Send the DICOM composite object to the MESA Image Manager.

Evaluation

1. Evaluate the contents of your Key Image Note as follows:

   perl 512/eval_512.pl [-v]

Supplemental Information

If you need to send the note a second time, you should clear the MESA Image Manager first. This will allow the evaluation software to examine your latest object.

   perl  scripts/reset_servers.pl

Template Identifier	2010:DCMR	Required
Document Title	113007:DCM:For Patient	Required
HAS CONC MOD	CODE 121049:DCM:Language of Content Item and Descendants = ISO369_2:eng:English	Optional
HAS OBS CONTEXT	CODE 121005:DCM:Observer Type = 121006:DCM:Person	Required
HAS OBS CONTEXT	PNAME 121008:DCM:Person Observer Name = MOORE^STEVE	Required
CONTAINS TEXT	113012:DCM:Key Object Description = Key Object Test 512	Required
Image Reference	Select the images with Image Number 67 and 68	Required

Test 513: Key Image Note 513

In this test, Acquisition Modalities will create a Key Image Note that refers to two images; each from a different series.

References

Instructions

1. Create/modify the SQL script to identify the Evidence Creator under test.

2. Start the MESA servers as described in Starting the MESA Servers above.

3. The steps below are run from the directory $MESA_TARGET/mesa_tests/rad/actors/imgcrt.

4. Load the data sets into the MESA Image Manager.

   perl 5xx/load_img_mgr.pl

5. Retrieve the study for the patient MRTHREE^STEVE.

6. Create a Key Image Note with the parameters described below. Send the DICOM composite object to the MESA Image Manager.

Evaluation

1. Evaluate the contents of your Key Image Note as follows:

   perl 513/eval_513.pl [-v]

2. Submit the output of the results into gazelle as the results for this test.

If you need to send the note a second time, you should clear the MESA Image Manager first. This will allow the evaluation software to examine your latest object.

   perl  scripts/reset_servers.pl

Supplemental Information

Table of information to use when creating Key Object Note

Template Identifier	2010:DCMR	Required
Document Title	113004:DCM:For Teaching	Required
HAS CONC MOD	CODE 121049:DCM:Language of Content Item and Descendants = ISO369_2:eng:English	Optional
HAS OBS CONTEXT	CODE 121005:DCM:Observer Type = 121006:DCM:Person	Required
HAS OBS CONTEXT	PNAME 121008:DCM:Person Observer Name = MOORE^STEVE	Required
CONTAINS TEXT	113012:DCM:Key Object Description = Key Object Test 513	Required
Image Reference	Select Image 9 from Series 103 Select image 19 from Series 104	Required

Test 552: Example Key Image Note

The goal of this test is to send representative samples to the Project Manager for distribution to other vendors. These samples will be based on test 511.

References

Instructions

Either create DICOM Part 10 files with your original DICOM files and submit them (step 3-4) or follow the instructions below.

1. After you complete test 511, locate the Key Image notes stored on the MESA Image Manager. These will be in $MESA_STORAGE/imgmgr/instances. The first directory level is the Study Instance UID. You should recognize your Key Image Notes by the Series Instance UID used to identify the next directory.

2. Upload sample objects and the screen capture snapshot into gazelle under Connectathon-->List of samples. Select your system name and add objects uhder 'Sample to share'. (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

3. Create a short txt file indicating you have completed the upload step. Upload that txt file into the gazelle system as results for this test.

4. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

The evaluation of this test comes in the form of feedback from other users of your data. If other users identify issues with your data, you will be asked to work with those users (and Project Manager) to resolve those issues.

Supplemental Information

Consistent Presentation of Images Tests

Modality Test 521: Consistent Presentation of Images

This test is for Modalities that support the Consistent Display of Images integration profile. These modalities should use the MESA Image Display reference system (DICOMscope) to validate the images and presentation states they create. Instructions for this test are found in the document Display Consistency Test Plan for Evidence Creator.

1xx Series Modality Tests (PGP Tests)

These tests are similar to the 2xx series modality tests. The setup steps are the same as for the 2xx setup steps (the Individual Tests section of this document) with one exception. To create the test data, start the MESA servers and use the following script:

   perl  1xx/1xx.pl

Modality Test 106: Presentation of Grouped Procedures

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager.

   perl scripts/clear_img_mgr.pl

3. Obtain the MWL enties for the patient: ROSE^CARL; There should be two separate Requested Procedures (P6, P7), each with a single Scheduled Procedure Step.

4. Group the two procedures (P6, P7) and produce one series of images and one corresponding set of MPPS messages. Send the images and MPPS events to the MESA Image Manager.

5. Produce one GSPS object that “splits” the image series for Requested Procedure P6. Produce MPPS events for this Requested Procedure. This GSPS object will be in a different series than the original images. Send the GSPS object and MPPS events to the MESA Image Manager.

6. Produce one GSPS object that “splits” the image series for Requested Procedure P7. Produce MPPS events for this Requested Procedure. This GSPS object will be in a different series than the original images. Send the GSPS object and MPPS events to the MESA Image Manager.

Evaluation

1. Run the evaluation script for this test. This script sends the appropriate association requests and records results in 106/grade_106.txt. Upload that file into gazelle as results for this test.

   perl  106/eval_106.pl [-v]

Supplemental Information

Modality Test 108: PGP Test Data

This test uses the data generated in Modality Test 106. It assumes that you have cleared the Image Manager before running test 106 and that the only data in the Image Manager is from this test.

This data will be distributed to Image Manager actors for testing with their systems.

References

Instructions

1. Find the data stored in the Image Manager for the 106 test. This is located in $MESA_STORAGE/imgmgr. You need all subdirectories.

2. Render the data showing the split between the two (or more) presentation states. Perform a screen capture and capture the data in one or more JPEG (or other suitable) files.

3. Upload the GSPS and the screen capture snapshot into gazelle under Connectathon -> List of samples.... Select your system name and Add a sample for test 108. Enter information to give the Image Display information about the number of images to be rendered for each presentation state. (Note that when the DICOM objects are uploaded, this triggers and automatic DICOM validation service. You should take note of the output of the validation.)

4. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

5. As Image Manager/Order Filler actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

Supplemental Information

Charge Processing Tests

Modality Test 1305: Charge Posting Process Flow

Test 1305 is for Eye Care implementations that support Charge Posting. In this test, the Acquisition Modality performs a single procedure and includes the proper protocol code items in the output MPPS data.

Instructions

1. Run MESA test 50202. You must include the protocol code items in the MPPS objects.
2. When you perform the evaluation of test 50202, make sure you specify the switch to examine the protocol code items.
3. Rename the output file from grade_50202.txt to grade_1305.txt
4. Submit the result for evaluation to the Project Manager.

Evaluation

Supplemental Information

Basic Security Tests

This section describes tests that are specific to the IHE Basic Security integration profile. If you have the MESA servers running for the “standard” tests, you should stop those servers now. You will need to start the MESA secure servers with a different script. Before you run any tests, you need to produce the MESA test data (modality worklist and comparison data). Once the MESA servers have been started, create the test data as follows:

   perl  15xx/15xx.pl

Modality Test 1591: Simple Case, One SPS

Order Filler Test 1591 uses the same sequence of events as test 211. The Acquisition Modality is expected to communicate with other systems using TLS negotiation and to send appropriate audit messages to the MESA syslog server. The table below lists the Audit Messages that should be generated by your system. Please refer to the document IHE Tests: Transaction Sequences for the full context of these messages. You might trigger other messages to the Audit Record Repository based on your interaction with your Acquisition Modality.

Identifier	Description	Source	Destination
1591.010	Begin-storing-instances	Modality	Audit Record Rep

References

Instructions

1. Start the secure MESA servers as described in Starting the MESA Servers.

2. Create the MESA test data as described above using the 15xx script.

3. Clear the MESA Image Manager.

   perl scripts/clear_img_mgr.pl

4. Obtain the MWL entry for the patient: MODALITY^211. This entry should have one Scheduled Procedure Step with one Protocol Code: X1_A1.

5. Perform the one procedure as defined in the MWL.

6. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl scripts/send_storage_commit_nevents_secure.pl

7. As part of the process of storing the images for this procedure step, your system should send a Begin-storing-instances audit message to the MESA Audit Record Repository.

Evaluation

1. Run the evaluation script for this test. This script sends the appropriate association requests and records results in 1591/grade_1591.txt:

   perl  1591/eval_1591.pl <AE Title>

where <AE Title> is the Application Entity title of your modality.

2. Grab all of the files (tar/zip) in $MESA_TARGET/logs/syslog and upload them as results for this test Supplemental Information

Evidence Documents Tests

Modality/Evidence Creator Test 1700: Evidence Document Description

In the Evidence Documents profile, Evidence Documents are defined as DICOM SR objects that are to be used to assist in diagnosis. An example would be measurements on an Ultrasound device.

The purpose of this test is to make sure that Evidence Creators and Acquisition Modalities in the Evidence Documents profile understand the content they are to produce is contained in DICOM SR objects according to the Evidence Document Profile. As mentioned above, the most obvious example are Ultrasound measurements. Another example could be a Mammography CAD file. Evidence Documents (in the Evidence Document Profile) are not images, nor are they DICOM SR Diagnostic Reports.

The instructions below are not a joke. We have had experience with this profile indicating some users do not understand the intent of the Evidence Documents profile.

References

Instructions

1. Create a text file and answer the questions below:

1. List the DICOM SOP class(es) used by your system to generate Evidence Documents. This should be one or more Structured Report Classes.

2. Describe in 100-500 words why your documents are to be considered evidence and are not merely diagnostic reports or other SR objects.

3. Describe in 100-500 words what problems other vendors will have in rendering your document or incorporating your results in a diagnostic report.

2. Name the text file using the convention: CompanyName_1700.txt

3. Submit the text file as the results for this 'test'.

Evaluation

Project Manager will read the answers provided to make sure your system is operating in the proper context.

Supplemental Information

Modality/Evidence Creator Test 1720: Evidence Document Samples

The purpose of this test is to collect SR objects from all Modality actors in the ED profile prior to the Connectathon. These vendors/actors are required to submit SR objects for every SR SOP Class supported.

In this “test”, you use the MESA tools to submit sample SR(s). The purpose is to identify interoperability problems before the Connectathon by distributing these object to Image Display actors for them to render.

• You should submit at least one example
• Note that your DICOM objects MUST NOT contain real patient demographics.
• Note that your SR(s) will be distributed to other vendors.

These files will be used by the Image Display vendors/actors. It is requested that this test, in particular, be completed at least two weeks in advance of the MESA test completion date to allow the Image Display actors to test the display of each of these objects and to allow time for communication if there is a problem.

Instructions

0. You need to export your SR samples to files for other participants to export. If your software can do that natively, you can skip steps 1-4 below.

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload the objects into gazelle under Gazelle -> List of samples.... (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

8. You may submit more than one set.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to display the contents of your objects. If they find issues in displaying the studies, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

Modality/Evidence Creator Test 20640: Evidence Creation – Cath – Vendor Interoperability

Test 20640 tests the creation and content of an SR with a Cath template.

The purpose of this test is to collect SR object/cath templates from all Acq. Modality actors in the ED-CARD profile prior to the Connectathon. These vendors/actors are required to submit SR objects for every Cath template and SR SOP Class supported. The purpose of this test is to collect SR objects from all Evidence Creator actors prior to the Connectathon. These vendors/actors are required to submit SR objects for every SR SOP Class supported.

In this “test”, you use the MESA tools to submit sample SR(s). The purpose is to identify interoperability problems before the Connectathon by distributing these object to Image Display actors for them to render.

• You should submit at least one example
• Note that your DICOM objects MUST NOT contain real patient demographics.
• Note that your SR(s) will be distributed to other vendors.

These files will be used by the Image Display vendors/actors. It is requested that this test, in particular, be completed at least two weeks in advance of the MESA test completion date to allow the Image Display actors to test the display of each of these objects and to allow time for communication if there is a problem.

Instructions

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload your DICOM SRs and a screen capture snapshot of your Evidence Document(s) into gazelle under Connectathon -> List of samples. (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

9. You may submit more than one set.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to display the contents of your objects. If they find issues in displaying the studies, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

Modality/Evidence Creator Test 20641: Evidence Creation – Echo – Vendor Interoperability

Test 20641 tests the creation and content of an SR with an Echo template.

The purpose of this test is to collect SR object/echo templates from all Acq. Modality actors in the ED-CARD profile prior to the Connectathon. These vendors/actors are required to submit SR objects for every Echo template and SR SOP Class supported. The purpose of this test is to collect SR objects from all Evidence Creator actors prior to the Connectathon. These vendors/actors are required to submit SR objects for every SR SOP Class supported.

In this “test”, you use the MESA tools to submit sample SR(s). The purpose is to identify interoperability problems before the Connectathon by distributing these object to Image Display actors for them to render.

• You should submit at least one example
• Note that your DICOM objects MUST NOT contain real patient demographics.
• Note that your SR(s) will be distributed to other vendors.

These files will be used by the Image Display vendors/actors. It is requested that this test, in particular, be completed at least two weeks in advance of the MESA test completion date to allow the Image Display actors to test the display of each of these objects and to allow time for communication if there is a problem.

Instructions

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload your DICOM SRs and a screen capture snapshot of your Evidence Document(s) into gazelle under Connectathon -> List of samples.... (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

8. You may submit more than one set.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to display the contents of your objects. If they find issues in displaying the studies, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

Modality/Evidence Creator Test 20642: Evidence Creation – CTA/MRA – Vendor Interoperability

Test 20642 tests the creation and content of an Enhanced SR with a CT/MR Cardiovascular Analysis Report template.

The purpose of this test is to collect SR objects from all Acq. Modality actors in the ED-CARD profile prior to the Connectathon. These vendors/actors are required to submit SR objects for every SR SOP Class supported.

In this “test”, you use the MESA tools to submit sample SR(s). The purpose is to identify interoperability problems before the Connectathon by distributing these object to Image Display actors for them to render.

• You should submit at least one example
• Note that your DICOM objects MUST NOT contain real patient demographics.
• Note that your SR(s) will be distributed to other vendors.

These files will be used by the Image Display vendors/actors. It is requested that this test, in particular, be completed at least two weeks in advance of the MESA test completion date to allow the Image Display actors to test the display of each of these objects and to allow time for communication if there is a problem.

Instructions

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload your DICOM SRs and a screen capture snapshot of your Evidence Document(s) into gazelle under Connectathon -> List of samples.... (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

8. You may submit more than one set.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to display the contents of your objects. If they find issues in displaying the studies, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

Modality/Evidence Creator Test 20643: Evidence Creation – Stress Test – Vendor Interoperability

Test 20642 tests the creation and content of an Enhanced SR with a CT/MR Cardiovascular Analysis Report template.

The purpose of this test is to collect SR objects from all Acq. Modality actors in the ED-CARD profile prior to the Connectathon. These vendors/actors are required to submit SR objects for every SR SOP Class supported.

In this “test”, you use the MESA tools to submit sample SR(s). The purpose is to identify interoperability problems before the Connectathon by distributing these object to Image Display actors for them to render.

• You should submit at least one example
• Note that your DICOM objects MUST NOT contain real patient demographics.
• Note that your SR(s) will be distributed to other vendors.

These files will be used by the Image Display vendors/actors. It is requested that this test, in particular, be completed at least two weeks in advance of the MESA test completion date to allow the Image Display actors to test the display of each of these objects and to allow time for communication if there is a problem.

Instructions

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload your DICOM SRs and a screen capture snapshot of your Evidence Document(s) into gazelle under Connectathon -> List of samples. (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test. 7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

8. You may submit more than one set.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to display the contents of your objects. If they find issues in displaying the studies, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

Nuclear Medicine Tests

Modality Test 2201: NM Image Type (test 0008, 0008 Value 3)

Test 2201 examines the Value 3 in the Image Type attribute (0008, 0008) produced by NM modalities. Allowed image types are:

• STATIC
• WHOLEBODY
• DYNAMIC
• GATED
• TOMO
• RECON TOMO
• GATED TOMO
• RECON GATED TOMO

References

Rad TF-1: E.4.

Instructions

1. Produce one or more NM images with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

Evaluation

1. Run the evaluation script for test 2201:

   perl 2201/eval_2201.pl <log level> FILE1 [FILE2 ...]

2. The evaluation output is found in 2201/mir_mesa_2201.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Log level is a value from 1 to 4 (1 is low, 4 is more messages). When sending the evaluation output to the Project Manager, use a value of 3 or 4.

Modality Test 2202: NM Image IOD: Multi-Frames and Vectors

Test 2202 tests the relationship between Image Type (0008, 0008 value 3) and Frame Increment Pointers. For a specific Image Type, DICOM defines the frame increment pointers and the order of those pointers. In this test, a modality creates NM multi-frame images, and the test software examines the Frame Increment Pointers.

References

Rad TF-1: E.4.2.

Instructions

You can follow the steps for test 2201. You do not need to send new images. To run the evaluation script:

   perl  2202/2202_eval.pl -l <log level>

Evaluation

Supplemental Information

Send the evaluation log (2202/grade_2202.txt) to the Project Manager. Use a log level of 3 or 4 when you run the evaluation script.

Modality Test 2203: NM Image Required Attributes

Test 2202 tests the relationship between Image Type (0008, 0008 value 3) and required values as defined in Rad TF-2: Table 4.8-2.

References

Rad TF-2: 4.8.4.1.2.2

Instructions

You can follow the steps for test 2201. You do not need to send new images.

Evaluation

To run the evaluation script:

   perl  2203/2203_eval.pl -l <log level>

Send the evaluation log (2203/grade_2203.txt) to the Project Manager. Use a log level of 3 or 4 when you run the evaluation script.

Supplemental Information

Modality Test 2210: NM Modality STATIC

Test 2210 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2210 directory.

MESA Requirements This test requires baseline MESA software and the Image Magick binaries.

References

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one STATIC NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your STATIC image):

   perl  scripts/cine.pl loglevel FILE STATIC 2210/2210cineDisplay the gif file that results (use IE or another browser).

5. Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2210 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2211: NM Modality WHOLE BODY

Test 2211 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2211 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

References

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one 'WHOLE BODY' NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your WHOLE BODY image):

perl scripts/cine.pl loglevel FILE "WHOLE BODY" 2211/2211cine

5. Display the gif file that results (use IE or another browser). Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2211 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2212: NM Modality DYNAMIC

Test 2211 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2212 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

Reference

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one DYNAMIC NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your DYNAMIC image):

   perl  scripts/cine.pl loglevel FILE DYNAMIC 2212/2212cine

This will produce the file 2212/2212cine101.gif.

5. Display the gif file that results (use IE or another browser). Verify that the cine image matches the data produced by your system.

6. For the remaining steps, you are using the MESA tools to select a subset of the frames in your image to produce an animated display that would be reasonable to show to the end user. For example, one might fix values for Energy Window, Detector and Phase and let the time access vary.

7. For the next steps, you will need to pick single values for Energy Window, Detector and Phase for your dynamic image. The test software does not dictate what values are used for acquisition.

8. For the combinations of Energy Window, Detector and Phase, generate a Cine image using the tools as described below. You do not need to use all combinations of these values, but do generate a reasonable set of representative images. The output file name should indicate the imaging parameters, or should be mappable to the image parameters. Instruct the MESA system to produce a Cine image:

   perl scripts/cine_dynamic.pl loglevel FILE 2212/2212cine_001  EnergyWindow Detector Phase 0

For example, EnergyWindow = 1, Detector = 2, Phase = 1

   perl scripts/cine_dynamic.pl 3 FILE 2212/2212cine_A 1 2 1 0

This will produce the output file 2212/2212cine_A101.gif. You can repeat the process and produce output files with different names (B, C, …). It is also helpful to include an abbreviation for your company name in the file name.

9. Display the gif file that results (use IE or another browser). Verify that the image or images produced by selecting Energy Window match those produced by your system.

10. Create an archive of the 2212 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2213: NM Modality GATED

Test 2213 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2213 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

Reference

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one 'GATED' NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your GATED image):

   perl  scripts/cine.pl loglevel FILE "GATED" 2213/2213cine

5. Display the gif file that results (use IE or another browser). Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2213 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2214: NM Modality TOMO

Test 2214 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2214 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

Reference

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one 'TOMO' NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your GATED image):

perl scripts/cine.pl loglevel FILE "TOMO" 2213/2213cine

5. Display the gif file that results (use IE or another browser). Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2214 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2215: NM Modality GATED TOMO

Test 2215 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2215 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

Reference

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one 'GATED TOMO' NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your GATED image):

   perl  scripts/cine.pl loglevel FILE "GATED TOMO" 2213/2213cine

5. Display the gif file that results (use IE or another browser). Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2215 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2216: NM Modality RECON TOMO

Test 2216 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2216 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

Reference

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one 'RECON TOMO' NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your GATED image):

   perl  scripts/cine.pl loglevel FILE "RECON TOMO" 2216/2216cine

5. Display the gif file that results (use IE or another browser). Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2216 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2217: NM Modality RECON GATED TOMO

Test 2217 examines the frames produced by an Acquisition Modality to determine if they are displayable by Image Display actors. All output images are produced in the 2217 directory.

MESA Requirements

This test requires baseline MESA software and the Image Magick binaries.

Reference

Rad TF-2: 4.16.4.2.2.3

Instructions

1. Produce one 'RECON GATED TOMO' NM image with the proper image type in Value 3 of Image Type (0008 0008).

2. Create a DICOM Part 10 file or store in the MIR CTN format (IVRLE, no preamble, no group 0002).

3. Copy/ftp/carrier pigeon the file (or files) to the MESA box/computer.

4. Instruct the MESA system to produce a Cine image (of your GATED image):

perl scripts/cine.pl loglevel FILE "RECON GATED TOMO" 2217/2217cine

5. Display the gif file that results (use IE or another browser). Verify that the Static image matches the data produced by your system.

6. Create an archive of the 2217 directory (tar/zip) and submit to the Project Manager for evaluation.

Evaluation

Supplemental Information

Modality Test 2220: NM Modality STATIC/General/Attributes

Test 2220 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type STATIC in the General NMI catagory.

Reference

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a STATIC NM image. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system.

2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2220/eval_2220.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2220/eval_2220.pl loglevel filename

3. The evaluation output is found in 2220/mir_mesa_2220.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The STATIC image should have none of the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2. 2. There are no coded values to examine.

Modality Test 2221: NM Modality DYNAMIC/General/Attributes

Test 2221 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type DYNAMIC in the General NMI catagory.

Reference

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a DYNAMIC NM image, paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system.

2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2221/eval_2221.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2221/eval_2221.pl loglevel filename

3. The evaluation output is found in 2221/mir_mesa_2221.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The DYNAMIC image should have none of the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. There are no coded values to examine.

Modality Test 2223: NM Modality GATED/General/Attributes

Test 2223 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type DGATED in the General NMI catagory.

Reference

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a GATED NM image, paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system. 2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting the MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2223/eval_2223.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2223/eval_2223.pl loglevel filename

3. The evaluation output is found in 2223/mir_mesa_2223.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The GATED image should have none of the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. There are no coded values to examine.

Modality Test 2224: NM Modality TOMO/General/Attributes

Test 2224 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type TOMO in the General NMI catagory.

Reference

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a TOMO NM image (General category), paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system. 2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting the MESA Servers.
• Clear the MESA Image Manager:

    perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2224/eval_2224.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2224/eval_2224.pl loglevel filename

3. The evaluation output is found in 2224/mir_mesa_2224.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The TOMO image should have the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. There are no coded values to examine.

Modality Test 2225: NM Modality RECON TOMO/General/Attributes

Not available in this release.

Test 2225 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type RECON TOMO in the General NMI catagory.

Reference

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a RECON TOMO NM image (General category), paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system.

2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting the MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.plC-Store your image to the MESA Image Manager (AE Title: MESA, port 2350}

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2225/eval_2225.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2225/eval_2225.pl loglevel filename

3. The evaluation output is found in 2225/mir_mesa_2225.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The RECON TOMO image should have the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. There are no coded values to examine.

3. The evaluation script will note if 0028 0051 contains ATTN but will not flag an error. This is only required for attenuation data.

Modality Test 2230: NM Modality TOMO/Cardiac/Attributes

Test 2230 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type TOMO in the Cardiac NMI catagory.

References

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a TOMO NM image (Cardiac category), paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system. 2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting the MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3.Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2230/eval_2230.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2230/eval_2230.pl loglevel filename

3. The evaluation output is found in 2230/mir_mesa_2230.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The TOMO image should have the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. The Concept Name Code Sequence (0040 A043) shall contain (DCM, 109055, "Patient State")

3. Concept Code Sequence (0040 A168) shall use a value from the list in Table 4.8-2.2

Modality Test 2231: NM Modality RECON TOMO/Cardiac/Attributes

Test 2231 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type RECON TOMO in the Cardiac NMI catagory.

References

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a RECON TOMO NM image (Cardiac category), paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You must use one of the standard cardiac views: Short Axis, Vertical Long Axis, or Horizontal Long Axis. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system.

2.If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting the MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.plC-Store your image to the MESA Image Manager (AE Title: MESA, port 2350) 

• Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2231/eval_2231.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2231/eval_2231.pl loglevel filename

3. The evaluation output is found in 2231/mir_mesa_2231.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The RECON TOMO image should have the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. View Code Sequence (0054 0220) shall use a value from the list in Table 4.8-2.1

3. Slice Progress Direction (0054 0500) shall be APEX_TO_BASE or BASE_TO_APEX if the View Code Sequence indicates Short Axis views.

Modality Test 2232: NM Modality GATED TOMO/Cardiac/Attributes

Test 2232 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type GATED TOMO in the Cardiac NMI catagory.

References

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a GATED TOMO NM image (Cardiac category), paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system. 2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2232/eval_2232.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2232/eval_2232.pl loglevel filename

3. The evaluation output is found in 2232/mir_mesa_2232.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1. The TOMO image should have the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. The Concept Name Code Sequence (0040 A043) shall contain (DCM, 109055, "Patient State")

3. Concept Code Sequence (0040 A168) shall use a value from the list in Table 4.8-2.2

Modality Test 2233: NM Modality RECON GATED TOMO/Cardiac/Attributes

Test 2233 inspects NM images looking for the required tags referenced in Rad TF 2:4.8.4.1.2.2. In this test, the evaluation software examines one image that is of type RECON TOMO in the Cardiac NMI catagory.

References

Rad TF-2: 4.8.4.1.2.2

Instructions

1. Produce a RECON GATED TOMO NM image (Cardiac category), paying attention to the classification in Rad TF 2:4.8.4.1.2.2. You must use one of the standard cardiac views: Short Axis, Vertical Long Axis, or Horizontal Long Axis. You can either transmit the image to the MESA image manager (C-Store) or have the MESA software evaluate a file that you provide to the MESA system. 2. If you choose to transmit the image, follow these steps:

• Start the MESA servers as described in Starting the MESA Servers.
• Clear the MESA Image Manager:

   perl scripts/clear_img_mgr.pl

• C-Store your image to the MESA Image Manager (AE Title: MESA, port 2350)

3. Evaluate the image as described below.

Evaluation

1. If you C-Stored your NM image, evaluate as follows:

   perl 2233/eval_2233.pl loglevel

2. If you have a DICOM Part 10 file to evaluate, use this command:

   perl 2233/eval_2233.pl loglevel filename

3. The evaluation output is found in 2233/mir_mesa_2233.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

1.The RECON GATED TOMO image should have the tags listed in Rad TF 2: 4.8.4.1.2.2, Table 4.8-2.

2. View Code Sequence (0054 0220) shall use a value from the list in Table 4.8-2.1

3. Slice Progress Direction (0054 0500) shall be APEX_TO_BASE or BASE_TO_APEX if the View Code Sequence indicates Short Axis views.

Modality Test 2240: Example General NM images

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare those other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples 2-3 weeks before the usual test deadlines.

References

Instructions

A. Determine a representative set of non-cardiac images for your NM imaging modality that would help other actors understand your content. We do not expect you to generate images for every combination of parameters. Pick one set of parameters.

B. Place the images in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the images you produced as a reference. The goal is for an Image Display actor to examine your rendered images and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM files and a screen capture snapshot into gazelle under Connectathon -> List of samples.... (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

F. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in Starting the MESA Servers.

2. Make sure the worklist entries for step 211 have been created (see test 211).

2. Clear the MESA Image Manager.

   perl scripts/clear_img_mgr.pl

3. Locate the images stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files.

4. Upload DICOM files and a screen capture snapshot into gazelle under Connectathon / List of samples. Select your system name and Add a sample for test 2435.

5. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazaelle as results for this test.

6. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process

Evaluation

Supplemental Information

Modality Test 2435: Sample Cardiac NM Datasets

In this “test”, you use the MESA tools to collect images and then send those images to the Project Manager for distribution to other vendors. Please note the following:

• These image sets will be distributed to Image Display vendors which support the Cardiac NM Option in the Nuclear Medicine Image Profile. The Image Displays will ensure they are able to use MPR of two RECON TOMO short axis images to display them in the standard format approved by the American College of Cardiology (ACC NM Cardiac Display format). See Technical Framework references below .
• These are the images that may be used in a demonstration. That is, they should be of reasonable clinical quality
• These images MUST NOT contain real patient demographics.

References

Rad TF-1: Appendix E.5.2, E.5.2.1-3 Rad TF-2:4.16 Table 4.16-1 and 4.16.4.2.2.3.2

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager. From $MESA_TARGET/mesa_tests/rad/actors/mod:

    perl  scripts/clear_img_mgr.pl

3. Send the appropriate images to the MESA Image Manager. Refer to the Clinical Example 1b in Rad TF-1: Appendix R.5.3.2.

4. Locate the images stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload DICOM files and a screen capture snapshot into gazelle under Connectathon -> List of samples. (Note that when the DICOM objects are uploaded, this maytrigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Image Fusion (FUS) - Modality Tests

Modality Test 3512: Create and Store Spatial Registration

<this test is not yet implemented in the MESA tools>

This is an OPTIONAL test for Acquistion Modalities in the Image Fusion profile. If your Acquisition Modality supports Spatial Registration, you should run this test.

In this test, the Modality will create a Spatial Registration Object that spatially aligns two series of images it has acquired. These series may have the same or different Frames of Reference. This tests transaction [RAD-56] in the Image Fusion Profile and Storage Commitment [RAD-10].

References

Rad TF-1:20.4.2 Rad TF-3: 4.56 DICOM PS3.3 – 2004 A.30

Test description/steps for test 3512.

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. The steps below are run from the directory $MESA_TARGET/mesa_tests/rad/actors/mod.

3.

Evaluation

Evaluate the contents of your Spatial Registration IOD as follows:

   perl  3512/eval_3512.pl [-v]

If you need to send the Spatial Registration object a second time, you should clear the MESA Image Manager first. This will allow the evaluation software to examine your latest object.

   perl scripts/reset_servers.pl

Supplemental Information

Modality Test 3514: Create BSPS with Spatial Registration

<this test is not yet implemented in the MESA tools>

This is an OPTIONAL test for Acquistion Modalities in the Image Fusion profile, but if your Acquisition Modality supports Spatial Registration, you must run this test.

In this test, the Modality will create a Blended Softcopy Presentation State (BSPS) which references the Spatial Registration created in test 3512. objects must be stored during this test. Storage Commitment may be sent, but it will not be evaluated in this test.

Note: Test 5312 must be run before this one.

References

Rad TF-3: 4.57.4.1.2

Test description/steps for test 3514.

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. The steps below are run from the directory $MESA_TARGET/mesa_tests/rad/actors/mod.

Evaluation

Evaluate the contents of your BSPS IOD as follows:

   perl  3514/eval_3514.pl [-v]

If you need to send the BSPS and Spatial Registration objects a second time, you should clear the MESA Image Manager first. This will allow the evaluation software to examine your latest object.

   perl scripts/reset_servers.pl

Supplemental Information

Modality Test 3516: Modify Existing BSPS

<this test is not yet implemented in the MESA tools>

References

Instructions

Evaluation

Supplemental Information

Modality Test 3540: Create and Store BSPS IOD – same FoR

In the Image Fusion Profile, Acquistion Modalities which store two acquired images dataset with the same Frame of Reference are required to be able to create a BSPS for these dataset. In this test, the Modality will create a Blended Softcopy Presentation State (BSPS) object that specifies how to blend for display the two series of images it acquired. These series must have the same Frame of Reference. This tests transaction [RAD-57] in the Image Fusion Profile.

Note: The BSPS created in this test will be used again in the next test, 3541. It is possible that the images and BSPS used for this test are the same as you submit for test 551.

References

Rad TF-1: Table 20.1-1 Rad TF-1: 20.4.3 Rad TF-3: 4.57 DICOM PS3.3 – 2004 A.30

Instructions

Either create DICOM Part 10 files and submit to the Project Manager or follow the instructions below. 

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager (if necessary). From $MESA_TARGET/mesa_tests/rad/actors/mod:

   perl scripts/clear_img_mgr.pl

3. Send your images and BPSP object to the MESA Image Manager.

If you need to send the images and BSPS object a second time, you should clear the MESA Image Manager first.

   perl  scripts/reset_servers.pl

4. Tar or zip the files (images & BSPS) in $MESA_STORAGE/imgmgr/instances

5. If the file is small enough, you may upload it into the Connectathon webtool as results for this test. If the file is too large, send an email to the Project Manager stating that you are ready to submit results. Do not email the zipped objects. You will receive a response containing instructions for submitting your objects to an ftp site or sending in a CD.

Evaluation

1. There is no MESA evaluation script for this test. The contents of your BSPS object will be manually evaluated by a Project Manager.

Supplemental Information

Modality Test 3541: Modify Existing BSPS

In this test, the Modality will modify the Blended Softcopy Presentation State (BSPS) object created in test 3540. Test 3540 must be run before this one. The Modality will modify the transparency of the SUPERIMPOSED dataset and create a new BSPS instance. The Modality will C-STORE this new BSPS

References

Rad TF-3: 4.57.4.1.2

Instructions

1. The Acquisition Modality should locate the Blended Softcopy Presentation State created for test 3540.

2. Use your application to modify the transparency of the superimposed series.

3. Send the new DICOM BSPS object to the MESA Image Manager.

4.Start the MESA servers as described in Starting the MESA Servers.

5.Clear the MESA Image Manager (if necessary). From $MESA_TARGET/mesa_tests/rad/actors/mod:

   perl scripts/clear_img_mgr.pl

If you need to send the BSPS object a second time, you should clear the MESA Image Manager first.

   perl  scripts/reset_servers.pl
   

6. Tar or zip the file in $MESA_STORAGE/imgmgr/instances

7. Upload it into the Connectathon webtool as results for this test.

Evaluation

1. There is no MESA evaluation script for this test. The contents of your BSPS object will be manually evaluated by a Project Manager.

Supplemental Information

Modality Test 3620: FUS - Example Image, BSPS and Spatial Registration Objects

For the Connectathon, meaningful interoperability testing for the Image Fusion profile will rely largely on the quality of the data sets supplied by the Acquisition Modality vendors.

The goal of this “test” is to provide samples for other vendors to display. You should send a “representative sample” of the data produced by your system.

Blended Softcopy Presentation State (BSPS) and Spatial Registration objects are used in the Image Fusion Profile. Both Evidence Creator and Acquisition Modality actors may create and store BSPS and Spatial Registration objects. In addition to BSPS objects, you should also submit the datasets (images, Spatial Registrations) you reference within your BSPS object, even if you did not produce them. That will allow other actors to display the original images with the appropriate BSPS and Spatial Registration objects.

Each system should send samples of the Image , BSPS and Spatial Registration objects. If you create BSPS and/or Spatial Registration objects in the Image Fusion profile, you should also send along the image series the BSPS and Spatial Registration objects reference.

In order to facilitate their testing, please submit your samples 2-3 weeks before the usual test deadlines, and earlier if possible.

References

Instructions

Either create DICOM Part 10 files and submit them (see steps 5-7) or follow the instructions below.

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager (if necessary). From $MESA_TARGET/mesa_tests/rad/actors/mod:

   perl scripts/clear_img_mgr.pl

3. Send sample images/BSPS/Spatial Registration objects to the MESA Image Manager.

4. Tar or zip the files in $MESA_STORAGE/imgmgr/instances

5. Assuming you have this ability, render the study you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

6. Upload DICOM Part 10 file and the screen capture snapshot into gazelle under Connectathon -> List of samples.... Select your system name and Add a sample for test 3620. You are encouraged to submit multiple samples. (Note that when the DICOM objects are uploaded, this triggers and automatic DICOM validation service. You should take note of the output of the validation.)

7. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

8. As Image Display actors import your images, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

The evaluation of this test comes in the form of feedback from other users of your data. If other users identify issues with your data, you will be asked to work with those users (and Project Manager) to resolve those issues.

Supplemental Information

Mammography Image Integration Profile – Modality Tests

These test cases apply to Acquisition Modality actors in the Mammography Image Integration Profile.

Modality Test 3900: Full Field Digital Mammo image - “For Presentation” & "For Processing"

This test is for Acquisition Modalities in the Mammography Image Integration Profile. If your modality is a digitizer, you should run test 3905 instead.

This test case asks the Modality to:

• C-STORE TWO Full Fidelity Digital Mammography images – a pair of “For Presentation” and “For Processing” images – to the MESA Image Manager
• Note: Storage Commitment is tested elsewhere; MWL and MPPS are not required

This test verifies that the data attributes required by this profile are present and that defined codes and values are used, but it cannot check that the values in the required attributes are accurate. That exercise is left to vendors to test internally.

This tests attributes identified as R+ in RAD TF-2: 4.8.4.1.2.3. The RC+ attributes are tested in separate tests.

References

RAD TF-2:4.8.4.1.2.3

Instructions

To run this test, follow these steps:

1. Start the MESA servers as described in Starting the MESA Servers.

2. From the $MESA_TARGET/mesa_tests/rad/actors/mod directory, run the following script:

   perl scripts/mod_mammo.pl 3900 <log_level>

Evaluation

1. Run the evaluation script for test 3900:

   perl 3900/eval_3900.pl <log level>

2. The evaluation output is found in 3900/mir_mesa_3900.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool. Supplemental Information

You can repeat this test as many times as you like. You can send multiple images; the test will evaluate all images stored by the Image Manager.

Modality Test 3905: Digitizer Acq. Modality Mammography Images - Required Attributes

<this test is not yet implemented in the MESA tools>

This test is for digitizer Acquisition Modalities in the Mammography Image Integration Profile.

This test case asks the Modality to:

• C-STORE a “For Processing” image – to the MESA Image Manager
• Note: Storage Commitment is tested elsewhere; MWL and MPPS are not required

Digitzer Modalities must store images using the "Digital Mammography Image Storage - For Presenation" SOP Class (not Secondary Capture). This test verifies that the data attributes required by this profile for digitizers are present, but it cannot check that the values in the required attributes are accurate. That exercise is left to vendors to test internally.

This tests attributes identified as R+ in RAD TF-2: 4.8.4.1.2.3. The RC+ attributes are tested in separate tests.

References

RAD TF-2:4.8.4.1.2.3

Instructions

To run this test, follow these steps:

1. Start the MESA servers as described in Starting the MESA Servers.

2. From the $MESA_TARGET/mesa_tests/rad/actors/mod directory, run the following script:

   perl scripts/mod_mammo.pl 3905 <log_level>

Evaluation

1. Run the evaluation script for test 3905:

    perl 3905/eval_3905.pl <log level>

2. The evaluation output is found in 3905/mir_mesa_3905.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

You can repeat this test as many times as you like. You can send multiple images; the test will evaluate all images stored by the Image Manager.

Modality Test 3915: Partial View Option

This test only applies to Acquisition Modality actors which support the Partial View option in the Mammography profile.

The Image Display must create a set of images (a mosaic) for a breast that is larger than the detector. The following attributes define the partial view in each image in the set: - (0028,1350) Attribute Partial View - (0028,1352) Partial View Code Sequence

References

RAD TF-2:4.8.4.1.2.3.1

Instructions

To run this test, follow these steps:

1. Start the MESA servers as described in Starting the MESA Servers.

2. From the $MESA_TARGET/mesa_tests/rad/actors/mod directory, run the following script:

   perl scripts/mod_mammo.pl 3915 <log_level>

3. Create a mosaic set of “For Presentation” mammography images setting the partial view attributes. The Patient ID should be MESA3915. The patient name should be MESA^MammoPartialView. These values are not critical to the test.

4. Send the images to the MESA Image Manager.

Evaluation

1. Run the evaluation script for test 3915:

   perl 3915/eval_3915.pl <log level>

2. The evaluation output is found in 3905/mir_mesa_3905.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

You will send multiple images; the test will evaluate all images stored by the Image Manager.

Modality Test 3916: Sample Datasets

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

Instructions

A. Determine a complete, representative set of MAMMO images for your Acquisition Modality that would help other actors understand your content. Good samples make for meaningful tests between vendors.

• These datasets should be of reasonable clinical quality.
• You should send pairs of 'for processing' and 'for presentation' images. You may submit a full set of current and prior images. If you support the Partial View option, submit a sample set of these images.
• Note that your DICOM objects MUST NOT contain real patient demographics.
• Note that these datasets will be distributed to other vendors.

B. Place the image(s) in DICOM Part 10 files

C. Assuming you have this ability, render the image(s) you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot onto the IHE ftp site: ftp://ftp.ihe.net/Connectathon/samples/RAD-profiles/MAMMO_Samples/ under the subdirectory for your Connectathon. You may contact the Connectathon Project Manager for the username/password to the ftp site. (Note: Due to the size of the files, we do not ask you to upload your sample into gazelle under Connectathon -> List of samples...).

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

F. As Image Display and Image Manager actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

There is no evaluation for this test. Your partners will check for the objects you submitted.

MAWF Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the Mammography Acquisition Workflow Integration Profile.

Modality Test 4100: MAWF Vendor Interoperability - Recall

For the Connectathon, meaningful interoperability testing for the MAWF profile will rely largely on the quality of the data sets supplied by the Acquisition Modality vendors.

In this “test”, you create a sample data set for the Recall case that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Managers and Image Displays) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples 2-3 weeks before the usual test deadlines.

References

RAD TF-2:4.5.4.2.2.2

RAD TF-2:4.8.4.1.2

RAD TF-2:4.16.4.2.2.5

Instructions

A1. Create representative mammography study for your modality; include both FOR PRESENTATION and FOR PROCESSING images. Then we want you to simulate a "Recall" case and encode "Recall for patient symptoms/clinical findings" as the Reason for Requested Procedure. Consult the Technical Framework references above.

B. Place the images (original and recalled) in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the images you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot into gazelle under Connectathon -> List of samples.... You are encouraged to submit multiple samples. (Note that when the DICOM objects are uploaded, this triggers and automatic DICOM validation service. You should take note of the output of the validation.)

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as the results for this test.

F. As Image Display actors import your images, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload the objects into gazelle under Connectathon / List of samples

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into the gazelle as results for this test.

8. You may submit more than one sample.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

Modality Test 4102: MAWF Vendor Interoperability - View Correction

In this “test”, you create a sample data set for the View Correction case that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Displays) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples 2-3 weeks before the usual test deadlines.

References

RAD TF-2:4.8.4.1.2.4

RAD TF-2:4.66.4.2.2

Instructions

A1. Create representative mammography study for your modality with incorrect view encoded; include both FOR PROCESSING and FOR PRESENTATION images. Then we want you to simulate a "View Correction" case and create images which encode the correct view information -- consult the Technical Framework references above.

A2. Create a KOS with the title "Rejected for Patient Safety Reasons" which references the incorrect images.

B. Place the images (original and corrected) and the KOS in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the images you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot into gazelle under Connectathon -> List of samples.... Add a sample for test 4102. You are encouraged to submit multiple samples. (Note that when the DICOM objects are uploaded, this triggers and automatic DICOM validation service. You should take note of the output of the validation.)

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test. F. As Image Display actors import your images, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload the objects into gazelle under Connectathon -> List of samples.... Add a sample for test 4102.

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

8. You may submit more than one sample.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Supplemental Information

REM and REM-NM Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the Radiation Exposure Monitoring Integration Profile.

Modality Test 4400: REM Vendor Interoperability - Exchange Dose SR Samples

For the Connectathon, meaningful interoperability testing for the REM profile between Modalities and Dose Info Consumers, Reporters and Registers will rely largely on the quality of the data sets supplied by the Acquisition Modality vendors.

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Dose Info Consumer, Dose Info Reporter, Dose Register) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

Instructions

A. Determine a representative set of Dose SRs for your Acquisition Modality that would help other actors understand your content. Good samples make for meaningful tests between vendors. You may choose to submit the images associated with the Dose SR(s).

B. Place the SR(s)in DICOM Part 10 files

C. Assuming you have this ability, render the SR Content you produced as a reference. The goal is for a consumer of your SRs to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. * Upload DICOM Part 10 file and the screen capture snapshot into gazelle under Connectathon -> List of samples... On the Samples to share tab, upload your sample image(s) under the REM entry. You are encouraged to submit multiple samples.

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

F. As Dose Information Reporter, Dose Information Consumer and Dose Register actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Modality Test 4402: REM Profile -- Modality Type and Template Support

Instructions

There are no test steps to execute for this test. Instead, create a text file which specifies the type of DICOM images your modality creates and lists the DICOM Baseline Template your Acquisition Modality uses when creating Dose SRs for the REM profile.

CT modalitites which report on irradiation events shall be capable of producing an SR compliant with TID 10011.

Actors which support on irradiation events for Modalities of type XR, XA, RF, MG, CR, or DX shall be capable of producing an SR compliant with TID 10001.

Your test file should have the following naming convention: CompanyName_Product_4402.txt.

Submit the text file into the webtool as the results for test 4402.

References

RAD TF-3:4.62.4.1.2

Modality and RAS Test 4410: REM-NM Vendor Interoperability - Exchange Dose SR & Image Samples

For the Connectathon, meaningful interoperability testing for the REM-NM profile between Radiolpharmceutical Activity Suppliers (RAS) and Modalities as creators of DICOM objects, and Image Managers, Dose Info Consumers, Reporters, Registers as consumers of those objects, will rely largely on the quality of the data sets supplied by the RAS and Modality vendors.

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Dose Info Consumer, Dose Info Reporter, Dose Register) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

Instructions for RAS systems:

• Determine a representative set of Radiopharmaceutical Radiation Dose Structured Reports (RRDSR ) for your RAS that would help other actors understand your content. Good samples make for meaningful tests between vendors.

• Upload the DICOM SR(s) into gazelle under Connectathon -> List of samples... On the Samples to share tab, upload your sample under the REM-NM entry. You are encouraged to submit multiple samples.

• Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

• As Image Manager, Dose Information Reporter, Dose Information Consumer and Dose Register actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Instructions for Modality systems:

• Determine a representative set of images for your modality that would help other actors understand your content. In particular, we are looking for samples that demonstrate your ability to include dose information in your image objects per the requirements in RAD TF-2:4.8.4.1.2.5 for the REM-NM profile.

• Upload sample images into Gazelle under Connectathon -> List of Samples. On the Samples to share tab, upload your sample image(s) under the REM-NM entry.

• • Some image sets are too large to upload into gazelle. If you encounter this, please contact the Connectathon Technical Project Manager to for instructions on alternatives.

• Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as the result file for this test.

• You may submit more than one sample.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

PERF Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the CT/MR Perfusion Imaging with Contrast Integration Profile.

Modality Test 4550: PERF Vendor Interoperability - Exchange Enhanced CT and MR Image Samples

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

References

Instructions

A. Determine a representative set of Enhanced CT or Enhanced MR for your Acquisition Modality that would help other actors understand your content. Good samples make for meaningful tests between vendors.

B. Place the image(s)in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the image(s) you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot into gazelle under Connectathon -> List of samples.... . You are encouraged to submit multiple samples.

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle F. As Image Display and Image Manager actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files

5. Upload the objects into gazelle under Connectathon -> List of samples.... .

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

8. You may submit more than one sample.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Project Managers will also examine your objects for attributes required in RAD TF-2: 4.8.4.1.2.5.2.

Supplemental Information

DIFF Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the MR Diffusion Imaging Integration Profile.

Modality Test 4650: DIFF Vendor Interoperability - Exchange Enhanced MR Image Samples

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

References

Instructions

A. Determine a representative set of Enhanced MR images for your Acquisition Modality that would help other actors understand your content. Good samples make for meaningful tests between vendors.

B. Place the image(s)in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the image(s) you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot into gazelle under Connectathon -> List of samples.... You are encouraged to submit multiple samples.

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

F. As Image Display and Image Manager actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files

5. Upload the objects into gazelle under Connectathon -> List of samples.

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

8. You may submit more than one sample.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Project Managers will also examine your objects for attributes specified in RAD TF-2:4.8.4.1.2.5 and 4.8.4.1.2.5.1.

Supplemental Information

SMI Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the Stereotactic Mammography Image Profile.

Modality Test 4950: SMI Vendor Interoperability - Exchange Stereotactic Mammography Image Samples

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

References

RAD TF-2:4.8.4.1.2.X "Storage of Stereotactic Mammography Images" (in 2013, this section is in the SMI Trial Implementation Supplement).

Instructions

A. Determine a complete, representative set of Stereotactic Mammography image for your Acquisition Modality that would help other actors understand your content. Good samples make for meaningful tests between vendors. Your images must meet the requirements in attributes specified in RAD TF-2:4.8.4.1.2.X "Storage of Stereotactic Mammography Images" (in 2013, this section is in the SMI Trial Implementation Supplement). You must create a complete set including image types:

1. STEREO_SCOUT
2. STEREO_MINUS
3. STEREO_PLUS
4. PREFIRE_MINUS
5. PREFIRE_PLUS
6. POSTFIRE_MINUS
7. POSTFIRE_PLUS
8. POSTBIOPSY_MINUS
9. POSTBIOPSY_PLUS
10. POSTBIOPSY
11. POSTMARKER_MINUS
12. POSTMARKER_PLUS
13. POSTMARKER

B. Place the image(s) in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the image(s) you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot onto the IHE ftp site: ftp://ftp.ihe.net/Connectathon/samples/RAD-profiles/SMI_Samples/ under the subdirectory for your Connectathon. You may contact the Connectathon Project Manager for the username/password to the ftp site. (Note: Due to the size of the files, we do not ask you to upload your sample into gazelle under Connectathon -> List of samples...).

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

F. As Image Display and Image Manager actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Follow these steps if you need to use the MESA tools to create DICOM files

1. Start the MESA servers as described in MESA/Acquisition_Modality#Starting_the_MESA_Servers.

2. Clear the MESA Image Manager.

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files

5. Upload the objects into gazelle under Connectathon -> List of samples.

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

8. You may submit more than one sample.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Project Managers will also examine your objects for attributes specified in RAD TF-2:4.8.4.1.2.X "Storage of Stereotactic Mammography Images" (in 2013, this section is in the SMI Trial Implementation Supplement).

DBT Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the Digital Breast Tomosynthesis Profile.

Modality Test 5250: DBT Vendor Interoperability - Exchange Digital Breast Tomosynthesis Image Samples

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as early as possible in the pre-Connectathon period, at the latest 2-3 weeks before the usual test deadlines.

References

RAD TF-2:4.8.4.1.2.7 "Storage of Digital Breast Tomosynthesis Images" (in 2014, this section is in the DBT Trial Implementation Supplement).

Instructions

A. Determine a complete, representative set of DBT images for your Acquisition Modality that would help other actors understand your content. Good samples make for meaningful tests between vendors. Your Modality may create...

• Digital Mammogrpahy X-Ray Image Story - For Presentation and For Processing SOP Classes
• Breast Projection X-Ray Image For Presentation SOP Class

Your images must meet the requirements in attributes specified in RAD TF-2:4.8.4.1.2.7 "Storage of Digital Breast Tomosynthesis Images" (in 2014, this section is in the DBT Trial Implementation Supplement). You must create a complete set including image types:

B. Place the image(s) in DICOM Part 10 files using your own tools or follow the numbered instructions below.

C. Assuming you have this ability, render the image(s) you produced as a reference. The goal is for a consumer of your images to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

D. Upload DICOM Part 10 file and the screen capture snapshot onto the IHE ftp site: ftp://ftp.ihe.net/Connectathon/samples/RAD-profiles/DBT_samples/ under the subdirectory for your Connectathon. You may contact the Connectathon Project Manager for the username/password to the ftp site. (Note: Due to the size of the files, we do not ask you to upload your sample into gazelle under Connectathon -> List of samples...).

E. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

F. As Image Display and Image Manager actors import your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

The evaluation of this test comes in the form of feedback from vendors who try to import/process/display the contents of your objects. If they find issues, you will be asked to work with those vendors (and the Project Manager) to resolve those issues

Project Managers will also examine your objects for attributes specified in RAD TF-2:4.8.4.1.2.7 "Storage of Digital Breast Tomosynthesis Images" (in 2014, this section is in the SMI Trial Implementation Supplement).

Cardiology Echo Modality Tests

Modality Test 20403: Stress Echo Option

This test is for Acquisition Modalities which have implemented the Stress Echo Option of the Echocardiography Workflow. In this test, you use the MESA tools to collect images and then send those images to the Project Manager to manually verify the DICOM headers and verify the Stress Echo data attributes. Please see the CARD TF-2:4.2.3 of the Cardiology Technical Framework for the attribute definitions. This test verifies that the data attributes are present and that defined codes and values are used, but cannot check that the defined attributes are accurate (ie., that a “Parasternal short axis at the aortic valve level” is in fact what was imaged). That exercise is left to the vendors to test internally.

References

CARD TF-2:4.2.3

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager (if necessary). From $MESA_TARGET/mesa_tests/card/actors/mod:

    perl scripts/clear_img_mgr.pl

3. Use any patient demographics desired.

4. Locate the images stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files and send them to the Project Manager.

Evaluation

Supplemental Information

Modality Test 20404: Echo Image Sets

In this “test”, you use the MESA tools to collect images and then send those images to the Project Manager for distribution to other vendors. Please note the following:

• These are the images that may be used in the demonstration. That is, they should be of reasonable clinical quality.
• These images MUST NOT contain real patient demographics.
• These image sets will be distributed to other vendors.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers. 2. Clear the MESA Image Manager. From $MESA_TARGET/mesa_tests/card/actors/mod:

   perl  scripts/clear_img_mgr.pl

3. Send the appropriate images to the MESA Image Manager.

4. Locate the images stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files.

5. If the file is small enough, you may upload it into the Connectathon webtool as results for this test. If the file is too large, send an email to the Project Manager stating that you are ready to submit results. Do not email the zipped objects. You will receive a response containing instructions for submitting your objects to an ftp site or sending in a CD.

6. Repeat this test for EVERY SOP class which your product supports from the SOP class table in CARD TF-2:4.2.2 (Table 4.2-5. Echocardiography SOP Classes).

Evaluation

Supplemental Information

Note that if the Stress Echo Option of CARD-2 is supported that the attribtues identified in CARD-2 must be included.

Cardiology Cath Modality Tests

Modality Test 20405: Cath Image Set

In this “test”, you use the MESA tools to collect images and then send share those samples with other vendors. Please note the following:

• These images should be of reasonable clinical quality.
• These images MUST NOT contain real patient demographics.
• These image sets will be distributed to other vendors.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager. From $MESA_TARGET/mesa_tests/card/actors/mod:

   perl  scripts/clear_img_mgr.pl

3. Send the appropriate images to the MESA Image Manager.

4. Locate the images stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances. Tar or zip these files.

5. Upload sample objects and the screen capture snapshot into gazelle under Connectathon-->List of samples. Select your system name and add objects uhder 'Sample to share'. (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

5a. If the file is too large, send an email to the Project Manager stating that you are ready to submit results. Do not email the zipped objects. You will receive a response containing instructions for submitting your objects to an ftp site or sending in a CD.

6. Repeat this test for EVERY SOP class which your product supports from the SOP class table in CARD-TF 2:4.2.1 (Table 4.2-1. Cardiac Cath SOP Classes).

Evaluation

Supplemental Information

STRESS Profile - Modality Tests

The tests in this section are required for Acquisition Modality actors in the Stress Testing Workflow Integration Profile.

Modality Test 20700: SOP Class Support

Instructions

There are no test steps to execute for this test. Instead, create a text file which lists all of the SOP classes which your Acquisition Modality is capable of creating within the Stress ECG, Stress Echo or Nuclear Medicine options in the STRESS profile. Your file should have the following naming convention: CompanyName_Product_20700_Mod_2007.

Submit the text file to the Technical Project Manager as the results for this test..

Modality Test 20710: 12-Lead ECG attribute evaluation - Stress ECG Option

This test is for Acquisition Modalities which have implemented the Stress ECG Option of the Stress Testing Workflow Integration Profile (STRESS) and are capable of sending DICOM 12-LEAD ECG Waveform objects.

This tests the Stress workflow - you will be asked to query for MWL and use the MESA tools to collect DICOM 12-Lead ECG Waveform objects. This test verifies that the Patient ID and Study Instance UID from the MWL is encoded. The Waveform objects will be also evaluated for attributes required for the [CARD-2] transaction when the Stress ECG option is supported . This test verifies that the attributes are present and that defined codes and values are used, but cannot check that the defined attributes are accurate (ie., that a given waveform was acquired using the Pharmacologic protocol, or during the Resting state). That exercise is left to the vendors to test internally.

MPPS and Storage Commitment messages may be sent, but are not evaluated in this test.

References

CARD TF-2:4.2 and CARD TF-2: Appendix X

Instructions

1. Start the MESA servers as described in the Starting the MESA Servers section.

2. From the $MESA_TARGET/mesa_tests/card/actors/mod directory, run the following script:

   perl scripts/mod_stress.pl 20710 <log_level>

3. Query for Worklist for Patient ID 20710 (patient ANNA^A)

4.Select the worklist item and acquire four waveform objects for the following patient states (the protocol used is not mandated by this test): - One Resting State ECG - One Baseline State ECG - One Exercise State ECG - One Post-exercise State ECG

5. C-STORE the 4 objects to the MESA Image Manager.

Evaluation

To evaluate this test run:

   perl 20710/eval_20710.pl <log_level> <Mod AE title>

Supplemental Information

Modality Test 20712: General ECG attribute evaluation - Stress ECG Option

Note: The steps in this test are identical to 20710, except General ECG waveform IODs are gathered, rather than 12-Lead ECGs.

This test is for Acquisition Modalities which have implemented the Stress ECG Option of the Stress Testing Workflow Integration Profile (STRESS) and are capable of sending DICOM General ECG Waveform objects.

This tests the Stress workflow - you will be asked to query for MWL and use the MESA tools to collect DICOM 12-Lead ECG Waveform objects. This test verifies that the Patient ID and Study Instance UID from the MWL is encoded. The Wavform objects will be also evaluated for attributes required for the [CARD-2] transaction when the Stress ECG option is supported . This test verifies that the attributes are present and that defined codes and values are used, but cannot check that the defined attributes are accurate (ie., that a given waveform was acquired using the Pharmacologic protocol, or during the Resting state). That exercise is left to the vendors to test internally.

MPPS and Storage Commitment messages may be sent, but are not evaluated in this test.

References

Card TF-2:4.2 and RAD TF-2: Appendix X

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. From the $MESA_TARGET/mesa_tests/card/actors/mod directory, run the following script:

   perl scripts/mod_stress.pl 20712 <log_level>

3. Query for Worklist for Patient ID 20712 (patient FLORA^F).

4. Select the worklist item and acquire four waveform objects for the following patient states (the protocol used is not mandated by this test): - One Resting State ECG - One Baseline State ECG - One Exercise State ECG - One Post-exercise State ECG

5. C-STORE the 4 objects to the MESA Image Manager.

Evaluation

To evaluate this test run:

   perl 20712/eval_20712.pl <log level> <Mod AE title>

Supplemental Information

Modality Test 20740: Sample Datasets

In this “test”, you use the MESA tools to collect images and then send those images to the Project Manager for distribution to other vendors. Please note the following:

• These are datasets that may be used in a demonstration. That is, they should be of reasonable clinical quality.
• You should send at least one example for each of the SOP classes you listed in 20700. You may submit more than one.
• Note that your DICOM objects MUST NOT contain real patient demographics.
• If the Stress Echo Option is supported, the attributes identified in [CARD-2] must be included for 12-Lead and General ECG Waveform objects.
• Note that these datasets will be distributed to other vendors.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager. From $MESA_TARGET/mesa_tests/card/actors/mod:

   perl  scripts/clear_img_mgr.pl

3. C-STORE DICOM objects to the MESA Image Manager.

4. Locate the DICOM objects stored by the MESA Image Manager. These are in $MESA_STORAGE/imgmgr/instances.

5. Upload your DICOM SRs and a screen capture snapshot of your Evidence Document(s) into gazelle under Connectathon -> List of samples.... (Note that when the DICOM objects are uploaded, this may trigger an automatic DICOM validation service. You should take note of the output of the validation.)

6. Create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as results for this test.

7. As Image Display actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

8. Repeat this test for EVERY SOP class which your product supports from the SOP class table in CARD TF-2:4.2.6 (Table 4.2-5 Stress ECG SOP Classes).

Evaluation

There is no evaluation for this test. The Project Manager will check for the object you submitted.

Supplemental Information

Eye Care Workflow - Modality Tests

Modality Test 281: Example Images and other DICOM objects

In this “test”, you create a sample data set that will be reviewed by other participants. The goal of this test is to prepare those other actors (Image Manager, Image Display) so they are not surprised during Connectathon events. In order to facilitate their testing, please submit your samples as scheduled for your connectathon, ie before the usual test deadlines.

Instructions

• Determine a representative set of images for your imaging modality or AMI that would help other actors understand your content. We do not expect you to generate images for every combination of parameters; pick one set of parameters. However, if your system supports more than one SOP class, or can use more than one transfer system, we expect you to upload representative samples for each.

• Assuming you have this ability, render the images you produced as a reference. The goal is for an Image Display actor to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.

• Upload sample objects and the screen capture snapshots onto ftp.aao.org. Contact the connectathon manager to obtain the username/password.

• Next, create a short txt file indicating you have completed the upload step. Upload that txt file into gazelle as the result file for this test.

• As Image Display actors render your data or Image Managers store your data, you may receive a request for interpretation or directives from the Connectathon Technical Project Manager to repair attributes. This may prove to be an iterative process.

• You may submit more than one set.

Evaluation

There is no specific evaluation for this test. Feedback comes as your partner Image Display and Image Manager partners test with your images in their lab.

Modality Test 50201: Eye Care Modality Unscheduled Case

Unscheduled cases imply that there is no Modality Worklist available to the Modality. In this test, you should produce a study according to the table below. The following table lists the patient demographics. Because this is an unscheduled case, your Modality will provide the Study Instance UID.

Test	Description	Requested Procedure	SPS / Protocol Code Items	PPS / Protocol Code Items
201	Simple Case	None	None	X1 / EYE_PC_200

Attribute	Value
Patient Name	KINGSTON^FRED
Patient ID	50201
Patient DOB	19980704
Patient Sex	M

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

3. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

If you need to rerun these tests, you can start again at step 2.

Evaluation

1. Compare your results to expected results:

   perl 50201/eval_50201.pl [output level]  <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 50201/mir_mesa_50201.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Evaluation

Supplemental Information

Modality Test 50202: Eye Care Modality Simple Case, One SPS

This test is for one Requested Procedure (EYE-200) leading to one Scheduled Procedure Step with one Protocol Item (EYE_PC_200). The modality is expected to perform one Performed Procedure Step as scheduled. Producing the Performed Protocol Code Sequence in the MPPS data is required if the modality supports the “Assisted Acquisition Protocol Setting” option. If the modality supports that option, set the “Protocol Flag” to “1” in step 6 below. Otherwise, set the value to 0.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

3. Obtain the MWL entry for the patient: FISHKILL^F. This entry should have one Scheduled Procedure Step with one Protocol Code Item: EYE_PC_200.

4. Perform the one procedure as defined in the MWL.

5. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

6. If you need to rerun these tests, you can start again at step 2.

Evaluation

1. Compare your results to expected results:

   perl  50202/eval_50202.pl <output level> <AE Title MPPS SCU> <Protocol Flag> [Japanese]]

where <AE Title MPPS SCU> is the Application Entity title of your modality, <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output), and <Protocol Flag> is 0 or 1. Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 50202/mir_mesa_50202.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Note: You might want to read the instructions for Modality Test 281 and extract the images required for that test. After this test has been completed, you could skip most of the steps in Test 281 and just harvest the images produced in this test.

Modality Test 50215: Eye Care Modality, Perform Different Procedure

In this test, the MWL entry is for Requested Procedure EYE-200 with Protocol Item EYE_PC_200. At the modality, we decide to perform procedure EYE-201 with Protocol Item EYE_PC_201. Procedure EYE-200 is not performed.

References

Instructions

1. Start the MESA servers as described in Starting the MESA Servers.

2. Clear the MESA Image Manager (if necessary)

   perl scripts/clear_img_mgr.pl

3. Obtain the MWL entry for the patient: BUFFALO^B. This entry should have one Scheduled Procedure Step with a single Protocol Item.

4. Perform procedure EYE-200 with Protocol Item EYE_PC_201 rather than the scheduled EYE-200.

5. Send your MPPS events, images and Storage Commitment requests to the MESA Image Manager. The MESA Image Manager does not automatically send Storage Commitment N-Event reports. To trigger these reports:

   perl  scripts/send_storage_commit_nevents.pl

If you need to rerun these tests, you can start again at step 2.

Evaluation

1. Compare your results to expected results:

   perl 50215/eval_50215.pl <output  level> <AE Title MPPS SCU> [Japanese]

where <AE Title MPPS SCU> is the Application Entity title of your modality, and <output level> is a value from 1 to 4 indicating the amount of output to log (1 = errors only, 4 = full output). Follow with the optional keyword Japanese if using that version of the software.

2. The evaluation output is found in 50215/mir_mesa_50215.xml. The final result should indicate 0 errors. Submit the result run at log level 4 to the Project Manager. For pre-Connectathon tests, this normally means uploading the XML file into the Kudu or Gazelle tool.

Supplemental Information

Modality/Evidence Creator Test 50216: ECED Example Document

In this “test”, you provide some Eye Care Evidence Document (ECED) samples for review by other vendors.

References

Instructions

1. Create one or more sample ECED objects. Store these in DICOM Part 10 format.
2. You can create a DICOM Part 10 CD with a DICOMDIR file or just create DICOM Part 10 files without the DICOMDIR. If you need help creating DICOM Part 10 files, contact the Connectathon Manager.
3. Create a short .txt file that describes the data you have created. You do not need to write a book, but something to help the other systems.
4. If you can, provide a sample rendering of the document as a JPEG or HTML file.
5. Place the DICOM Part 10 files, text description and sample rendering in a zip file. Name the zip file SYSTEM_NAME_50216.zip where SYTEM_NAME refers to the name assigned to your system in the Kudu or Gazelle tool. It is not your company product name.
6. Upload this file onto ftp://ftp.aao.org. Find the 'Connectathon_2008_samples' folder and upload your sample, along with the screen shots into the folder for Test 50216
7. Go to the Kudu/Gazelle tool and enter a note indicating you have uploaded your sample.
8. As other actors render your data, you may receive a request for interpretation or directives from the Project Manager to repair attributes. This may prove to be an iterative process.

Evaluation

Evaluation is provided by other systems as they render your samples.

Supplemental Information