MESA/Secure Node

From IHEWiki

Jump to: navigation, search

Secure App/Secure Node Test Software

Contents


[edit]

Secure Node Tests

[edit]

Integration Profiles and Test Procedures

IHE Secure Nodes combine one or more IHE actors with secure communications. Secure communications implies the following:

  • The Secure Node uses and requires authentication of network operations using TLS
  • The Secure Node sends audit records to the Audit Record Repository

For the purposes of this document, we will classify nodes as clients or servers. A client is one that initiates a network connection; a server listens for and accepts a network connection. Many systems may operate as both a client and as a server. This term is not used in the IHE Technical Framework.

This document will describe tests for both client and server applications.

[edit]

Introduction

Each test is run using the same procedure. 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/iti/actors/secure_node. Make sure the $MESA_TARGET and $MESA_STORAGE environment variables are set properly.

[edit]

Integration Profiles and Test Procedures

This document lists a number of tests for Secure Node Systems. You may not be responsible for all of these tests.

Please refer to the Connectathon web tool to list the required tests for your system. The web address of this tool depends on the year and project manager. Please contact the appropriate project manager to obtain this information.

[edit]

Message Attributes

This section is applicable for other actors and other tests. Expect that all fields of X.509 certificates and IHE Audit (syslog) messages are subject to evaluation.


[edit]

Message Values

This section is applicable for other actors and other tests.


[edit]

Configuration

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

The table below gives parameters for MESA servers that will receive messages from your system.

Application Certificate Port
MESA Syslog Server NA 4000 (UDP)
TLS TCP Server Self signed 4100
TLS TCP Server Self signed, unregistered 4101
TLS TCP Server Self signed, expired 4102
Order Placer (HL7 V2 MLLP) CA signed 2101
Order Filler (HL7 V2 MLLP) CA signed 2201
Order Filler (DICOM MWL) CA signed 2251
Patient Demographics Supplier (HL7 V2 MLLP, PDQ queries) CA signed 3701
Patient ID Cross Reference Manager (HL7 V2 MLLP, ITI-8, PIX Query) CA signed 3601


Read the Runtime Notes section of the Installation Guide to determine the proper settings for the MESA runtime environment.

[edit]

Starting the MESA Servers

MESA servers are started from a DOS/CMD window or a terminal emulator. Follow these steps:

  1. Unix, unsigned certificates
    1. cd $MESA_TARGET/mesa_tests/iti/actors/secure_node
    2. scripts/start_mesa_servers.csh [loglevel]
  2. Unix, signed certificates
    1. cd $MESA_TARGET/mesa_tests/iti/actors/secure_node
    2. scripts/start_ca_signed.csh
  3. Windows, unsigned certificates
    1. cd %MESA_TARGET%\mesa_tests\iti\actors\secure_node
    2. scripts\start_mesa_servers.bat [loglevel]
  4. Windows, signed certificates
    1. cd %MESA_TARGET%\mesa_tests\iti\actors\secure_node
    2. scripts\start_ca_signed.bat [loglevel]

To stop the servers:

  • Unix, unsigned certificates: scripts/stop_mesa_servers.csh [loglevel]
  • Unix, signed certificates: scripts/stop_ca_signed.csh [loglevel]
  • Windows, unsigned certificates: scripts\stop_mesa_servers.bat [loglevel]
  • Windows, signed certificates: scripts\stop_ca_signed.bat [loglevel]

Log files are stored in $MESA_TARGET/logs.

[edit]

External Audit Record Repositories

[edit]

This does not apply for the 2006-2007 cycle. Reliable syslog has been placed on hold.

The MESA tools are shipped with an Audit Record Repository that supports the BSD Syslog protocol (UDP). Reliable Syslog is handled using products from different systems. This release of the software relies on a Knoppix CD made available by HIPAAT, Inc. To send audit messages using the Reliable Syslog protocol, you will need to download the ISO image of the Knoppix CD or request a CD from the Project Manager.

There is a separate document from HIPAAT that describes how to start/run the CD. The CD is shipped assuming you will use DHCP to obtain an IP address. You can modify the network setup to give the PC a fixed IP address.

[edit]

Self-signed Digital Certificates

Some MESA tests use self-signed digital certificates.

Self-signed digital certificates for testing are located in the directory $MESA_TARGET/runtime/certificates. Included in the directory are pairs of files for the private key and public certificate. This is not a secure way to distribute these, but the goal is to work on the technology of certificates.

Your system should use the private key and certificate found in the files starting with test_sys_1. Import these into your system using whatever configuration is necessary.

The MESA client and server applications will use certificates found in the file mesa_list.cert. Use this as the list of all certificates that MESA may use when communicating with your system.

Do not use your own certificates for these tests or try to configure the MESA tools with different certificates. If there are issues with the certificates, please log a bug report.

[edit]

CA-Signed Digital Certificates

Some MESA tests use certificates signed by a CA. In these tests, you will need to configure your system with the private4 key/certificate for your system and the public certifidcate of the CA. You will only need the CA certificate when accepting MESA certificates. This is testing the case where you do not receive a copy of the peer certificate in advance. You do have the certificate of the CA, and you rely on the CA signature to validate the peer certificate.

For NA 2010, signed certificates have been issued for all systems. You can use that signed certificate for your system or the private key/certificate found in $MESA_TARGET/runtime/certs-ca-signed/test_sys_1.....pem. The public certificate for the CA is $MESA_TARGET/runtime/certs-ca-signed/cacert.pem.

[edit]

Basic Secure Node (Client or Server)

Each section below describes one test that is appropriate for a Secure Node in the Basic Security Integration Profile that is configured as either a client node or a server node. Later sections will list tests that are specific to client operations or server operations.

[edit]

Test Instructions: 120x Tests

Each test is independent of the others. You must collect the results of one test before starting a new test. You do not have to run the tests in the order listed. Each of the tests in the 120x section are designed for the IHE Radiology Basic Security Profile. This uses the provisional schema and UDP messaging to the MESA Audit Record Repository.

Enter the Secure Node directory: mesa_tests/rad/actors/secure_node. Remember the MESA servers were started according to the directions in section 1.5.

Follow the test instructions for each test found in the next sections of this document.

[edit]

1200: SEC List Audit Messages

This is a documentation procedure where you list all of the audit messages that your system is required to produce. The purpose of the test is for you to provide that list to the Project Manager so that the manager can determine if your system is producing the proper set of messages. This test result is due 3 weeks in advance of the normal test deadlines. This will give you time to recover in the event that you are missing audit events required of your system.

Create a text file named: grade_1200.txt. Content of the file should be as listed below.

  • Line 1: Company Name
  • Line 2: System Name
  • Line 3 and following: List of all Integration Profile/Actor combinations for this system.

Following lines: List all audit events for which your system produces an audit message. Submit the text file to the Project Manager for evaluation.

[edit]

1201: Actor Start

This sequence tests your ability to send an audit record to the MESA Audit Record Repository. This test covers the basic functionality of transmitting the message and the proper XML format of the message. The Actor Start message is chosen as that is required of all actors and is independent of other IHE transactions. This can be run using the IETF or INTERIM audit record format.

If not already done, start the MESA servers according to the directions in section 1.5.

By whatever means you use, “start” your actor such that it generates the actor-start-stop audit record message. This should be sent to the MESA Audit Record Repository.

Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Actor-start-stop and it should verify the content of that record against the IHE XML schema: 

   perl 1201/eval_client_1201.pl <log> <INTERIM or IETF>

<log> is a log level (1 – 4). The results file 1201/grade_client_1201.txt) should show 0 failures.

Run the evaluation at log level 4 and submit the test results to the Project Manager.


[edit]

1202: System Configuration

This sequence tests your ability to send an audit record to the MESA Audit Record Repository. This test covers the basic functionality of transmitting the message and the proper XML format of the message. The Actor-config message is chosen.

If not already done, start the MESA servers according to the directions in section 1.5.

By whatever means you use, configure or reconfigure your actor such that it generates the IHE Actor-config audit record message. This should be sent to the MESA Audit Record Repository. For example, you might change the host name.

Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Actor-config and it should verify the content of that record against the IHE XML schema: 

   perl 1202/eval_client_1202.pl

The results file (1202/grade_client_1202.txt) should show 0 failures.

Submit the test results to the Project Manager.


[edit]

1203: User Authenticated

This sequence tests your ability to send an audit record to the MESA Audit Record Repository. This test covers the basic functionality of transmitting the message and the proper XML format of the message. The User-Authenticated message is chosen.

If not already done, start the MESA servers according to the directions in section 1.5.

By whatever means you use, configure or reconfigure your actor such that it generates the IHE User-Authenticated audit record message. This should be sent to the MESA Audit Record Repository. For example, you might change the host name.

Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Actor-config and it should verify the content of that record against the IHE XML schema: 

    perl 1203/eval_client_1203.pl

The results file (1203/grade_client_1203.txt) should show 0 failures.

Submit the test results to the Project Manager.


[edit]

1205: Unspecified Records

Tests 1201 through 1204 cover specific events that defined by the MESA documentation. For test 1205, the system under test is asked to send three or more Audit Record messages to the MESA Audit Record Repository. These messages are evaluated by the MESA software, and the user collects the messages and sends them to the Project Manager for distribution to other systems.

You are welcome to use the events that are specified for tests 1201 through 1204. You might want to use other events so that your software is more fully tested.

If not already done, start the MESA servers according to the directions in section 1.5.

By whatever means you use, configure or reconfigure your actor such that it generates the IHE User-Authenticated audit record message. This should be sent to the MESA Audit Record Repository. For example, you might change the host name.

Clear the MESA Audit Record Repository of existing messages: 

   perl scripts/clear_db.pl

Generate three (3) or more Audit Record messages and send these to the MESA Audit Record Repository.

Run the evaluation script to examine all audit records sent during this test: 

   perl 1205/eval_client_1205.pl

   perl 1203/eval_client_1203.pl

Collect all of the files (tar/zip) in $MESA_TARGET/logs/syslog and submit these to the Project Manager.


[edit]

1211: Time Synchronization

Refer to the tests for Consistent Time/Time Client

[edit]

Secure Client Node Tests

Each section below lists one test for a Secure Client Node. The test authors define a Secure Node Client as a client system in the traditional client/server model where the client initiates a network connection. These tests in this section assume the Secure Node is initiating such a connection.


[edit]

1221: Client Certificate Exchange with Valid Certificate

In this test, your client application requests a network connection with a MESA server using the standard X.509 (unexpired) certificates. The MESA server will complete the TLS handshake, read data from the socket and then disconnect after 2 seconds. Therefore, this test demonstrates your ability to implement the basic TLS handshake with the cyphersuite:

TLS_RSA_WITH_NULL_SHA

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Start one MESA tls_server executable that uses a valid certificate. This will print certificate and debug information to the terminal emulator:

  • scripts/start_registered.csh
  • scripts\start_registered.bat

3. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

4. Open a network connection with the MESA TLS server listening at port 4100. We assume this means you have to initiate an IHE transaction; this transaction will fail because the MESA TLS server does not respond beyond the TLS handshake.

5. After the TLS handshake and aborted message sequence, you will see debug and other information printed by the tls_server. That should indicate a successful connection. Perform a screen capture or direct the server to send the output to a text file.

6. Create a file named SYSTEM_1221.xxx (txt, bmp, jpg) that shows evidence you have completed this test. Submit this file to the Project Manager (kudu or gazelle tool).

[edit]

1222: Client Certificate Exchange with Unregistered Certificate

In this test, your client application requests a network connection with a MESA server using the standard X.509 certificates. The MESA server will attempt the TLS handshake by offering an unregistered certificate. You are expected to abort the network connection and log an audit record message with the MESA Audit Record Repository (at port 4000 on the MESA system).

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Start one MESA tls_server executable that uses an unregistered certificate. This will print certificate and debug information to the terminal emulator:

  • scripts/start_unregistered.csh
  • scripts\start_unregistered.bat

3. (Optional) Clear the log files of prior messages. You will need a separate terminal emulator for this. The server started in step 2 runs in the foreground. 

   perl scripts/clear_logs.pl

4. Open a network connection with the MESA TLS server listening at port 4101. We assume this means you have to initiate an IHE transaction; the server will attempt the TLS handshake with an unregistered certificate.

5. After the TLS handshake and aborted message sequence, examine the output from the tls_server. It is printed to the terminal emulator you used to start the server. This should indicate a connection attempt from your system and an aborted connection.

6. Copy the output of the tls_server that shows evidence you attempted the connection and submit that as part of the evaluation (submit file to Kudu / Gazelle tool).

7. Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Node-Authentication failure and it should verify the content of that record against the IHE XML schema: 

   perl 1222/eval_client_1222.pl  IETF (or)
 
   perl 1222/eval_client_1222.pl  INTERIM

8. The results file 1222/grade_client_1222.txt should show 0 failures.

9. Submit the grade file to the Project Manager (Kudu/Gazelle tool).

[edit]

1223: Client Certificate Exchange with Expired Certificate

In this test, your client application requests a network connection with a MESA server using the standard X.509 certificates. The MESA server will attempt the TLS handshake by offering an unregistered certificate. You are expected to abort the network connection and log an audit record message with the MESA Audit Record Repository (at port 4000 on the MESA system).

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Start one MESA tls_server executable that uses an expired certificate. This will print certificate and debug information to the terminal emulator:

  • scripts/start_expired.csh
  • scripts\start_expired.bat

3. (Optional) Clear the log files of prior messages. You will need a separate terminal emulator for the step. The tls_server started in step 2 runs in the foreground. 

   perl scripts/clear_logs.pl

4. Open a network connection with the MESA TLS server listening at port 4102. We assume this means you have to initiate an IHE transaction; the server will attempt the TLS handshake with an expired certificate.

5. After the TLS handshake and aborted message sequence, examine the output sent by the tls_server to the terminal emulator. This should show the connection request. Capture the output (screen capture, direct the output to a text file) and submit that output to the Kudu/Gazelle tool as evidence that you made a connection.

6. Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Node-Authentication failure and it should verify the content of that record against the IHE XML schema: 

   perl 1223/eval_client_1223.pl IETF (or)

   perl 1223/eval_client_1223.pl INTERIM

7. The results file 1223/grade_client_1223.txt should show 0 failures.

8. Submit the grade file to the Project Manager.

[edit]

1224: Client TLS Handshake for 3DES

Do not run this test for the 2006-2007 cycle


[edit]

1226: DICOM Verification with TLS

This test is for DICOM client applications that are lacking a fully integrated MESA test sending data with TLS. In this test, your actor establishes a TLS connection with a MESA server and sends a DICOM C-Echo command (Verification class). If your actor has a fully integrated MESA test that exercises TLS and DICOM, you can skip this test.

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

4. Establish a DICOM/TLS connection with the MESA server running on port 2350. DICOM AE titles are ignored. Send a C-Echo request to that server.

5. This should run to completion with no errors. If you encounter an error, you will need to correct the communication problem and rerun the test.

6. When you have successfully completed the C-Echo request, there will be log information stored in the MESA Image Manager log: $MESA_TARGET/logs/imgmgr.log. Submit that log file to the Project Manager as the output of this test.

7. The most typical problem is using the wrong certificate. Start the MESA servers with the highest log level. If you cannot get a C-Echo command to work, examine the MESA Image Manager log file.


[edit]

1226: DICOM Verification with TLS: Unregistered Certificate

In this test, your actor establishes a TLS connection with a MESA server that has a certificate that is not registered with your system. That is, your system should attempt to establish a DICOM connection, determine that the MESA system is using a certificate that is not known to you, and abort/terminate the network connection.

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

4. Establish a DICOM/TLS connection with the MESA server running on port 2351. DICOM AE titles are ignored. Send a C-Echo request to that server.

5. Your system should not complete the DICOM association negotiation.

6. When you have successfully completed the test, there will be log information stored in the MESA Image Manager log: $MESA_TARGET/logs/imgmgr.log. Submit that file to the Project Manager.

7. This is a rather difficult test as it is designed to make something fail on purpose. Whether your system closes the connection gracefully or merely exits depends on your design and software.


[edit]

1226: DICOM Verification with TLS: Expired Certificate

In this test, your actor establishes a TLS connection with a MESA server that has a certificate that is expired. That is, your system should attempt to establish a DICOM connection, determine that the MESA system is using a certificate that is expired, and abort/terminate the network connection.

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

4. Establish a DICOM/TLS connection with the MESA server running on port 2352. DICOM AE titles are ignored. Send a C-Echo request to that server.

5. Your system should not complete the DICOM association negotiation.

6. When you have successfully completed the test, there will be log information stored in the MESA Image Manager log: $MESA_TARGET/logs/imgmgr.log. Submit that file to the Project Manager.

7. This is a rather difficult test as it is designed to make something fail on purpose. Whether your system closes the connection gracefully or merely exits depends on your design and software.

Supplemental Information

The certificate used by the Image Manager for this test is located in $MESA_TARGET/runtime/certificates/expired.cert. You should try to configure your system to know that this is the peer certificate. This is to make sure you are testing for expired certificates rather than unregistered certificates.


[edit]

Secure Server Node Tests

Each section below lists one test for a Secure Server Node.


[edit]

1221: Server Certificate Exchange with Valid Certificate

In this test, a MESA client application requests a network connection with your server using the standard X.509 (unexpired) certificates. The MESA client will complete the TLS handshake and then disconnect after 2 seconds. Therefore, this test demonstrates your ability to implement the basic TLS handshake with the cyphersuite: 

   TLS_RSA_WITH_NULL_SHA

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Make sure the configuration file secure_test.cfg accurately describes your system.

3. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

4. (Optional) Clear the log files of prior messages: 

    perl scripts/clear_logs.pl

5. Instruct the MESA client to open a connection with your server: 

   perl 1221/1221_server_test.pl

6. After the TLS handshake and aborted message sequence, examine the MESA log file in $MESA_TARGET/logs/tls_client.txt. This should indicate a successful TLS handshake.

7. Cut/paste the entry from the MESA log file. Create a file named SYSTEM_1221.log, enter the log information and submit that file to the Project Manager.


[edit]

1222: Server Certificate Exchange with Unregistered Certificate

In this test, a MESA client application requests a network connection with your server using the standard X.509 certificates. The MESA server will attempt the TLS handshake by offering an unregistered certificate. You are expected to abort the network connection and log an audit record message with the MESA Audit Record Repository (at port 4000 on the MESA system).

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA servers are configured to recognize this certificate.

2. Make sure the configuration file secure_test.cfg accurately describes your system.

3. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

4. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

5. Instruct the MESA client to open a connection with your server: 

   perl 1222/1222_server_test.pl

6. After the TLS handshake and aborted message sequence, examine the MESA log file in $MESA_TARGET/logs/tls_client.txt This should indicate the aborted network connection.

7. After the TLS handshake and aborted message sequence, examine the MESA log file in $MESA_TARGET/logs/tls_client.txt. This should indicate a successful TLS handshake.

8. Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Node-Authentication failure and it should verify the content of that record against the IHE XML schema:. 

   perl 1222/eval_server_1222.pl  IETF (or)

   perl 1222/eval_server_1222.pl  INTERIM

9. The results file 1222/grade_server_1222.txt should show 0 failures.


[edit]

1223: Server Certificate Exchange with Expired Certificate

In this test, a MESA client application requests a network connection with your server using the standard X.509 certificates. The MESA server will attempt the TLS handshake by offering an expired certificate. You are expected to abort the network connection and log an audit record message with the MESA Audit Record Repository (at port 4000 on the MESA system).

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA applications are configured to recognize this certificate.

2. Make sure the configuration file secure_test.cfg accurately describes your system.

3. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

4.(Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

5. Instruct the MESA client to open a connection with your server: 

   perl 1223/1223_server_test.pl

6. After the TLS handshake and aborted message sequence, examine the MESA log file in $MESA_TARGET/logs/tls_client.txt This should indicate the aborted network connection.

7. After the TLS handshake and aborted message sequence, examine the MESA log file in $MESA_TARGET/logs/tls_client.txt. This should indicate a successful TLS handshake.

8. Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Node-Authentication failure and it should verify the content of that record against the IHE XML schema:. 

   perl 1223/eval_server_1223.pl

9. The results file 1223/grade_server_1223.txt should show 0 failures.


[edit]

1224: Server TLS Handshake for 3DES

Do not perform this test for the 2006-2007 cycle.


[edit]

1226: Server DICOM Verification with TLS

This test establishes a TLS connection with your server and sends a DICOM C-Echo command (Verification class) to your system.

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA applications are configured to recognize this certificate.

2. Make sure the configuration file secure_test.cfg accurately describes your system.

3. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

4. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

5. Instruct the MESA client to open a connection with your server: 

   perl 1226/1226_server_test.pl

6. This should run to completion with no errors. If you encounter an error, you will need to correct the communication problem and rerun the test

7. When the test is working successfully, run the test and redirect the output to a file. Submit that file to the Project Manager for evaluation.


[edit]

1227: Server DICOM Verification with TLS: Unregistered Certificate

This test attempts to establish a TLS connection with your server using an unregistered certificate. Should you accept the connection, the MESA application sends a DICOM C-Echo command (Verification class) to your system. The proper behavior is that your system refuses the TLS connection.

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA applications are configured to recognize this certificate.

2. Make sure the configuration file secure_test.cfg accurately describes your system.

3. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

4. (Optional) Clear the log files of prior messages: 

   perl scripts/clear_logs.pl

5. Instruct the MESA client to open a connection with your server: 

   perl 1227/1227_server_test.pl

6. This should run to completion and indicate that a connection was not completed. If the script completes a DICOM verification this indicates an error that should be corrected.

7. When the test is working successfully, run the test and redirect the output to a file. Submit that file to the Project Manager for evaluation.


[edit]

1228: Server DICOM Verification with TLS: Expired Certificate

This test attempts to establish a TLS connection with your server using an expired certificate. Should you accept the connection, the MESA application sends a DICOM C-Echo command (Verification class) to your system. The proper behavior is that your system refuses the TLS connection.

References

Instructions

1. Configure your system using the X.509 certificate assigned to you ($MESA_TARGET/runtime/certificates/test_sys_1). The MESA applications are configured to recognize this certificate.

2. Make sure the configuration file secure_test.cfg accurately describes your system.

3. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

4. (Optional) Clear the log files of prior messages: 

    perl scripts/clear_logs.pl

5. Instruct the MESA client to open a connection with your server: 

   perl 1228/1228_server_test.pl

6. This should run to completion and indicate that a connection was not completed. If the script completes a DICOM verification this indicates an error that should be corrected.

7. When the test is working successfully, run the test and redirect the output to a file. Submit that file to the Project Manager for evaluation.

Supplemental Information

The certificate used by the Image Manager for this test is located in $MESA_TARGET/runtime/certificates/expired.cert. You should try to configure your system to know that this is the peer certificate. This is to make sure you are testing for expired certificates rather than unregistered certificates.

[edit]

ATNA Secure Node (Client or Server)

Each section below describes one test that is appropriate for a Secure Node in the ATNA Integration Profile that is configured as either a client node or a server node.


[edit]

11100: ATNA: List Audit Messages

This is a documentation procedure where you list all of the audit messages that your system is required to produce. The purpose of the test is for you to provide that list to the Project Manager so that the manager can determine if your system is producing the proper set of messages. This test result is due 3 weeks in advance of the normal test deadlines. This will give you time to recover in the event that you are missing audit events required of your system.

References 

ITI TF-2:3.20.6 and Rad TF-3:5.1.1

Instructions

Create a text file named: grade_11100.txt. Content of the file should be as listed below

  • Line 1: Company Name.
  • Line 2: System Name
  • Line 3 and following: List of all Integration Profile/Actor combinations for this system.
  • Following lines: List all audit events for which your system produces an audit message. For transactions in the ITI domain, see ITI TF-2:3.20.6 and the "Security Considerations" section ITI TF-2 for each transaction your system supports. For transactions in the Radiology domain, see: Rad TF-3:5.1.1.
  • Submit the text file to the Project Manager for evaluation.

Evaluation

Supplemental Information

[edit]

11101: ATNA Audit: Actor Start BSD

This sequence tests your ability to send an audit record to a “BSD” Audit Record Repository. This test covers the basic functionality of transmitting the message and the proper XML format of the message. The Actor Start message is chosen as that is required of all actors and is independent of other IHE transactions.

References

Instructions

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/rad/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. By whatever means you use, “start” your actor such that it generates the Start/Stop audit record message. Send this message to the MESA “BSD” Audit Record Repository.

4. Run the evaluation script to examine the last audit record sent by your system to the MESA Audit Record Repository. It should find the last audit record was for Actor-start-stop and it should verify the content of that record against the IHE XML schema:

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/rad/actors/secure_node directory, run the evaluation script 

   perl 11101/eval_11101.pl <log level> INTERIM (or)

   perl 11101/eval_11101.pl <log level> IETF
where INTERIM or IETF indicate which schema is to be used.

2. The output file is 11101/grade_11101.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

[edit]

11102: ATNA Audit: Actor Start Reliable Syslog

Do not run this test for the 2006-2007 cycle. Reliable Syslog has been placed on hold


[edit]

11103: ATNA Audit: Actor Specific Audit Message

In this test, the actor generates a log message that is specific to the actor. The Actor Start/Stop or User Authentication messages are general in nature.

References

Instructions

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/rad/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. By whatever means you use, generate an audit record message that is specific to one or more of the actors in your system. Send this message to the appropriate repository.

4. Extract the log message from the server. Copy $MESA_TARGET/logs/syslog/last_log.xml to the file name of your choice.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/rad/actors/secure_node directory, run the evaluation script 

   perl 11103/eval_11103.pl <log level> INTERIM FILE(or)

   perl 11103/eval_11103.pl <log level> IETF FILE
where INTERIM or IETF indicate which schema is to be used.

2. The output file is 11103/grade_11103.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information


[edit]

11104: ATNA Audit: User Authentication

In this test, the system generates a User Authentication log message and evaluates it using the MESA tools.

References


Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/rad/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for a User Authentication event. Send this message to the appropriate MESA audit record repository.

4. Extract the log message from the server. Copy $MESA_TARGET/logs/syslog/last_log.xml to the file name of your choice.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/rad/actors/secure_node directory, run the evaluation script 

   perl 11104/eval_11104.pl <log level> INTERIM FILE(or)

   perl 11104/eval_11104.pl <log level> IETF FILE
where INTERIM or IETF indicate which schema is to be used.

2. The output file is 11104/grade_11104.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

[edit]

11106: ATNA -- Complete Questionnaire

In this test you complete a form which collects information that will help us evaluate your Audit Logging and Node Authentication capabilities during the Connectathon.

Instructions

1. Access a blank ATNA questionnaire at: http://ihewiki.wustl.edu/wiki/index.php/Image:ATNA_Questionnaire_2010.doc

2. Complete the questionnaire. If you are testing more that one system at the Connectathon, you will submit one form per system.

3. Upload the completed questionnaire into kudu under MESA Tests-->Pre-Connectathon...Objects'.

4. Finally, create a text file stating that your form is ready for review. Upload that text file into kudu as the Log Return file for test 11106.

Evaluation

The Project Manager will review your completed form. If we have comments, we will follow up with you.


[edit]

11107: ATNA -- Read ATNA testing policy for NA2010 Connectathon

A Change Proposal to that ATNA profile, approved in Sept 2009, affects the transport of audit records in the ATNA profile and prompts a new policy for testing ATNA at the 2010 North American Connectathon. We want to ensure that participants are not surprised by this change.

Instructions

1. Read the policy: http://ihewiki.wustl.edu/wiki/index.php/North_America_2010#ATNA_profile_testing_policy_for_NA2010_Connectathon

2. Create a text file stating that you have read the policy and upload that file as results for test 11107. If you have questions about the policy, contact the Connectathon Manager.

[edit]

11121: ATNA Audit: Patient Records

For test 11121, the system under test is asked to generate three or more audit messages. The user collects the messages and sends them to the Project Manager for distribution to other systems.

References

Instructions

1. Generate three (3) or more Audit Record messages containing at least one record for:

  • User Authentication
  • Patient Record Access

If the Patient Record Access is not pertinent, substitute a different event (PHI export). The third record is of your choosing.

2. Place each message in a separate XML file and tar/zip the collection together. Name the tar/zip file using the system name found in the Kudu web tool.

3. Submit the tar/zip file to the Project Manager. The Project Manager will distribute to other vendors for testing.

4. Please submit the records 2 weeks in advance of the normal deadline to allow distribution to other systems.



[edit]

ATNA Tests for Client Applications

The tests in this section are for ATNA applications that initiate TLS connections. In that sense, these are considered client applications.

[edit]

11141: Client ATNA Certificate Exchange with Valid Certificate

References

Instructions

Run test 1221 described in this document.

Rename the grade file grade_11141.txt.

Submit the grade file to the Project Manager.


[edit]

11142: Client ATNA Certificate Exchange with Unregistered Certificate

References

Instructions

Run test 1222 described in this document.

Rename the grade file grade_11142.txt.

Submit the grade file to the Project Manager.


[edit]

11143: Client ATNA Certificate Exchange with Expired Certificate

References

Instructions

Run test 1223 described in this document.

Rename the grade file grade_11143.txt.

Submit the grade file to the Project Manager.

[edit]

11170: ATNA TLS/CA signed, HL7 V2, Client Side

The 11170 series of tests are for applications that initiate an HL7 V2 connection. In that sense, they are client applications. Perform any of the 11170-xx tests that apply to your system. Upload results into Kudu/Gazelle for at least one of the tests. You do not need to upload results for each test. Run all of the tests, but upload results for one.

If your system has no HL7 V2 communication, or if there is not an appropriate HL7 V2 test defined, enter a short note (1-2 lines) in the Kudu/Gazelle system.

[edit]

11170-01: TLS/CA Signed: ITI-8 Patient Identity Source

This test is designed for Patient Identity Source actors which implement the ITI-8 transaction. In this test, the Patient Identity Source sends an HL7 V2 ADT message (ITI-8) to a MESA PIX Manager. The communication is secured using TLS and a CA-signed certificate.

References

Instructions

  1. Read the instructions on CA-signed certificates
  2. Start CA-signed versions of the MESA servers
  3. Send one ITI-8 transaction to the MESA PIX Manager listening on port 3601. Demographics/ID are arbitrary.
  4. Examine the log file in $MESA_TARGET/logs/xr_hl7ps_secure.log
    1. You should see evidence of certificate exchange that will list your certificate
    2. You should see evidence that the MESA PIX Manager received an ADT message from you
  5. Once you have gotten the exchange to work, delete $MESA_TARGET/logs/xr_hl7ps_secure.log
  6. Send one ITI-8 transaction to the MESA PIX Manager. Demographics/ID are arbitrary.
  7. Examine the log file again for evidence of 1 certificate exchange and one ADT message.
  8. Assuming the log file shows that evidence, submit that log file as evidence for this test.

Evaluation The log files are human readable and should clearly indicate certificate exchange and the transmission of one HL7 V2 ADT message (ITI-8). No automatic evaluation is available.

Supplemental Information

Test 11170-01 will not appear on your test list. Submit the results of this test for 11170.

Submit a clean log file without 5 failed attempts.

[edit]

11170-02: TLS/CA Signed: ITI-9 PIX Query Consumer

This test is designed for Patient Identifier Cross Reference Consumer actors which implement the ITI-9 transaction. In this test, the Patient Identitifier Cross Reference Consumer sends an HL7 V2 PIX query (ITI-9) to a MESA PIX Manager. The communication is secured using TLS and a CA-signed certificate.

References

Instructions

  1. Read the instructions on CA-signed certificates
  2. Start CA-signed versions of the MESA servers
  3. Send one ITI-9 transaction to the MESA PIX Manager listening on port 3601. Demographics/ID are arbitrary.
  4. Examine the log file in $MESA_TARGET/logs/xr_hl7ps_secure.log
    1. You should see evidence of certificate exchange that will list your certificate
    2. You should see evidence that the MESA PIX Manager received a PIX Query message from you
  5. Once you have gotten the exchange to work, delete $MESA_TARGET/logs/xr_hl7ps_secure.log
  6. Send one ITI-9 transaction to the MESA PIX Manager. Demographics/ID are arbitrary.
  7. Examine the log file again for evidence of 1 certificate exchange and one PIX Query.
  8. Assuming the log file shows that evidence, submit that log file as evidence for this test.

Evaluation The log files are human readable and should clearly indicate certificate exchange and the transmission of one HL7 V2 PIX Query (ITI-9). No automatic evaluation is available.

Supplemental Information

Test 11170-02 will not appear on your test list. Submit the results of this test for 11170.

The response from the PIX manager might not indicate a match. That is not important. The important part of the test is to see that the certificate negotiation completed successfully and the MESA PIX Manager receives the ITI-9 query.


[edit]

11170-03: TLS/CA Signed: ITI-21 PDQ Query Consumer

This test is designed for Patient Demographics Consumer actors which implement the ITI-21 transaction. In this test, the Patient Demographics Consumer sends an HL7 V2 PDQ query (ITI-21) to a MESA Patient Demographics Supplier. The communication is secured using TLS and a CA-signed certificate.

References

Instructions

  1. Read the instructions on CA-signed certificates
  2. Start CA-signed versions of the MESA servers
  3. Send one ITI-21 transaction to the MESA Patient Demographics Supplier listening on port 3701. Demographics/ID are arbitrary.
  4. Examine the log file in $MESA_TARGET/logs/pds_hl7ps_secure.log
    1. You should see evidence of certificate exchange that will list your certificate
    2. You should see evidence that the MESA Patient Demographics Supplier received a PDQ request from you.
  5. Once you have gotten the exchange to work, delete $MESA_TARGET/logs/pds_hl7ps_secure.log
  6. Send one ITI-21 transaction to the MESA PIX Manager. Demographics/ID are arbitrary.
  7. Examine the log file again for evidence of 1 certificate exchange and one PDQ request.
  8. Assuming the log file shows that evidence, submit that log file as evidence for this test.

Evaluation The log files are human readable and should clearly indicate certificate exchange and the transmission of one HL7 V2 Patient Demographics Query (ITI-21). No automatic evaluation is available.

Supplemental Information

Test 11170-03 will not appear on your test list. Submit the results of this test for 11170.

The response from the Patient Demographics Supplier might not indicate a match. That is not important. The important part of the test is to see that the certificate negotiation completed successfully and the MESA PDS receives the ITI-21 query.

[edit]

ATNA Tests for Server Applications

The tests in this section are for ATNA applications that accept TLS connections. In that sense, these are considered server applications.

[edit]

11141: ATNA Certificate Exchange with Valid Certificate

References

Instructions

Run test 1221 described in this document. Rename the grade file grade_11141.txt. Submit the grade file to the Project Manager.

Supplemental Information

[edit]

11142: ATNA Certificate Exchange with Unregistered Certificate

References

Instructions

Run test 1222 described in this document. Rename the grade file grade_11142.txt. Submit the grade file to the Project Manager. Submit the grade file to the Project Manager.

Supplemental Information


[edit]

11143: ATNA Certificate Exchange with Expired Certificate

References

Instructions

Run test 1223 described in this document. Rename the grade file grade_11143.txt. Submit the grade file to the Project Manager. Submit the grade file to the Project Manager.

Supplemental Information


[edit]

11175: ATNA TLS/CA signed, HL7 V2, Server Side

The 11175 series of tests are for applications that accept an HL7 V2 connection. In that sense, they are server applications. Perform any of the 11175-xx tests that apply to your system. Upload results into Kudu/Gazelle for at least one of the tests. You do not need to upload results for each test. Run all of the tests, but upload results for one.

If your system has no HL7 V2 communication, or if there is not an appropriate HL7 V2 test defined, enter a short note (1-2 lines) in the Kudu/Gazelle.

[edit]

11175-01: TLS/CA Signed: ITI-8 PIX Manager

This test is designed for Patient Identity Cross Reference actors which implement the ITI-8 transaction. In this test, the MESA Patient Identity Source sends an HL7 V2 ADT message (ITI-8) to PIX Manager under test. The communication is secured using TLS and a CA-signed certificate.

References

Instructions

  1. Read the instructions on CA-signed certificates
  2. cd $MESA_TARGET/mesa_tests/iti/actors/secure_node
  3. Send an ADT A04 message to your PIX manager
    1. perl scripts/111750-01/xref_mgr.pl host port
  4. Examine the log file in $MESA_TARGET/logs/send_hl7_secure.log
    1. You should see evidence of certificate exchange that will list your certificate
    2. You should see evidence that the PIX Manager responded to the HL7 message with an ACK.
  5. Once you have gotten the exchange to work, delete $MESA_TARGET/logs/send_hl7_secure.log
  6. Send the ADT A04 message to your PIX manager again, using the script above.
  7. Examine the log file again for evidence of 1 certificate exchange and one ADT message.
  8. Assuming the log file shows that evidence, submit that log file as evidence for this test.

Evaluation The log files are human readable and should clearly indicate certificate exchange and the transmission of one HL7 V2 ADT message (ITI-8). No automatic evaluation is available.

Supplemental Information

Test 11175-01 will not appear on your test list. Submit the results of this test for 11175.

Submit a clean log file without 5 failed attempts.

[edit]

11175-02: TLS/CA Signed: ITI-9 PIX Manager

This test is designed for Patient Identity Cross Reference actors which implement the ITI-9 transaction. In this test, the MESA PIX Consumer sends an HL7 V2 query message (ITI-9) to the PIX Manager under test. The communication is secured using TLS and a CA-signed certificate.

References

Instructions

  1. Read the instructions on CA-signed certificates
  2. cd $MESA_TARGET/mesa_tests/iti/actors/secure_node
  3. Send a PIX query message to your PIX manager
    1. perl scripts/11175-02/xref_mgr.pl host port
  4. Examine the log file in $MESA_TARGET/logs/send_hl7_secure.log
    1. You should see evidence of certificate exchange that will list your certificate
    2. You should see evidence that the PIX Manager responded to the HL7 message with an ACK.
  5. Once you have gotten the exchange to work, delete $MESA_TARGET/logs/send_hl7_secure.log
  6. Send the PIX query message to your PIX manager again, using the script above.
  7. Examine the log file again for evidence of 1 certificate exchange and one query message.
  8. Assuming the log file shows that evidence, submit that log file as evidence for this test.

Evaluation The log files are human readable and should clearly indicate certificate exchange and the transmission of one HL7 V2 PIX Query (ITI-9). No automatic evaluation is available.

Supplemental Information

Test 11175-02 will not appear on your test list. Submit the results of this test for 11175.

The response from the PIX manager might not indicate a match. That is not important. The important part of the test is to see that the certificate negotiation completed successfully and the PIX Manager receives the ITI-9 query and formulates some response.


[edit]

11175-03: TLS/CA Signed: ITI-21 Patient Demographics Supplier

This test is designed for Patient Demographics Supplier actors which implement the ITI-21 transaction. In this test, the MESA PD Consumer sends an HL7 V2 query message (ITI-21) to the PD Supplier under test. The communication is secured using TLS and a CA-signed certificate.

References

Instructions

  1. Read the instructions on CA-signed certificates
  2. cd $MESA_TARGET/mesa_tests/iti/actors/secure_node
  3. Send a PDQ message to your PD Supplier.
    1. perl scripts/11175-03/pds.pl host port
  4. Examine the log file in $MESA_TARGET/logs/send_hl7_secure.log
    1. You should see evidence of certificate exchange that will list your certificate
    2. You should see evidence that the PD Supplier responded to the HL7 message with an ACK.
  5. Once you have gotten the exchange to work, delete $MESA_TARGET/logs/send_hl7_secure.log
  6. Send the query message to your PD Supplier again, using the script above.
  7. Examine the log file again for evidence of 1 certificate exchange and one query message.
  8. Assuming the log file shows that evidence, submit that log file as evidence for this test.

Evaluation

The log files are human readable and should clearly indicate certificate exchange and the transmission of one HL7 V2 Patient Demographics Query (ITI-21). No automatic evaluation is available.

Supplemental Information

Test 11175-03 will not appear on your test list. Submit the results of this test for 11175.

The response from the Patient Demographics Supplier might not indicate a match. That is not important. The important part of the test is to see that the certificate negotiation completed successfully and the PDS receives the ITI-21 query.

[edit]

ATNA All Audit Events

[edit]

11180: System Audit Event

Test 11180 is a reference to other tests. Your “system” should generate one or more of the audit events listed in ITI TF 2:3.20.6.

Determine which log messages your system should generate in response to user events.

Run one or more of the tests 11181 – 11202 as appropriate for the user events.

Submit the grade message for test 11181 – 11202 as 11180. You may submit a zip file with multiple results

[edit]

11181: Actor Start

In this test, the system generates an Actor Start log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Actor Start event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11181/eval_11181.pl <log level>

2. The output file is 111181/grade_11181.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Actor Start. See DICOM Supplement 95 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.1
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110100 DICOM Supplement 95, A.1.3.1
codeSystemName DCM DICOM Supplement 95, A.1.3.1
displayName Application Activity DICOM Supplement 95, A.1.3.1
EventTypeCode code 110120 DICOM Supplement 95, A.1.3.1
codeSystemName DCM DICOM Supplement 95, A.1.3.1
displayName Application Start DICOM Supplement 95, A.1.3.1
[edit]

11182: Actor Stop

In this test, the system generates an Actor Stop log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Actor Stop event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11182/eval_11182.pl <log level>

2. The output file is 11182/grade_11182.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Actor Stop. See DICOM Supplement 95 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.1
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110100 DICOM Supplement 95, A.1.3.1
codeSystemName DCM DICOM Supplement 95, A.1.3.1
displayName Application Activity DICOM Supplement 95, A.1.3.1
EventTypeCode code 110121 DICOM Supplement 95, A.1.3.1
codeSystemName DCM DICOM Supplement 95, A.1.3.1
displayName Application Stop DICOM Supplement 95, A.1.3.1


[edit]

11183: Begin Storing Instances

In this test, the system generates a Begin Storing Instances log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Actor Stop event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11183/eval_11183.pl <log level>

2. The output file is 11183/grade_11183.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Begin Storing Instances. See DICOM Supplement 95 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.1
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110102 DICOM Supplement 95, A.1.3.1
codeSystemName DCM DICOM Supplement 95, A.1.3.1
displayName Begin Transferring DICOM Instances DICOM Supplement 95, A.1.3.1


[edit]

11184: Health-service-event

In this test, the system generates a Health Service Event log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Actor Stop event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11184/eval_11184.pl <log level>

2. The output file is 11184/grade_11184.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Health Service Event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode C ITI TF-2, section 3.20.7.3
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code IHE0001 ITI TF-2, section 3.20.7.3
codeSystemName IHE ITI TF-2, section 3.20.7.3
displayName Health Services Provision Event ITI TF-2, section 3.20.7.3


[edit]

11185: Instances-deleted

In this test, the system generates an Instances Deleted log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Instances Deleted event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11185/eval_11185.pl <log level>

2. The output file is 11185/grade_11185.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Instances Deleted. See DICOM Supplement 95 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode D DICOM Supplement 95, A.1.3.8
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110105 DICOM Supplement 95, A.1.3.8
codeSystemName DCM DICOM Supplement 95, A.1.3.8
displayName DICOM Study Delete DICOM Supplement 95, A.1.3.8


[edit]

11186: Instances-Stored

In this test, the system generates an Instances Stored log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Instances Stored event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11186/eval_11186.pl <log level>

2. The output file is 11186/grade_11186.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Instances Stored. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode one of the following values - C or R or U DICOM Supplement 95, A.1.3.7
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110104 DICOM Supplement 95, A.1.3.7
codeSystemName DCM DICOM Supplement 95, A.1.3.7
displayName DICOM Instances Transferred DICOM Supplement 95, A.1.3.7


[edit]

11187: Medication

In this test, the system generates a Medication log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Medication event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11187/eval_11187.pl <log level>

2. The output file is 11187/grade_11187.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Medication event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C ITI TF-2, section 3.20.7.3
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code IHE0002 ITI TF-2, section 3.20.7.3
codeSystemName IHE ITI TF-2, section 3.20.7.3
displayName Medication Event ITI TF-2, section 3.20.7.3


[edit]

11188: Mobile-machine-event/enter

In this test, the system generates a Mobile-Machine-Event (Enter) log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Mobile Machine Event (enter) event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11188/eval_11188.pl <log level>

2. The output file is 11188/grade_11188.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Mobile Machine Event (enter). See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.9
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110108 DICOM Supplement 95, A.1.3.9
codeSystemName DCM DICOM Supplement 95, A.1.3.9
displayName Netwok Entry DICOM Supplement 95, A.1.3.9
EventTypeCode code 110124 DICOM Supplement 95, A.1.3.9
codeSystemName DCM DICOM Supplement 95, A.1.3.9
displayName Attach DICOM Supplement 95, A.1.3.9


[edit]

11189: Mobile-machine-event/leave

In this test, the system generates a Mobile-Machine-Event (Leave) log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Mobile Machine Event (leave) event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11189/eval_11189.pl <log level>

2. The output file is 11189/grade_11189.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Mobile Machine Event (leave). See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.9
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110108 DICOM Supplement 95, A.1.3.9
codeSystemName DCM DICOM Supplement 95, A.1.3.9
displayName Netwok Entry DICOM Supplement 95, A.1.3.9
EventTypeCode code 110124 DICOM Supplement 95, A.1.3.9
codeSystemName DCM DICOM Supplement 95, A.1.3.9
displayName Detach DICOM Supplement 95, A.1.3.9


[edit]

11190: Node-Authentication-Failure

In this test, the system generates a Node-Authentication-Failure log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Node-Authentication-Failure event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11190/eval_11190.pl <log level>

2. The output file is 11190/grade_11190.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Node-Authentication-Failure. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.4
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110113 DICOM Supplement 95, A.1.3.14
codeSystemName DCM DICOM Supplement 95, A.1.3.14
displayName Security Alert DICOM Supplement 95, A.1.3.14
EventTypeCode code 110126 DICOM Supplement 95, A.1.3.14
codeSystemName DCM DICOM Supplement 95, A.1.3.14
displayName Node Authentication DICOM Supplement 95, A.1.3.9
[edit]

11191: Order-record-event

In this test, the system generates an Order-record-event log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Order-record-event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 1. perl 11191/eval_11191.pl <log level>

2. The output file is 11191/grade_11191.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Order-record-event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D DICOM Supplement 95, A.1.3.10
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110109 DICOM Supplement 95, A.1.3.10
codeSystemName DCM DICOM Supplement 95, A.1.3.10
displayName Order Record DICOM Supplement 95, A.1.3.14


[edit]

11192: Patient-care-assignment

In this test, the system generates a Patient-Care-Assignment log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Patient-care-assignment event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11192/eval_11192.pl <log level>

2. The output file is 11192/grade_11192.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Patient-care-assignment. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D ITI TF Vol2, 3.20.7.3.3
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code IHE0003 ITI TF Vol2, 3.20.7.3.3
codeSystemName IHE ITI TF Vol2, 3.20.7.3.3
displayName Patient Care Resource Assignment ITI TF Vol2, 3.20.7.3.3
[edit]

11193: Patient-care-episode

In this test, the system generates a Patient-care-episode log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Patient-care-episode event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11193/eval_11193.pl <log level>

2. The output file is 11193/grade_11193.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Patient-care-episode. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D ITI TF Vol2, 3.20.7.3.4
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code IHE0004 ITI TF Vol2, 3.20.7.3.4
codeSystemName IHE ITI TF Vol2, 3.20.7.3.4
displayName Patient Care Resource Assignment ITI TF Vol2, 3.20.7.3.4
[edit]

11194: Patient-care-protocol

In this test, the system generates a Patient-care-protocol log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Patient-care-protocol event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11194/eval_11194.pl <log level>

2. The output file is 11194/grade_11194.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Patient-care-protocol. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D ITI TF Vol2, 3.20.7.3.5
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code IHE0005 ITI TF Vol2, 3.20.7.3.5
codeSystemName IHE ITI TF Vol2, 3.20.7.3.5
displayName Patient Care Protocol ITI TF Vol2, 3.20.7.3.5
[edit]

11195: Patient-record-event

In this test, the system generates a Patient-record-event log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Patient-care-protocol event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11195/eval_11195.pl <log level>

2. The output file is 11195/grade_11195.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Patient-record-event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D DICOM Supplement 95, A.1.3.11
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110110 DICOM Supplement 95, A.1.3.11
codeSystemName DCM DICOM Supplement 95, A.1.3.11
displayName Patient Record ITI TF Vol2, 3.20.7.3.11
[edit]

11196: PHI-export

In this test, the system generates a PHI Export log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Actor Stop event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11196/eval_11196.pl <log level>

2. The output file is 11196/grade_11196.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is PHI Export. See DICOM Supplement 95 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.

! Element !! Value !! Attribute !! Value !! Comments |- style="background:white;" |EventIdentification | |EventActionCode |R |DICOM Supplement 95, A.1.3.4 |- style="background:white;" | | |EventDateTime | |Proper date/time format |- style="background:white;" | | |EventOutcomeIndicator |0 |RFC 3881 5.1.4 |- style="background:white;" |EventID | |code |110106 |DICOM Supplement 95, A.1.3.4 |- style="background:white;" | | |codeSystemName |DCM |DICOM Supplement 95, A.1.3.4 |- style="background:white;" | | |displayName |Export |ITI TF Vol2, 3.20.7.3.4 |- style="background:white;" |}


[edit]

11197: PHI-import

In this test, the system generates a PHI Import log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Actor Stop event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11197/eval_11197.pl <log level>

2. The output file is 11197/grade_11197.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is PHI-Import. See DICOM Supplement 95 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C DICOM Supplement 95, A.1.3.5
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110107 DICOM Supplement 95, A.1.3.5
codeSystemName DCM DICOM Supplement 95, A.1.3.5
displayName Import DICOM Supplement 95, A.1.3.5
[edit]

11198: Procedure-record-event

In this test, the system generates a Procedure-record-event log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Procedure-care-protocol event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11198/eval_11198.pl <log level>

2. The output file is 11198/grade_11198.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Procedure-record-event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D DICOM Supplement 95, A.1.3.12
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110111 DICOM Supplement 95, A.1.3.12
codeSystemName DCM DICOM Supplement 95, A.1.3.12
displayName Procedure Record DICOM Supplement 95, A.1.3.12
[edit]

11199: Query Information

In this test, the system generates a Query Information log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Query Information event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11199/eval_11199.pl <log level>

2. The output file is 11199/grade_11199.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Query Information event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.13
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110112 DICOM Supplement 95, A.1.3.13
codeSystemName DCM DICOM Supplement 95, A.1.3.13
displayName Query DICOM Supplement 95, A.1.3.13
[edit]

11200: Security Administration

In this test, the system generates a Security Administration log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Security Administration event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11200/eval_11200.pl <log level>

2. The output file is 11200/grade_11200.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Query Information event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode E DICOM Supplement 95, A.1.3.14
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110113 DICOM Supplement 95, A.1.3.14
codeSystemName DCM DICOM Supplement 95, A.1.3.14
displayName Security Alert DICOM Supplement 95, A.1.3.14
EventTypeCode code one of the following values - 110126 or 110127 or 110128 or 110129 or 110129 or 110130 or 110131 or 110132 or 110133 or 110134 or 110135 or 110136 or 110137 DICOM Supplement 95, A.13.14
codeSystemName DCM DICOM Supplement 95, A.1.3.14
displayName one of the following values - Node Authentication or Emergency Override or Network Configuration or Security Configuration or Hardware Configuration or Software Configuration or Use of Restricted Function or Audit Recording Stopped or Audit Recording Started or Object Security Attributes Changed orSecurity Roles Changed or User security Attributes Changed DICOM Supplement 95, A.1.3.14
[edit]

11201: Study-Object-Event

In this test, the system generates a Security Administration log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Security Administration event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11201/eval_11201.pl <log level>

2. The output file is 11201/grade_11201.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Security Administration event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D DICOM Supplement 95, A.1.3.6
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110103 DICOM Supplement 95, A.1.3.6
codeSystemName DCM DICOM Supplement 95, A.1.3.6
displayName DICOM Instances Accessed DICOM Supplement 95, A.1.3.6
[edit]

11202: Study-used

In this test, the system generates a Study-used log message and evaluates it using the MESA tools.

References

Instructions

Perform these instructions using a DOS/Command prompt window or terminal emulator.

1. Set the current directory to $MESA_TARGET/mesa_tests/iti/actors/secure_node.

2. Make sure the MESA servers have been started. See Starting the MESA Servers for details.

3. Generate an audit record message for the Study-used event. Send this message to the MESA syslog server (Syslog UDP protocol, port 4000).

4. Examine the file $MESA_TARGET/logs/syslog/last_log.xml. This should contain your ATNA log message. If not, the BSD syslog communication failed.

Evaluation

To evaluate your response to this test:

1. From the $MESA_TARGET/mesa_tests/iti/actors/secure_node directory, run the evaluation script 

   perl 11202/eval_11202.pl <log level>

2. The output file is 11202/grade_11202.txt. This test is successfully completed when the last line in the output file indicates 0 errors.

3. Submit the grade file to the Project Manager.

Supplemental Information

The trigger event is Study-used event. See ITI TF-2 for details. This section defines the values expected/required by this test. If your interpretation of the values for these fields differs from ours, please contact us.


Element Value Attribute Value Comments
EventIdentification EventActionCode C or R or U or D DICOM Supplement 95, A.1.3.6
EventDateTime Proper date/time format
EventOutcomeIndicator 0 RFC 3881 5.1.4
EventID code 110103 DICOM Supplement 95, A.1.3.6
codeSystemName DCM DICOM Supplement 95, A.1.3.6
displayName DICOM Instances Accessed DICOM Supplement 95, A.1.3.6
Retrieved from "http://ihewiki.wustl.edu/wiki/index.php/MESA/Secure_Node"
Personal tools