Integrating the Healthcare Enterprise
ATNA/Basic Security Connectathon
Test Cases
Revision 2007-2
11-January-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
Contents
1
2
Introduction.............................................................................................................................. 2
Tests ......................................................................................................................................... 2
2.1 ATNA_Authentication_DICOM ...................................................................................... 2
2.2 ATNA_Authentication_HL7_V2 ..................................................................................... 3
2.3 ATNA_Authentication_HTTP ......................................................................................... 4
2.4 ATNA_Inquisition ............................................................................................................ 5
2.5 ATNA_Logging ............................................................................................................... 6
3 Retired Tests ............................................................................................................................ 8
3.1 ATNA_Authentication (Retired) ...................................................................................... 8
3.2 ATNA_Schema_Transport (Retired) ............................................................................... 9
3.3 ATNASecureWorkflow (Retired) .................................................................................. 10
3.4 ATNA_Employee_Tracking (Retired) ........................................................................... 10
3.5 ATNA_VIP_Patient_Tracking (Retired) ........................................................................ 12
3.6 ATNA_Fully_Secured_Node (Retired).......................................................................... 14
3.7 ATNAMultipleEvents (Retired) ..................................................................................... 15
__________________________________________________________________________
1
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
1
Introduction
This document describes the IHE Connectathon tests for the ATNA and Basic Security
Integration Profiles. This data will eventually be loaded into the Kudu web tool.
2
Tests
2.1
ATNA_Authentication_DICOM
2.1.1
Special Instructions
Your ATNA Secure Node may not support the DICOM protocol. In that case, skip this test.
2.1.2
Description
The purpose of the ATNA_Authentication_DICOM test is for Secure Nodes (ATNA or Basic
Security) to exchange certificates and then perform DICOM communication over the established
connection.
Evaluation will require the both applications to show log files or other evidence that certificates
were successfully exchanged and an IHE transaction occurred. The transaction is allowed to
cover a subset of an Integration Profile.
As a Secure Node at the Connectathon, you need to examine the list of other Secure Nodes and
find a system that you recognize as a test partner for other tests. Once you have found a suitable
test partner that uses the DICOM protocol over TLS, you can run this test.
2.1.3
Actors
Secure Node
2.1.4
Steps
Rad-32:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
ITI-19:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
Trans 0:
Secure Node (“client”) completes unspecified IHE transaction with Secure Node
(“server”) using DICOM communication.
__________________________________________________________________________
2
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
2.1.5
Evaluation
Connectathon monitor will examine log files of both applications for evidence of certificate
exchange. Systems should also be able to demonstrate that some transaction was completed
(MWL worklist query, DICOM C-Store, etc.).
Systems must support defined cyphersuites. These are found in the IHE ITI Technical
Framework and should also be documented here.
The systems under test need to demonstrate only one type of transaction is operational using the
TLS communication.
2.2
ATNA_Authentication_HL7_V2
2.2.1
Special Instructions
Your ATNA Secure Node may not support the HL7 V2 protocol. In that case, skip this test.
2.2.2
Description
The purpose of the ATNA_Authentication_HL7_V2 test is for Secure Nodes (ATNA or Basic
Security) to exchange certificates and then perform HL7 V2 communication over the established
connection.
Evaluation will require the both applications to show log files or other evidence that certificates
were successfully exchanged and an IHE transaction occurred. The transaction is allowed to
cover a subset of an Integration Profile.
As a Secure Node at the Connectathon, you need to examine the list of other Secure Nodes and
find a system that you recognize as a test partner for other tests. Once you have found a suitable
test partner that uses HL7 V2 messaging over TLS, you can run this test.
2.2.3
Actors
Secure Node
2.2.4
Steps
Rad-32:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
ITI-19:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
Trans 0:
Secure Node (“client”) completes unspecified IHE transaction with Secure Node
(“server”) using HL7 V2 communication.
__________________________________________________________________________
3
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
2.2.5
Evaluation
Connectathon monitor will examine log files of both applications for evidence of certificate
exchange. Systems should also be able to demonstrate that some transaction was completed
(ADT, ORM.).
Systems must support defined cyphersuites. These are found in the IHE ITI Technical
Framework and should also be documented here.
The systems under test need to demonstrate only one type of transaction is operational using the
TLS communication.
2.3
ATNA_Authentication_HTTP
2.3.1
Special Instructions
Your ATNA Secure Node may not support the HTTP protocol. In that case, skip this test.
2.3.2
Description
The purpose of the ATNA_Authentication_HTTP test is for Secure Nodes (ATNA or Basic
Security) that communicate using HTTP to use HTTPS and exchange the proper certificates.
Evaluation will require the both applications to show log files or other evidence that certificates
were successfully exchanged and an IHE transaction occurred. The transaction is allowed to
cover a subset of an Integration Profile.
As a Secure Node at the Connectathon, you need to examine the list of other Secure Nodes and
find a system that you recognize as a test partner for other tests. Once you have found a suitable
test partner that uses HTTPS with mutual authentication, you can run this test.
2.3.3
Actors
Secure Node
2.3.4
Steps
Rad-32:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
ITI-19:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
Trans 0:
Secure Node (“client”) completes unspecified IHE transaction with Secure Node
(“server”) using HL7 V2 communication.
__________________________________________________________________________
4
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
2.3.5
Evaluation
Connectathon monitor will examine log files of both applications for evidence of certificate
exchange. Systems should also be able to demonstrate that some transaction was completed (RID
Query, XDS Submit Document, XDS Register Document, XDS Parameterized Query).
Systems must support defined cyphersuites. These are found in the IHE ITI Technical
Framework and should also be documented here.
The systems under test need to demonstrate only one type of transaction is operational using the
TLS communication.
2.4
ATNA_Inquisition
2.4.1
Description
The ATNA profile has specific requirements for secure communication (TLS) and logging.
There are other requirement that describe how you protect and monitor your system. These other
requirements are best addressed with an interview process.
You will run one version of this test. A Connectathon Monitor will visit your system and
questions that are listed in a form. The questions are published along with the test plan. The goal
of the interview/inquisition is for the Connectathon Monitor to determine if you have met the
ATNA requirements for securing your system.
The Connectathon monitor will examine your system, listen to your responses and record an
opinion as to whether your system qualifies as:

ATNA Secure Node

ATNA Secure Application
If you do not qualify for either of these, you fail the ATNA profile.
As part of this test, the Connectathon Monitor will ask you to send Audit Messages to one or
more Audit Record Repository sytems. You should test your audit messages with the Audit
Record Repository systems before the arrival of the Connectathon Monitor. Those tests will not
be recorded in Kudu. The audit messages generated during this test will form the basis of the
audit record tests for both the client systems (Secure Node actors) and the Audit Record
Repository actors.
The form to be filled out is called the ATNA Secure Node Form. It is available at the same time
this document is published. You are encouraged to read the form, fill in as much information as
possible and email to the Project Manager 5 business days in advance of the Connectathon. That
will speed the interview process.
__________________________________________________________________________
5
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
2.5
2.5.1
ATNA_Logging
Special Instructions
ATNA logging is a supplement to the Inquisition test. Secure nodes need to run this test as well
as it will give you experience with more than one Audit Record Repository.
The Reliable Syslog protocol has been placed on hold by the ITI Technical Committee; only the
Berkley UDP protocol shall be used.
ATNA allows the Secure Node to select from two different schemas. However, the Secure Node
should not mix schemas; it should implement one schema for the system. Audit Record
Repository actors are required to support both schemas.
2.5.2
Description
The purpose of the ATNA_Logging test is for Secure Node (ATNA or Basic Security) to send
one or more audit messages to an Audit Record Repository. The type of audit message depends
on the nature of the Secure Node.
The top priority for testing would be an event that involves access to PHI that would result in an
audit message that includes a Patient ID. We have a well known patient to use, and want the
Secure Nodes to generate an event for that patient if possible.
If the Secure Node does not generate an audit message that includes a patient ID, we will accept
a different audit message.
Assuming a PHI event, the Secure Node should generate an audit record with the patient ID that
corresposponds to the well know patient FARNSWORTH^STEVE. This global ID is fixed by
the Connectathon test plan:
101^^^HIMSS2005&1.3.6.1.4.1.21367.2005.1.1&ISO^PI.
If your system generates an audit record using a local ID for FARNSWORTH, make sure you
inform the Connectathon monitor.
The test steps list both audit message schemas; run the test with a single schema. That means you
will omit one test step.
2.5.3
Evaluation
For a PHI related log message, the Connectathon Monitor will ask the Audit Record Repository
for a list of PHI related events for the FARNSWORTH patient from the Secure Node that
participated in the test.
If the Secure Node does not generate an event with the FARNSWORTH patient ID, the
Connectathon Monitor will ask the Audit Record Repository to show the last one or two log
messages from the Secure Node.
__________________________________________________________________________
6
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
2.5.4
Actors
Secure Node
Audit Record Repository
2.5.5
Steps
Trans-0:
Secure Node engages in some action (maybe with help from others) that triggers
an audit message. In the best scenario, this includes the patient ID for the patient
FARNSWORTH.
ITI-20:
Secure Node sends audit message using IHE YR4 Interim Schema
ITI-20:
Secure Node sends audit message using IETF Audit Message Schema.
__________________________________________________________________________
7
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
3
Retired Tests
These tests are still listed but are retired. They may be brought back for future events.
3.1
ATNA_Authentication (Retired)
3.1.1
Special Instructions
This test will not be run during the 2007 Connectathon in Chicago.
3.1.2
Description
The purpose of the ATNAAuthentication test is for Secure Nodes (ATNA or Basic Security) to
exchange certificates and then perform communication over the established connection. This
implies DICOM, HL7 or other communication over the established connection.
Evaluation will require the both applications to show log files or other evidence that certificates
were successfully exchanged and an IHE transaction occurred. The transaction will be a subset
of an Integration Profile.
3.1.3
Actors
Secure Node
3.1.4
Steps
Rad-32:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
ITI-19:
Secure Node (“client”) initiates TLS connection with Secure Node (“server”).
Trans 0:
Secure Node (“client”) completes unspecified IHE transaction with Secure Node
(“server”).
3.1.5
Evaluation
Connectathon monitor will examine log files of both applications for evidence of certificate
exchange. Systems should also be able to demonstrate that some transaction was completed
(Patient ADT, MWL worklist query).
The systems under test need to demonstrate only one type of transaction is operational using the
TLS communication.
__________________________________________________________________________
8
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
3.2
ATNA_Schema_Transport (Retired)
3.2.1
Special Instructions
This test is included only as setup/instruction. You can run this test with a partner, but do NOT
enter the test in Kudu. You have a different test that will require examination of log messages by
a Connectathon monitor.
3.2.2
Description
The ATNA Integration Profile supports two transports: BSD Syslog and Reliable Syslog. It also
supports two schema definitions: IHE Provisional (Radiology Year 4) and the schema found in
RFC 3881 Security Audit and Access Accountability Message XML Data Definitions for
Healthcare Applications. The Radiology Basic Security profile supports only BSD Syslog and
the IHE Provisional schema.
The purpose of this test is to have a Secure Node actor generate one event and communicate that
event to the Audit Repository. There are multiple steps to the test to differentiate those choices.
You only need to complete the step or steps that apply to you. You do need to complete at least
the first step (generate an event) and one of the following steps (send the message using a
combination of transport and schema definitions).
This test is preparation for later tests. Perform this test with each repository to make sure the
transport is working. Do NOT submit this test in the Kudu web tool; DO NOT ask a
Connectathon monitor for evaluation.
3.2.3
Actors
Secure Node
Audit Record Repository
3.2.4
Steps
Trans 0:
In the steps below, you will see repetition based on the profile (ATNA/SEC), the
type of transport chosen and the message format. Choose the lines that are
appropriate. Mark the others as not done. This is not a failure.
Trans 0:
Secure Node implements an action that produces an auditable event. The simplest
case is user login.
Rad-34:
Secure Node sends audit record to Audit Repository using BSD Syslog / IHE
Provisional schema.
ITI-20:
Secure Node sends audit record to Audit Repository using BSD Syslog / IHE
Provisional schema.
__________________________________________________________________________
9
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
ITI-20:
Secure Node sends audit record to Audit Repository using BSD Syslog / RFC
3881
ITI-20:
Secure Node sends audit record to Audit Repository using Reliable Syslog / IHE
Provisional schema.
ITI-20:
Secure Node sends audit record to Audit Repository using Reliable Syslog / RFC
3881
3.2.5
Evaluation
There is no evaluation for this. This will be evaluated in later, workflow tests.
3.3
3.3.1
ATNASecureWorkflow (Retired)
Special Instructions
This test will not be used at the January 2007 Connectathon.
3.3.2
Description
In the ATNASecureWorkflow test, two or more Secure Nodes communicate using secure
transactions as defined in the ATNA profile. Specifically, the Secure Nodes exchange certificates
using TLS and then continue communicating use the same socket connection.
3.3.3
Actors
Secure Node
3.3.4
Steps
3.3.5
Evaluation
3.4
3.4.1
ATNA_Employee_Tracking (Retired)
Special Instructions
This test will not be used at the January 2007 Connectathon.
This test is based on a use case involving events that take place during the connectathon. You
will need to finish the first part of the test by Tuesday 15:00, and the second part of the test on
Wednesday. That puts pressure on the testers to be ready at the start of the Connectathon.
__________________________________________________________________________
10
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
3.4.2
Description
Harpo and Groucho Marx are brothers working at the Large Hospital System (LHS). They have
login IDs of marxh and marxg. Groucho’s last day of work is Tuesday, and he will have all of his
accounts turned off Tuesday afternoon.
Each Secure Node should create and activate accounts for marxg and marxh for operation on
Monday morning.
On Monday and Tuesday morning, Groucho logs on to various secure systems. Each Secure
Node system should generate at least two audit events: login and some other event such as a
patient access event or data export.
Groucho fills out his retirement papers on Tuesday, and all Secure Nodes should deactivate the
marxg account on Tuesday at 15:00.
Groucho’s retirement party is at noon today, and all of his accounts on all systems have been
disabled.
On Wednesday, Groucho returns to LHS to visit his brother Zeppo who is in the hospital.
Groucho cannot get a straight answer from the physicians, and wants to examine Zeppo’s records
for himself.
Groucho visits each secure system in LHS and tries to login with his old account (marxg). That
fails, and the secure system sends a log message to the Audit Record Repository.
Groucho then pulls Harpo’s password out of his pocket (after all, what are brothers for?) and
logs in (marxh). The secure system sends a log message to the Audit Record Repository.
Groucho then views Zeppo’s record or performs some other action that will trigger an audit
record (use your imagination here; we do not know what each system does), and then logs out.
The LHS Security Manager gets a report of Groucho walking around the LHS and logging in to
various systems. He consults with the Audit Record Repository and asks for the following
reports:
1. Show me the log of all activity for Harpo in the last 7 days.
2. Show me the list of all login failures in the last 7 days.
3. Show me the log of all activity for Groucho in the last 7 days.
Secure nodes pass this test if they appear in the reports generated by the Audit Record
Repository.
This test is different than the usual Connectathon tests. A Connectathon monitor will play the
role of Groucho during the week and visit the Secure Nodes. The Secure Nodes should perform
the operations listed in the description. The monitor does not examine the log files of the Audit
Record Repository for individual records.
Starting on Tuesday, each Audit Record Repository is expected to produce the requested reports.
If the reports are not available, the ARR fails the test.
__________________________________________________________________________
11
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
If the report does not show the expected events from an individual Secure Node, that Secure
Node fails the test. Thus, we evaluate each Secure Node by examining a generated report at the
Audit Record Repository.
3.4.3
Actors
Secure Node
3.4.4
Steps
3.4.5
Evaluation
Connectathon monitor will evaluate the reports generated by the Audit Record Repository
answering the questions listed above. Audit Record Repository should generate reports on this
schedule:
Tuesday afternoon (after 15:00) should show normal behavior by Groucho
Wednesday at 12:00 should show abnormal behavior by Groucho on those Secure Nodes who
complete the test.
Wednesday
17:00
Thursday
12:00
Thursday
17:00
3.5
3.5.1
ATNA_VIP_Patient_Tracking (Retired)
Special Instructions
This test will not be used at the January 2007 Connectathon.
This test is based on a use case involving events that take place during the connectathon.
One Connectathon monitor will use the RIS Mall to generate a single Patient ID for our subject.
This Patient ID will be used by all systems to simplify reporting.
3.5.2
Description
It is Monday afternoon, and Harry Potter has just fallen off his broomstick while competing in
the final Quidditch match of the school year. Foul play is suspected, but a blinding light was cast
just at the instant Harry fell from the sky.
Harry has been taken to the infirmary under the watchful eye of Professor McGonagall. After a
full battery of tests, Harry is referred to St. Mungo’s Hospital for Magical Maladies and Injuries.
There he will see a specialist to determine if he is the victim of a spell.
All of the information systems at the Hogwarts School allow access to all patient records and use
auditing to detect undesirable behavior. Your Secure Node is one such information system.
__________________________________________________________________________
12
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
Determine some action that will trigger an audit record indicating someone on your system is
viewing a medical record for Harry Potter.
Create a character on your system, login with that character name and trigger the auditing event.
This should send the event to an Audit Record Repository. Perform this step by Wednesday,
17:00.
Professor Dumbledore suspects Hogwarts staff members are improperly trying to view Harry’s
records. He consults with the Audit Record Repository and asks for the following report:
1. Show me the log of all accesses to Harry Potter’s medical records in the last 7 days.
Secure nodes pass this test if they appear in the reports generated by the Audit Record
Repository.
Starting on Tuesday, each Audit Record Repository is expected to produce the requested reports.
If the reports are not available, the ARR fails the test. If the report does not show the expected
events from an individual Secure Node, that Secure Node fails the test. Thus, we evaluate each
Secure Node by examining a generated report at the Audit Record Repository.
3.5.3
Actors
Secure Node
Audit Record Repository
3.5.4
Steps
Trans 0:
Create an account on your system for someone who will access the Harry Potter
records.
ITI-20:
Login, generating a login audit message sent to the ARR
ITI-20:
Access Harry Potter PHI, generating an audit message to the ARR
3.5.5
Evaluation
Connectathon monitor will evaluate the reports generated by the Audit Record Repository
answering the questions listed above. Audit Record Repository should generate reports on this
schedule:
Tuesday
15:00
Wednesday
15:00
Thursday
10:00
Thursday
15:00
__________________________________________________________________________
13
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
3.6
ATNA_Fully_Secured_Node (Retired)
3.6.1
Special Instructions
This test will not be used at the January 2007 Connectathon.
ATNA or Basic Security Secure Nodes are required to protect all transactions with TLS
communication and generate audit messages for each actor where appropriate. For systems that
are combinations of several actors in several profiles, each actor in each profile must be secure
for this system to qualify as a secure node.
3.6.2
Description
This test is performed in the presence of a Connectathon monitor. You need to determine in
advance how you are going to demonstrate these actions.
1. Demonstrate TLS communication for each type of transaction for each actor/profile pair in
your system. For example, for a combined Image Manager (SWF) / XDS Repository (XDS),
you will have to demonstrate TLS communication for the Scheduled Workflow transactions
(Rad-4, Rad-6, Rad-8, Rad-14, Rad-16) and the XDS transactions (…).
2. For each actor/profile combination in your system, generate at least one audit record that is
appropriate. Send that audit record to a centralized Audit Record Repository designated by
the Connectathon monitor. This is a separate repository that is used only for this test and not
during the other tests.
When you are ready to run this test, the Connectathon monitor will clear the Audit Record
Repository so only your events are logged. As you run the test, you should indicate which audit
records should be recorded in the ARR. As the test progresses (or at the end), the Connectathon
monitor will review the records on the ARR and compare to your list.
3.6.3
Actors
Secure Node
Centralized Audit Record Repository
3.6.4
Steps
Trans 0:
Initiate and demonstrate TLS communication for each transaction
ITI-20:
Generate audit message for each actor/profile combination.
__________________________________________________________________________
14
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
3.6.5
Evaluation
Connectathon monitor will evaluate in real time with you during this test. You need to
demonstrate the appropriate TLS communication and logging to the central ARR.
3.7
ATNAMultipleEvents (Retired)
This test is now deprecated in favor of ATNAEmployeeTracking and ATNAFullySecuredNode.
3.7.1
Description
ATNAMultipleEvents tracks one user through a system performing multiple actions. These are a
login failure, successful login and access to a patient record of some kind. At least 3 audit
records should be generated and sent to the Audit Repository.
For the failure event, the user should try to login using a name that is easily identifiable with
your company/product. For example, himssxx would indicate the wrong login name for HIMSS.
For the successful login, select a user name that is alos easily identifiable with your
company/product (e.g., himss).
For the access event, you will need to select an action that causes your system to send an audit
record. These events could include access to a record, export of data, etc.
For evaluation, the Project Manager will examine the logs of the Audit Repository. One example
request: Show me a log of all of the login failures.
3.7.2
Actors
Secure Node
Audit Repository
3.7.3
Steps
Trans 0: Purposely fail with system login.
Trans ITI-20: Secure Node sends audit record to Audit Repository.
Trans 0: Correctly login to your system.
Trans ITI-20: Secure Node sends audit record to Audit Repository.
Trans 0: Perform some action that will generate an audit event.
Trans ITI-20: Secure Node sends audit record to Audit Repository.
__________________________________________________________________________
15
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA
ATNA/Basic Security Connectathon Test Cases
______________________________________________________________________________
3.7.4
Evaluation
Project Manager will examine log files of Audit Repository to check for evidence of the
requested events.
__________________________________________________________________________
16
Rev. 2007-2
11-Jan-2007
Copyright © 2006: ACC/HIMSS/RSNA