General Electric MUSE 7.0.2 ADVANCED SECURITY GUIDE_SM_2033425-029_A Operating Instructions VWR Air Jacketed CO2 Incubator

MUSE

™

Cardiology Information System

Advanced Security Guide

Software Version 7.0.2

2033425-029 Revision A

NOTE: The information in this manual only applies to MUSE software version 7.0.2. It does not apply to

earlier software versions. Due to continuing product innovation, specifications in this manual are subject to
change without notice.

MUSE™ and InSite™ are trademarks owned by GE Medical Systems Information Technologies, a General
Electric Company going to market as GE Healthcare. All other trademarks contained herein are the property
of their respective owners.

© 2006 General Electric Company. All rights reserved.

T-2 MUSE Revision A

2033425-029 29 September 2006

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Checklist for MUSE Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

MUSE Features Which Require Policies/Procedures . . . . . . . . . . . . . . . . . . . . . . . 1-4

Access Control Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Windows Authentication vs. MUSE Authentication . . . . . . . . . . . . . . . . . . . . . . . .1-6

Allow MUSE Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6

Unattended Workstation Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6

Accounting/Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Print Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8

Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9

Logging of System Security Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10

Disabling Remote Query & User Entered Destination . . . . . . . . . . . . . . . . . . . . . 1-11

MUSE Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12

Configure IIS to Log Web Site Activity on MUSE Web . . . . . . . . . . . . . . . . . . . .1-12

Setting Up Client Browser for 128-bit Encryption . . . . . . . . . . . . . . . . . . . . . . . . .1-13

Anti-Virus Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14

Microsoft Security Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15

Appendix A – HIPAA Overview . . . . . . . . . . . . . . . . . . . . .A-1

HIPAA Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

HIPAA Law Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

Privacy and Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

Electronic Health Transactions and Code Sets Standards . . . . . . . . . . . . . . . . . . A-7

HIPAA Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Policy and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-9

Achieving HIPAA Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-10

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

Revision A MUSE i

2033425-029

How HIPAA-Compliant Can Any Technology Be? . . . . . . . . . . . . . . . . . . . . . . . . A-12

Transactions Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-12

Privacy Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-12

Security Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-13

Overall... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-13

Appendix B – Summary of MUSE Security . . . . . . . . . . . .B-1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

Background Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

Network Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

Transactions, Code Sets, and Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4

Identify all of the identifiers this product supports . . . . . . . . . . . . . . . . . . . . . . . . B-4

User Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4

User Account Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5

Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6

Auto-Logoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

Device to Device Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

Log All Security Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

Log All Patient Data Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8

Log All Patient Data Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9

Log All Changes to the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10

Audit Log Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10

Audit Log Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10

Configuration Lockdown & Security Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11

AntiVirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12

Integrity Controls on Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12

Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13

Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13

De-Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13

ii MUSE Revision A

2033425-029

Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13

Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13

Appendix C – 21 CFR Part 11 Option . . . . . . . . . . . . . . . .C-1

Electronic Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

Other 21 CFR Part 11 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4

Disable Automatic Updates to Report Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-4

Revision A MUSE iii

2033425-029

iv MUSE Revision A

2033425-029

Introduction

Advanced Security Guide: Introduction

The MUSE Cardiology Information System (system) has several security
features which, when properly used and configured, can support USA
facilities in complying with the Health Insurance Portability and
Accountability Act (HIPAA) Security and Electronic Signature
Standards. These new security standards were designed to protect
patient’s health information from improper access, alteration, and loss
when it is maintained or transmitted electronically.

For more information on the HIPAA Security and Electronic Signature
Standards link to:

http://ge.com/hipaa

Compliance with the HIPAA Security and Electronic Signature
Standards cannot be attained solely through the use of the security
features on the MUSE system. Sites which use the MUSE system to
maintain and transmit patient health information must use the security
features in conjunction with a security plan which provides for the user
training and secure physical access to patient health information.

This document is provided to describe how to properly set up and use the
security features on the MUSE system. The responsibility of developing
the security plan for user training and secure physical access to patient
health lies with the end user.

If you have any questions or need assistance with any of these security
setups, call the Jupiter On-Line Center at 1-800-558-7044.

Revision A MUSE 1

2033425-029

Revision History

Advanced Security Guide: Revision History

Each page of the document has the document part number followed by a
revision letter at the bottom of the page. This letter identifies the
document’s update level. The revision history of this document is
summarized in the table below.

Table 1. Revision History, PN 2033425-029

Revision Date Comment

A 29 September 2006 Initial release of manual for version 7.0.2.

2 MUSE Revision A

2033425-029

Advanced Security Guide: Checklist for MUSE Security Features

Checklist for MUSE Security Features

When setting up security on the system, use the following checklist as a reminder of security features available on the system which
address both HIPAA and FDA 21 CFR Part 11 requirements. Shaded features are not required for 21 CFR Part 11 compliance but are
considered good security practices.

FDA

Requirement

Authentication

&

Authorization

Accounting

&

Tracking

MUSE Feature Configuration Recommended Solution

Access
Control Security

User
Authentication

Unattended
Workstation
Security

Windows Event
Log

Audit Trails Editor Security Enable the Change Log

Secure
Configuration

MUSE Users’
Password

Windows
Authentication

Logout or Lockout
Screen Savers

Audit Policy

Remote Query ‘Remote Query’ feature is disabled.
User Entered

Destination

MUSEAdmin, MUSEBkgnd, and MUSE Users’
passwords should adhere to facility’s best practice or
policy.

Windows Users should be mapped to MUSE Users.

“Allow Only Windows Authentication” option is installed

All workstations are configured to use “Logout Screen
Saver” or “Lockout Screen Saver.”

The Windows utility “Audit Policy” is set on MUSE Sever
and all workstations to log certain events.

“User Entered Destination” feature is disabled.





*












Web Encryption

&

Logging

Data Integrity Anti Virus

* Enabling of this feature requires the assistance of the Jupiter On-Line Support Center. Please dial 1-800-558-7044 to request

assistance with activating this feature.

MUSE Web

SSL Encryption

SSL Logging

Anti Virus
Software
Configuration

MUSE file server is set to use SSL to force 128-bit
encryption.

MUSE file server is set to use IIS to log MUSE Web
activities.

Anti-virus software is installed and properly configured
on MUSE file server and all workstations.







Revision A MUSE 3

2033425-029

Advanced Security Guide: MUSE Features Which Require Policies/Procedures

MUSE Features Which Require Policies/Procedures

The following MUSE features require policies and procedures to achieve
security compliance.

Policies and Procedures Required for HIPAA & 21 CFR Part II

Security Compliance

MUSE Feature

HL7 Device

Folder, FTP Folder, Email

MUSE API

Fax

Remote Query

Why a Policy/Procedure is

Needed

Patient Data leaving the
system, thus, no longer change
logging or protecting access of
records.

Patient Data leaving the
system, thus, no longer change
logging or protecting access of
records.

Data is leaving the system and
may not be under any security
control.

Faxed information can be
viewed by anyone, thus a policy
should be in place regarding
cover pages, and confidentiality
of patient information. Work
with your legal department in
developing these policies/
procedures.

Data is leaving the system and
may not be under any security
control.

Data is leaving the system and

Allowing users to enter destination

Policies and Procedures Required for 21 CFR Part II Security Compliance

Feature

Acquiring ECGs require Technicians to enter
ID Number at cart

4 MUSE Revision A

2033425-029

may not be under any security
control.

Why a Policy/Procedure is

Needed

Data leaves the system and not
under any security control

Advanced Security Guide: Access Control Security

Access Control Security

The MUSE system requires two Windows user accounts. One that is used
by GE Service to access and work on the system, and the other is used by
the system itself to run background Windows Services. This section of
the Advanced Security Guide describes these user accounts, how they are
used, and what the system requirements are for the accounts.

1. MUSEAdmin account. This account is used by GE Service to log into
the system to perform initial setup and configuration, and to provide
on-going service and support. This account needs to be a member of
the Administrators Group on the MUSE file server. The customer
should not use this account. For tracking and auditing reasons,
customers should use their own account. The MUSEAdmin account
should be a domain account whenever possible. As a workaround, it
can be an account local to the MUSE file server.

The password for the MUSEAdmin account can be determined by the
customer, but must be shared with GE Service so that they can use
that account when they work on the system.

2. MUSEBkgnd account. This account is used to start the MUSE
related background services on the MUSE file server. This account
needs to be a member of the Administrators Group on the MUSE file
server. This account should not be used by anyone for logging on to
the MUSE system. The MUSEBkgnd account should be a domain
account whenever possible. As a workaround, it can be local to the
MUSE file server.

The password for the MUSEBkgnd account can be determined by the
customer, but must be shared with GE Service so that they can use
that account when they work on the system.

The MUSEBkgnd account must not be subject to any policies that
would not allow the account the Logon As Service right, since that
right is a requirement for the account to be able to start the MUSE
related background services.

Passwords for the Windows MUSEAdmin and MUSEBkgnd user
accounts are changed through Windows like any other Windows user
account. Both accounts should have passwords that are set to never
expire. If the passwords change, GE Service may not be able to log into
the system to provide support, and the background services will fail to
start, causing the MUSE system to stop functioning.

All other users of the MUSE system can use their normal Windows user
credentials to access the MUSE system. Inside the MUSE application the
users are setup with their Domain\User account information, but no
password information is required when configuring a user. The user
passwords can be controlled or changed through Windows as required.

Revision A MUSE 5

2033425-029

Advanced Security Guide: User Authentication

User Authentication

Windows Authentication vs. MUSE Authentication

Using Windows Authentication on a MUSE workstation not only
eliminates a second logon using MUSE Authentication, but also supports
a higher level of security as is recommended to meet HIPAA compliance
standards.

MUSE authentication is most commonly used on a client workstation
that is shared by multiple users, and where those users do not want to
log out of Windows and log back in to run the MUSE application and be
recognized as a different user. Each person that runs the MUSE
application on the shared workstation can log into MUSE with their own
username and password. In order to help meet HIPAA compliance,
policies and procedures will need to be in place when using MUSE
authentication.

With Windows authentication, users are not required to log into the
MUSE application separately. When the MUSE application is launched,
MUSE will automatically log them in as the proper user, based on the
user that is logged into Windows on that computer. Windows
authentication supports a higher level of security as recommended to
meet HIPAA compliance standards.

Allow MUSE Authentication

By default, the system allows either MUSE or Windows Authentication.
To disable MUSE Authentication on the system so that Windows
authentication can be used, contact the Jupiter On-Line Support Center
at 1-800-558-7044, or contact your regional support center if you are
outside the United States.

If MUSE Authentication is allowed, it can be enabled at individual
workstations by adding the following switch to the shortcut that is used
to launch MUSE: -museauthenticate.

If MUSE authentication is disabled and a user tries to log in using
MUSE authentication, a message will appear stating MUSE
authentication is not enabled. If a user is logged into the system using
their correct Windows authentication, an error message appears, but
they will be allowed into the system. If a user is logged into a system as a
different user and logs in using MUSE authentication, the error message
appears and they will not be allowed into the system.

Unattended Workstation Security

There are two options available to you for setting up logout/lockout
security on workstations which are left unattended for a specified
amount of time. The two options are:

6 MUSE Revision A

2033425-029

Advanced Security Guide: User Authentication

1. Logout. When workstation is inactive (no mouse or keyboard input)
for the specified amount of time, the current user is logged off
Windows and the MUSE session is ended.

2. Lockout. When workstation is inactive for the specified amount of
time, the screen saver selected in the Control Panel is activated.

The table below summarizes these two options for unattended
workstation security. Be sure you understand how each option impacts
the user before choosing one of these options. Inform all system users
about how the unattended workstation security option affects their use of
the system.

Table 2. Differences Between the Two Options for Unattended Workstation Security

Item

Logout Screen Saver

WINEXIT

Lockout Screen Saver

Logon with Password Protected

Access will be terminated after predetermined time of inactivity Yes Yes
Require authentication to log back into system Yes Yes
Workstation is locked No Yes

Users can unlock workstation N/A

MUSE application exit Yes

 Last user
 Administrator

 No, if Last user unlocks the workstation
 Yes, if Administrator unlocks the

workstation

 No, if Last user unlocks the workstation

Lose unsaved changes Yes

 Yes, if Administrator unlocks the

workstation

*

Possibility of locking record that was being edited when
screen saver took control.

Yes

 No, if Last user unlocks the workstation
 Yes, if Administrator unlocks the

workstation

* If a record is locked, a message will be displayed indicating the record is being used by another workstation. The message will

display the Node ID of the workstation that has locked the record. To unlock the record, a user with sufficient privileges can logon
the workstation which has locked the record and start the MUSE application.

Revision A MUSE 7

2033425-029

Advanced Security Guide: Accounting/Logging

Accounting/Logging

Print Log

Outbound events refers to data that is sent out of the system, such as
patient tests, reports, sending out lists for printing, etc.

The system logs the following outbound events:

Printing to Postscript and PCL printers
Fax
CSI
Email
HL7
Folder
FTP Folder

These outbound events can be viewed in the Print Log. To open the Print
Log, select Status > Print Log.

Refer to the MUSE Operator Manual for instructions on configuring the
Print Log.

8 MUSE Revision A

2033425-029

Change Log

Advanced Security Guide: Accounting/Logging

The Change Log tracks changes to patient data, and can be viewed in
Clerical, Clinical ECG and Enhanced layouts of the Report Editor. Click

to open the Change Log window.

Edit Change Log

Process Log

003

Each time a change is made to a patient test, the changes are recorded.
After a test has been updated or saved in the database, the changes are
saved by date.

The Edit Change Log is a list of changes made to a test's Patient ID,
Name, Test Time or Site. The log exists to facilitate finding a test that
had incorrect data entered at the device and has since been corrected at
the system. Refer to the MUSE Operator Manual for detailed
information.

The Process Log is a list of all of the processes that have run on the
system. This log includes processes that are currently running and those
that have terminated successfully. Current processes can be identified
because they do not have an end time. Processes with an old start time
and no end time can be used to identify bad processes. Refer to the
MUSE Operator Manual for detailed information.

Revision A MUSE 9

2033425-029

Advanced Security Guide: Accounting/Logging

5

Logging of System Security Events

The MUSE file server and workstations should be configured to log
Windows security events to the Windows Viewer. At each file server and
workstation, repeat the following steps to set up this audit.

1. Click Start > Programs > Administrative Tools > Local Security
Policy. The Local Security Settings window appears.

2. Select Local Policies > Audit Policy.

3. Click on each event and select the checkboxes indicated in the table
below.

Event Success Failure

Audit account logon events
Audit account management
Audit directory service access
Audit logon events
Audit object access
Audit policy change
Audit privilege use
Audit process tracking
Audit system events

4. Click OK to save your changes.

99

9
9

99

9

99

9
9

99

00

5. Close the Local Security Settings window.

10 MUSE Revision A

2033425-029

Advanced Security Guide: Disabling Remote Query & User Entered Destination

Disabling Remote Query & User Entered Destination

1. Select System > Setup > Sites > Properties. Highlight Advanced.

Uncheck to
disable CSI
Remote Query

Uncheck to disable
user entered
destinations

2. To disable remote query, uncheck the Enable CSI Remote Query
checkbox.

3. To disable printing to temporary devices, uncheck the Enable User
Entered Destination checkbox.

4. Click OK.

5. Repeat for each site on the system.

004

Revision A MUSE 11

2033425-029

Advanced Security Guide: MUSE Web

MUSE Web

IIS is installed on the MUSE Web server. In order to access the MUSE
Web, the user must have their browser configured for 128-bit encryption.

For detailed procedures, see “MUSE Web Server Instruction Guide to
Enabling SSL.”

Configure IIS to Log Web Site Activity on MUSE Web

MUSE file server should be configured to enable logging web site activity
as follows:

1. Right-click My Computer and select Manage.

2. Expand Services & Application > Internet Application Services >
Websites in the list found in the Tree list (left panel).

3. Right-click on MUSE Web Site and select Properties in the Web Site
tab.

4. Ensure that Enable Logging is checked in the Web Site tab.

5. For Active log format, make sure it is W3C Extended Log File Format.

6. Select Properties....

 Select the General tab.

 Select Weekly for New Log Time Period.

 Make sure Log file directory is

%WinDir%\System32\LogFiles.

 Select Advanced tab.

 Add/delete/verify checkmarks to obtain the following Extended

Logging Options.

Date

9

Time

9

Client IP Address

9

User Name

9

P Service Name

Server Name

9

Server IP

9

Server Port
Method

9

9

URI Query
Http Status

Win32 Status
Bytes Sent
Bytes Received
Time Taken
Protocol Version
User Agent
Cookie
Referred

 Click OK to close the Logging Properties window. Click OK again

to close the Web Site Properties.

12 MUSE Revision A

2033425-029

Advanced Security Guide: MUSE Web

Setting Up Client Browser for 128-bit Encryption

MUSE Web server will allow only 128-bit encryption accesses. Users will
need to update their Internet Explorer (IE) 5.0 or 6.0 to have “High
Encryption Pack” installed.

NOTE

The High Encryption Pack can be downloaded from the Microsoft
web site.

The steps below describe how to determine the IE encryption level.

1. Start Internet Explorer.

2. Select Help > About Internet Explorer.

3. If Cipher Strength is less than 128-bit, you will need to install High
Encryption Pack.

Revision A MUSE 13

2033425-029

Advanced Security Guide: Anti-Virus Software

Anti-Virus Software

GE has validated the proper operation of the system with Norton Anti­Virus Corporate Edition and McAfee NetShield installed. Either of these
two virus protections software applications can be installed on the
system without affecting function or performance.

Anti-virus software is not provided with the system and it remains the
customer’s responsibility to acquire and install anti-virus software on
their system per the recommendations of the manufacturer of the anti­virus software.

See the MUSE Pre-Installation Manual for additional information on
installing anti-virus software on the system. When properly used, anti­virus software can protect the system from virus infection and the
subsequent data corruption which can result from a virus infection.
However, if improperly configured, anti-virus software can cause system
degradation.

14 MUSE Revision A

2033425-029

Advanced Security Guide: Microsoft Security Updates

Microsoft Security Updates

A list of viruses that pose a significant threat to GE customer product
security are posted on the GE Healthcare Security web site.
Vulnerability notification to customers will occur through the web site.
After security patches have been validated with GE Healthcare products,
this information will be included in a memo which can be downloaded
from the GE Healthcare web site. A validated security patch can then be
downloaded directly from the Microsoft web site and applied to the
customer’s GE product.

To check on the latest information regarding validated security patches:

1. Browse to the following site:

http://www.gehealthcare.com/usen/security/products/
modality_links.html

2. Login with your SSO (Single Sign On) username and password.

NOTE

If you are not within the firewall, you will be prompted to
register the first time you visit this site.

3. Then, click on the link for the security information for Diagnostic
Cardiology. This bulletin includes security patch information for
products made by the Diagnostic Cardiology modality of GE
Healthcare which require security patches. This list includes the
security patches which have been validated for

the system.

Revision A MUSE 15

2033425-029

For your notes

Advanced Security Guide: Microsoft Security Updates

16 MUSE Revision A

2033425-029

Appendix A – HIPAA Overview:

A Appendix A – HIPAA

Overview

Revision A MUSE A-1

2033425-029

Appendix A – HIPAA Overview: HIPAA Introduction

HIPAA Introduction

The future of health care in the United States changed on August 2, 1996
when the Health Insurance Portability and Accountability Act (HIPAA)
became law. The complex and far-reaching federal legislation
significantly affects every person and organization involved in health
care. HIPAA rules spell out standards and requirements for protecting
the confidentiality, security, and integrity of all health information.

A-2 MUSE Revision A

2033425-029

Appendix A – HIPAA Overview: HIPAA Law Overview

HIPAA Law Overview

The primary goals of HIPAA are quantification of consumer health care
rights along with improved privacy and security of medical records. The
two main components of HIPAA are Health Care Portability and
Administrative Simplification. The Health Care Portability legislation
became effective in 1996. The Portability part of HIPAA is well
understood and was successfully implemented by the US government
and the medical industry in 1996 and 1997. The Portability legislation
guarantees the following rights to health care consumers:

 Improved availability and accessibility of health insurance

 Guaranteed right of portability and continuity of health insurance

coverage for individuals and groups

 Prohibits discrimination based on health status

HIPAA’s Administrative Simplification provision is composed of four
parts and involves these health care issues:

 Standardization of electronic transfers of patient health,

administrative and financial data

 Privacy and security standards protecting the confidentiality and

integrity of health information

 Unique health identifiers for individuals, employers, health plans

and health care providers

Each part will eventually produce a variety of rules and standards. Many
of the rules and standards are under development. As the rules and
standards are finalized and become law they will have different
compliance deadlines. The four parts of Administrative Simplification
are:

1. Electronic Health Transactions Standards

2. Unique Identifiers

3. Security & Electronic Signature Standards

4. Privacy & Confidentiality Standards

HIPAA’s complexity confuses customers. Even the HIPAA name causes
confusion. Recently the meaning of the moniker HIPAA changed.
Initially HIPAA referred to all parts of the legislation. Current usage
narrows HIPAA’s meaning to the rules generated from the
Administrative Simplification subsection. GE Medical Systems
Information Technologies follows common usage and unless otherwise
noted HIPAA refers to the rules developed from the Administrative
Simplification subsection.

Revision A MUSE A-3

2033425-029

Appendix A – HIPAA Overview: HIPAA Law Overview

The main components of HIPAA and their relationships are presented in
Figure 1 below.

HIPAA Act of 1996

Health Care Portability

- Availability & Accessibility
Of Health Insurance

- Continuity of Health
Insurance Coverage

- Prohibits Discrimination
Based on Health Status

Administrative Simplification

(Now called HIPAA)

- Privacy & Security of Health Records

- Standardization of Electronic Transfers

- Unique National Identifiers

Transaction Standard

Privacy Standard

Identifiers Standard

Security Standard

Figure 1. HIPAA Components

The HIPAA component with the greatest impact on GEMS-IT customers
is the Privacy Standard. The Privacy Standard is defined in the
Administrative Simplification subsection. The Final Version of the
Privacy Standard, (Standards for Privacy of Individually Identifiable
Health Information, 45 CFR Parts 160 and 164), was published in the
Federal Register on December 20, 2000.

A-4 MUSE Revision A

2033425-029

Appendix A – HIPAA Overview: HIPAA Law Overview

The HIPAA implementation and enforcement schedule spans several
years. The Privacy Standard becomes enforceable on April 14, 2003.
Table 1 summarizes the HHS release status and timetable for the
HIPAA rules.

Table 1. HIPAA Rules and Rulemaking Timetable

Standard Publication Date Final Ruling

Required

Compliance

1. Insurance Portability Aug 02, 1996 Aug 02, 1996 Jul 01, 1997

2. Electronic Transactions & Code Sets

*

May 07, 1998 Aug 17,2000 Oct 16, 2003

3. Privacy & Confidentiality Nov 03, 1999 Dec 28, 2000 Apr 14, 2003

4. National Provider Identifier May 7, 1998 Expected 2002 –

5. National Employer Identifier Jun 16, 1998 Expected 2002 –

6. Security Aug 12, 1998 Expected 2002 –

7. National Health Plan Identifier In Development – –

8. Claims Enforcement Procedures In Development – –

9. National Individual Identifier

**

Withdrawn – –

* In January, 2002 the Bush Administration extended the deadline for the ‘Electronic Transactions & Code Sets’ from Oct 2002

until October 2003.

** Although the HIPAA law called for a unique health identifier for individuals, HHS and Congress indefinitely postponed any effort

to develop such a standard. (HHS Fact Sheet, Administrative Simplification, 2001)

Revision A MUSE A-5

2033425-029

Appendix A – HIPAA Overview: Privacy and Confidentiality

Privacy and Confidentiality

The Final Rule for Privacy was published December 28, 2000.
Compliance will be required on April 14, 2003 for most covered entities.
In general, privacy is about who has the right to access personally
identifiable health information. The rule covers all individually
identifiable health information in the hands of covered entities,
regardless of whether the information is or has been in electronic form.
The Privacy standards limit the non-consensual use and release of
private health information; give patients new rights to access their
medical records and the right to know who else accessed them; restrict
most disclosure of health information to the minimum needed for the
intended purpose; establish new criminal and civil sanctions for
improper use or disclosure; establish new requirements for access to
records by researchers and others.

The Privacy and Confidentiality regulations incorporate five basic
patient rights related to health care information:

 Consumer Control: The regulation provides consumers with critical

new rights to control the release of their medical information

 Boundaries: With few exceptions, an individual’s health care

information should be used for health purposes only, including
treatment and payment.

 Accountability: Under HIPAA, for the first time, there will be specific

federal penalties if a patient’s right to privacy is violated.

 Public Responsibility: The new standards reflect the need to balance

privacy protections with the public responsibility to support such
national priorities as protecting public health, conducting medical
research, improving the quality of care, and fighting health care
fraud and abuse.

 Security: It is the responsibility of organizations that are entrusted

with health information to protect it against deliberate or
inadvertent misuse or disclosure.

A-6 MUSE Revision A

2033425-029

Appendix A – HIPAA Overview: Electronic Health Transactions and Code Sets Standards

Electronic Health Transactions and Code Sets Standards

Health care organizations routinely store and transmit medical
information in electronic format. Electronic medical information is
manipulated through a wide variety of encoding schemes and formats.
Standard electronic data interchange improves the efficiency of health
care delivery. National standards make it easier for health plans,
doctors, hospitals and other health care providers to process claims and
other transactions. (HHS Fact Sheet, Administrative Simplification,

2001) The government and the medical industry perceive standardized
representations of routine medical data as beneficial for all parties
involved. The Transactions Standards mandates use of standardized
electronic formats developed by ANSI, the American National Standards
Institute. The Code Set Standards require use of the most commonly
used medical terminology code sets. Final standards for electronic
transactions and code sets were released in Aug 2000. The original
compliance deadline of October 2002 was extended to October 2003.

The Transactions Standards specify the format and content of the
following medical transactions:

 Health claims or equivalent encounter information transfer

 Health claims attachments

 Enrollment and disenrollment actions in a health plan

 Eligibility status in a health plan

 Health care payment and remittance advice

 Health plan premium payments

 First report of injury

 Health claim status

 Referral certification and authorization

The Health organizations must adopt standard code sets for all health
transactions. Code sets are alphanumeric identifiers representing
medical data. Medical coding systems describe diseases, injuries, and
other health problems, as well as causes, symptoms and actions taken.
All parties exchanging medical transactions must generate and accept
the same coding. Consistent coding reduces mistakes, duplication of
effort and costs. HIPAA specifies the following commonly used code sets:

1. International Classification of Diseases, 9th Edition, Clinical
Modification, (ICD-9-CM), Vols 1, 2, 3

2. National Drug Codes (NDC)

3. Code on Dental Procedures and Nomenclature,

4. Health Care Financing Administration Common Procedure Coding
System (HCPCS)

5. Current Procedural Terminology, Fourth Edition (CPT-4),

The Transactions Standards regulate information related to health
insurance status and remittance. GEMS-IT cardiology information

Revision A MUSE A-7

2033425-029

Appendix A – HIPAA Overview: Electronic Health Transactions and Code Sets Standards

system products are clinical systems and rarely (if ever) process the
health insurance and remittance information affected by the
Transactions Standards. The GE Medical Systems Information
Technologies cardiology information system products are not affected by
the Transactions Standards.

The Code Set Standards regulate use of clinical medical information. The
Code Set Standards may affect GE Medical Systems Information
Technologies cardiology equipment. The cardiology equipment may need
to support input of code set values when test information is acquired.

A-8 MUSE Revision A

2033425-029

Appendix A – HIPAA Overview: HIPAA Compliance

HIPAA Compliance

HIPAA compliance is achieved through a combination of changes to
‘policy and procedure’ and the purchase of HIPAA enhanced hardware,
software, and other technologies. No product can independently confer
HIPAA compliance rather the product must fit into a customer specific
HIPAA compliance scheme. Technology updates and ‘policy and
procedure’ changes are pieced together by customers into a unique and
site specific HIPAA compliance solution. The precise mechanisms for
achieving HIPAA compliance are left to the covered entities. HIPAA does
not mandate specific vendor equipment or mechanisms for achieving
compliance. The HIPAA implementers are free to create the systems that
enable compliance as they see fit. The HIPAA implementers must decide
how much of the compliance will come from new and upgraded
technology versus the amount achieved via changing ‘policy and
procedure’. HIPAA expects a majority of the compliance can be achieved
through ‘policy and procedure’ changes and the remaining compliance
achieved via deployment of new and updated technology. The authors of
the HIPAA provided guidance concerning policy and procedure in the
Federal Register (Dec 28, 2000):

Policy and Procedures

The rule requires that covered entities develop and document policies
and procedures with respect to protected health information to establish
and maintain compliance with the regulation. Through the standards,
requirements, and implementation specifications, we are proposing a
framework for developing and documenting privacy policies and
procedures rather than adopting a rigid, prescriptive approach to
accommodate entities of different sizes, type of activities, and business
practices. Small providers will be able to develop more limited policies
and procedures under the rule, than will large providers and health
plans, based on the volume of protected health information. We also
expect that provider and health plan associations will develop model
policies and procedures for their members, which will reduce the burden
on small businesses.

The myriad of HIPAA compliance solutions presents a difficult challenge
to customers. Customers want to stay focused on their primary job of
providing quality health care. Customers expect vendors to provide
detailed HIPAA guidance tailored to the customer’s unique security
needs and health care environment.

Revision A MUSE A-9

2033425-029

Appendix A – HIPAA Overview: HIPAA Compliance

Achieving HIPAA Compliance

Achieving HIPAA compliance is a top-down process of learning, planning
and implementing. Health care institutions must become intimately
familiar with HIPAA rules. The HIPAA implementer must conduct a
self-analysis to determine how HIPAA fits into their unique situation.
The HIPAA rules must be broken down into understandable categories
and tasks. Many internal stakeholders must be consulted in order to
ensure full compliance. Once a plan is in place then the HIPAA-enabling
technology is purchased and the ‘policy and procedure’ documents
created. The last stage is integration and deployment of all the HIPAA
mechanisms followed by an audit, ensuring compliance. The HIPAA
compliance effort requires strong commitment and detailed planning.
The American Health Information Management Association (AHIMA)
created the HIPAA Privacy Checklist (2001) to guide to HIPAA
implementers:

 Get management commitment

 Appoint HIPAA team

 Perform GAP analysis

 Understand current security policy and IT practices

 Perform risk analysis

 Draft required policies, procedures, and consents

 Obtain needed HIPAA-enabling technology

 Deploy ‘policy and procedure’ and technology

 Audit HIPAA policies, test privacy measures, test security measures

GE Medical Systems Information Technologies can advise and add value
at each phase of HIPAA implementation.

A-10 MUSE Revision A

2033425-029

References

Appendix A – HIPAA Overview: References

General Electric Medical Systems HIPAA Overview:

http://ge.com/hipaa

Dept. of Health and Human Services, Office of the Secretary, (Dec 28,

2000). Standards for Privacy of Individually Identifiable Health

Information, Comments and Rules, 1535 pages, Federal Register 45 CRF
Parts 160 through 164, p 82783

http://www.hhs.gov/ocr/fedreg.zip

Dept. of Health and Human Services, Office of the Secretary, (Dec 28,

2000). Standards for Privacy of Individually Identifiable Health

Information, Rules only 40 pages, Federal Register 45 CRF Parts 160
through 164, p 82783

http://aspe.os.dhhs.gov/admnsimp/final/PvcTxt01.htm

HHS Fact Sheet: Administrative Simplification Under HIPAA: National
Standards For Transactions, Security And Privacy. (May 11, 2001).
Retrieved from U.S. Department of Health and Human Services Web
site:

http://www.hhs.gov/news/press/2001pres/01fshipaa.html

Quarterly Industry HIPAA Survey Results - Summer 2001. (Aug 6,

2001). Retrieved Aug 10, 2001, from Phoenix Health Systems

HIPAAdvisory Web site:

http://www.hipaadvisory.com/action/survey/summer01.htm

HHS FAQ Sheet: The Rule Making Process for Administrative
Simplification: What Is Taking So Long? (July 2, 1999)
Retrieved from U.S. Department of Health and Human Services Web
site:

http://aspe.os.dhhs.gov/admnsimp/8steps.htm

HIPAA Primer, Retrieved Nov 29, 2001,from Phoenix Health Systems
HIPAAdvisory Web site:

http://www.hipaadvisory.com/regs/HIPAAprimer1.htm

HIPAA Privacy Checklist, Retrieved Aug 10, 2001, from the American
Health Information Management Association Web site:

http://www.ahima.org/journal/pb/01.06.1.html

Information on Microsoft solutions for the healthcare industry and for a
copy of Microsoft’s HIPAA Technical White Paper.

http://www.microsoft.com/business/health

Revision A MUSE A-11

2033425-029

Appendix A – HIPAA Overview: How HIPAA-Compliant Can Any Technology Be?

How HIPAA-Compliant Can Any Technology Be?

By Roy Rada, M.D., Ph.D.
Department of Information Systems
University of Maryland, Baltimore County

American history has witnessed a myriad of compliance activities; some
we might point with pride to, such as the 1906 Pure Food and Drug Act,
resulting from Dr. Harvey Wiley’s efforts to regulate the content of food.
However, the role of government in regulating business in the US has
often been accompanied by controversy and debate.

HIPAA has proved to be another battleground for compliance. Without
going further into the history, politics, law, or ethics of compliance, let’s
address the seemingly simple question of whether information
technology can be compliant with HIPAA.

How many times have you heard a vendor tout ‘my technology is HIPAA
compliant’? Some providers and payers are demanding to get HIPAA
compliant technology. Claims are commonly made by salespeople that
their product is HIPAA compliant. What’s the scoop here?

Transactions Rule

Direct compliance with HIPAA’s administrative simplification provisions
is not practical because the law itself is too indirect. It calls for rules to be
developed and enforced by the executive branch of the federal
government. Furthermore, the rules are diverse and cover, at least,
transactions, privacy, and in proposed-form security.

Might an IT vendor rightfully claim to be compliant with the
Transactions Rule? ‘Transaction’ refers in the HIPAA-context to
provider-payer transaction. The Transactions Rule calls for compliance
with certain standards, particularly X12 formats. A health care
provider might want to use information systems that support message
formats to payers that are compliant with X12, and a vendor could claim
to provide such X12-compliant forms.

This is not to say that the entity buying the technology would have an
instant fix to its ‘Transactions’ compliance problem. The Transactions
Rule goes beyond the X12 formats to specify the codes that have to be
used inside the fields of the format. Achieving compliance with some
coding requirements may entail changes in behavior. However,
technology could enforce the use of Transaction Rule formats and codes
and thus support compliance with the HIPAA transaction rule.

Privacy Rule

Privacy calls for changes in the way an entity manipulates information.
This is largely an administrative rather than a technical issue.
However, a technology can support the options for manipulating
information and be a vital support of the entity behavior. The
technology should support behavior consistent with the Privacy Rule.

A-12 MUSE Revision A

2033425-029

Security Rule

Appendix A – HIPAA Overview: How HIPAA-Compliant Can Any Technology Be?

The Privacy Rule calls for information systems that represent and audit
workflow. Exactly what the workflow should be is not precisely defined.
The approach of the Privacy Rule is like the ISO (the pre-eminent
international standards organization) approach to quality in ISO 9000.
ISO 9000 says that an organization should be clear in its goals and work
consistently to those goals. ISO 9000 does not say what the organization­specific goals should be, but an organization can be certified as ISO 9000
compliant. To be ISO 9000 compliant an organization must document its
objectives and document that its activities take it towards its objectives –
nothing more. The Privacy Rule goes beyond ISO 9000 in specifying
broadly what some of the privacy objectives are but then asks entities to
be quality organizations as respect to those objectives.

Entities must document working towards privacy objectives. Certifying
compliance for privacy would require an analysis of the organizational
manual and the way the organization implemented its manual. An IT
tool should help a health care entity have and follow the appropriate
organizational manual but the tool would not make the entity HIPAA
compliant.

Overall...

No security rule has been finalized for HIPAA. Yet, security is the topic
that comes closest to what an IT vendor feels is the special turf of the
vendor. The typical health care entity may be violating various security
mandates, such as transmitting information over the Internet in
encrypted form. A vendor can provide tools that encrypt messages before
sending them across the Internet.

The proposed security rule gives objectives of secure transmissions,
reliable authentication, contingency preparations, and much more.
However, the proposed rule gives flexibility to organizations in their
choice of ways to achieve the objectives and is neutral about particular
technologies. The compliance argument about security is not dissimilar
to the argument about privacy: when an organization uses a technology
in a certain way to reach a certain objective, then the organization will
have behaved in a compliant way as regards that HIPAA security
objective.

The bottom line is that Administrative Simplification is about
Administration, and technology can support that administration – but
not replace it. An information technology vendor should help its clients
understand what parts of HIPAA compliance are supported by the
vendor’s technology. But it should not claim that the technology is
HIPAA compliant.

Revision A MUSE A-13

2033425-029

Appendix A – HIPAA Overview: How HIPAA-Compliant Can Any Technology Be?

A-14 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security:

B Appendix B – Summary

of MUSE Security

Revision A MUSE B-1

2033425-029

Introduction

Appendix B – Summary of MUSE Security: Introduction

The following table is based on a MUSE system with 7.0.2 software with
no MUSE Web option. These tables are in direct response to the need for
security features in medical systems. GE provides these answers to
assist you in discovering your risks and in the creation of your mitigation
plan. GE provides these answers to the best of our knowledge given the
requirements and current state of the product.

This document contains a summary of the Legal Requirements of Health
Insurance Portability and Accountability Act (HIPAA). It is not intended
as legal advice. Every entity must make its own judgment regarding
what will be required to enable it to comply with HIPAA. General
Electric Company reserves the right to make changes in specifications
and features shown herein, or discontinue the product described at any
time without notice or obligation. Contact your GE representative for the
most current information.

B-2 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security: Background Information

Background Information

Enter any description that helps clarify the security context. The security context would include product options,

Unknown

environmental conditions, intended
Does the product Capture, Store, or Transmit any Patient identifiable data? Yes
Identify the architecture that best describes this product: 3 tier

application
What Operating System is this product Client based on? Windows XP
What Operating System is this product based on (or in the case of client/server products -- what is the server)? WIN2003
Which GSP Platform does the product utilize? None
Can the product display a customer supplied message on boot up or login? Yes & No,

the

application

cannot, but

Windows can

at login
Does the product provide a training mode that allows for training without corrupting the operational data? No

Network Presence

Does this product have a communications/network interface (Not including Remote Service)? Yes
Identify all of the Communications interface that this product has:

Ethernet Yes
Token-Ring No
ATM No
RF (802.11, blue tooth, other radio) No
COTS Modem Yes
Other Modem (eg SDLC) No
Direct Serial Yes
Other No

Does this product have a Database? Yes, SQL

Server 2005
Identify all of the Services/Protocols the product provides:

Any Direct Network db Access (JDBC, ODBC, SQL, etc) Yes
DICOM No
HL7 Yes
XML Yes
Hill Top Yes
Unity No
AdvantageNET No
PostScript or PCL printers Yes

Revision A MUSE B-3

2033425-029

Appendix B – Summary of MUSE Security: Transactions, Code Sets, and Identifiers

SMTP or MAPI Yes
FAX Yes
SNMP Yes
FTP Yes
Telnet / X windows No
Share (NFS, SMB, etc) Yes
Customer Accessible API? Yes
Other No
None No

Identify the modes of Network Communications of Patient Identifiable Data that is supported using the above protocols:

Send Patient Identifiable Data to other systems Yes
Receive Patient Identifiable Data from other systems Yes
Provide a Query interface that other systems can use to extract Patient Identifiable Data Yes

Does this product have a Web Server? Yes

Transactions, Code Sets, and Identifiers

Identify all of the Code Sets this product sends or receives:

non-standard equivalents to X12N Transactions (Billing EDI transactions)? No
standard X12N Transactions (Billing EDI transactions)? No
non-standard equivalents to CDT code sets (Dental Services)? No
standard CDT code sets (Dental Services)? No
non-standard equivalents to CPT4 code sets (Physician services)? No
standard CPT4 code sets (Physician services)? No
non-standard equivalents to ICD9 code sets (Diseases, injuries, etc)? No
standard ICD9 code sets (Diseases, injuries, etc)? No
non-standard equivalents to NDC code sets (Drugs and Biotics)? No
standard NDC code sets (Drugs and Biotics)? No
non-standard equivalents to HCPCS code sets (other services)? No
standard HCPCS code sets(other services)? No
User (soft) configured codes that may be configured to include CDT, CPT4, ICD9, NDC, or HCPCS? Yes
None of the above No

Identify all of the identifiers this product supports

“National Provider Identifier” (USA Unique identifier for all individuals providing healthcare services)? No
“National Employer Identifier” (USA Unique identifier for all healthcare facilities)? No
“National Payer Identifier" (USA Unique identifier for all insurance carrier)? No
None of the above Yes

User Identification

B-4 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security: User Account Maintenance

Does the product provide for individual identification (accounts) of clinical users (excluding service users)? Yes
What is the maximum number of accounts (0<zero> ==> theoretically infinite) 10,000
Does the product support passwords for authentication of the clinical users? Yes
Does the product utilize the operating system authentication for clinical users? Yes
Does the product place constraints on username? 16 char. max
Identify all of the authentication technologies this product supports

Windows Domain Yes
Microsoft Active Directory Yes
Non-Windows Kerberos No
NIS / YP No
CCOW No
Other No
None No
During login does the product inform the user of the last time the system was accessed using that user account? No
Can the user authentication be augmented by a biometric, token, or other method besides passwords? Yes

Identify all of the advanced authentication the product supports:

tokens Yes
smart cards Yes
badge readers No
written signature verification No
one-time password generators No
biometric identifiers No
Certificate identification No
dial-back modems No
Other No
None No

How does the customer get these advanced authentication methods? Customer

supplied

User Account Maintenance

Identify all of the information associated with a user account:

Full Name Yes
Additional Identifier Yes
Title Yes
Department No
Phone Number Yes
E-mail Address Yes

Revision A MUSE B-5

2033425-029

Appendix B – Summary of MUSE Security: Authorizations

Street Address No
FAX Number Yes
Other No
None No

Who Can administer user accounts? Multiple

Accounts
Identify all of the User Administrative controls supported

Audit Log of all account changes No
Set an account inactive without removing the account? Yes
Force a logoff of an active user? No
Automatic de-activation of an account on a specified date or number of days/time? No
Automatic de-activation of an account after a configured number of days of non-use? No
Other No
None No

Identify all of the User Account Reports supported:

List of all user accounts Yes
List of currently active users Yes
List of all user accounts with last used date/time No
Other No
None No
When an account is marked inactive or deleted does the product disable in real-time any active sessions using that ID? Yes
Does the product provide a tool for batch management of user accounts? Yes

Authorizations

Does the product support multiple levels of access control that can be assigned to user accounts? Yes
Does the product support multiple levels of access control that can be assigned to groups of user accounts? Yes
Identify all of the access control rights that can be applied to a user:

View Patient Identifiable Data on screen Yes
Print Patient Identifiable Data to paper or film Yes
Modify Patient Identifiable Data Yes
Export Patient Identifiable Data to removable digital media No
Delete Yes

Identify all the methods by which the access control right are applied:

Access at database view level No
Access at file level No
Access at file system directory level No
Time-of-Day No

B-6 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security: Auto-Logoff

Weekly Schedule No
Workstation (location) No
Other Yes
None No

Does product hide functionality that the user does not have rights to (to prevent the user from even knowing a functionality

Yes
exists)?

Does the product further restrict access based on patient specific consent? No

Auto-Logoff

Identify all of the inactivity Auto Logoff capability supported:

Unprotected Screen Saver Yes
Password protected Screen Saver (screen blanking) Yes
Application Logout No
Application blanking, with re-authentication allowing continuation. No
Other No

None No
Can the administrator override any inactivity screen/application blanking? Yes
Identify how the inactivity timeout can be configured:

System Wide No

Workstation (location) Yes

Per-User Yes

Device to Device Authentication

Identify all of the entity authentication that is used, when communicating and the remote user is not or can not be
authenticated serial number

Mac address No

IP Address No

AE-Title No

Process identifier No

Task identifier No

Unidirectional PKI certificate challenge (ex: simple SSL) No

Bidirectional PKI certificate challenge (ex: client and server auth SSL) No

Other No

None Yes

Log All Security Events

Identify all of the Security Events that can be logged:

Machine Shutdown Yes

Machine Boot Yes

Revision A MUSE B-7

2033425-029

Appendix B – Summary of MUSE Security: Log All Patient Data Views

Application start Yes

Application stop Yes

Network link/connection failures Yes

Data Integrity failure No

Successful User Login Yes

Failed User Login Yes

User Logout Yes

Auto-Logoff Yes

Forced logoff by administrator No

A user changed their password Yes

An admin reset/cleared a users password Yes

Attempt by a user to access function/data that they do not have access to No

User/Group account creation Yes

User/Group account deletion Yes

User/Group Access rights modification No

Other No

None No
Identify all of the contents of a Security Event log entry:

Date and Time Yes

Time to millisecond accuracy No

Identifier of the User Yes

Identifier of the device (workstation, IP, or other station identification) Yes

Event description Yes
Are these security events tracked in a different log than patient identifiable data related events? Yes
On failed authentication attempts, is the password attempted entered into the log? No
Is the log file persistent (NOT automatically overwritten or deleted)? Not limited
Is access to this log restricted to authorized individuals? Yes
Can the customer specify the list of events to track? No

Log All Patient Data Views

Identify all of the Patient Identifiable Data View events that can be logged:

Printouts Yes

Export to files Yes

Export to removable media Yes

Faxed Yes

E-Mailed Yes

View by browser Yes

B-8 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security: Log All Patient Data Modifications

View by client application No

Retrieved over network protocol (DICOM, XML, API, etc) No

De-identification No

Other No

None No
Identify all of the contents of a Patient Identifiable Data View log entry:

Date and Time Yes

Time to millisecond accuracy No

Identifier of User Yes

Identifier of Device (workstation, IP, or other station identification) Yes

Identifier of the application No

Identifier of the function within the application No

Identification of the Patient Yes

How long the data was displayed No

Event description Yes
Is the log file persistent (NOT automatically overwritten or deleted)? not limited
Is access to this log restricted to authorized individuals? Yes
Can the customer specify the list of events to track? No

Log All Patient Data Modifications

Identify all of the Patient Identifiable Data Modification events that can be logged:

modification of clinical data prior to a final report (diagnosis, medications, observations, measurements, etc) Yes

modification or amendments to a final report Yes

modification of patient demographics Yes

modification of test date, time, or setup parameters Yes

modification of diagnosis Yes

None No
Identify all of the contents of a Patient Identifiable Data Modification log entry

Date and Time Yes

Time to millisecond accuracy No

Identifier of User Yes

Identifier of Device (workstation, IP, or other station identification) Yes

Identifier of the application No

Identifier of the function within the application No

Identification of the Patient Yes

Event description Yes

Is the log file persistent (NOT automatically overwritten or deleted)? not limited

Revision A MUSE B-9

2033425-029

Appendix B – Summary of MUSE Security: Log All Changes to the Configuration

Is access to this log restricted to authorized individuals? Yes

Can the customer specify the list of events to track? No

Log All Changes to the Configuration

Identify all of the Configuration Change events that can be logged:

Change of the system Date and/or Time No

Installation of patches, maintenance, FMI, hotfix, etc Yes

IP Address or other network configuration No

Analysis algorithm parameters No

Creation, modification, or deletion of output devices/API/interface/AE No

Creation, modification, or deletion of input devices/API/interface/AE No

Other No

None No
Identify all of the contents of a Configuration Change log entry:

Date and Time Yes

Time to millisecond accuracy No

Identifier of User No

Identifier of Device (workstation, IP, or other station identification) No

Identifier of the application No

Identifier of the function within the application No

Event description Yes

Is the log file persistent (NOT automatically overwritten or deleted)? date limited

Is access to this log restricted to authorized individuals? Yes

Can the customer specify the list of events to track? No

Audit Log Viewing

Is there protection against ALL modification of all log files? Yes
Is deletion of a log tracked in a different log? No
Is viewing of a log tracked in a different log? No
Does the product provide alerts based on automated advanced log analysis? No
Are the audit trail alerts tracked in an log? No
Is there a time synchronization function included and documented? Yes

Audit Log Mining

Does the product support the use of third-party audit mining packages? No
Does the product support a mechanism for creating a text based audit log (or are the audit logs already text)? No
Does the product integrate with CA Unicenter or HP Openview? No
Does the product provide searching tools for the audit logs? No
Does the product provide sorting tools for the audit logs? Yes

B-10 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security: Configuration Lockdown & Security Fixes

Identify all of the Audit Trail Reports that can be created:

Users accessing records with the same last name as the user No

Users accessing records with the same address as their address No

Access to records that have not been accessed in a long time No

Access to an employee’s own patient data No

Accesses to minor’s patient data No

Accesses to terminated employees patient identifiable data No

Multiple login attempts with improper authentication No

All users that have use a specific function No

All activity of a specific user No

All accesses to a specific patient No

All activity from a specific workstation or communications link No

All login and logout activity within a period of time No

All login failures No

All Access control failures No

All Modifications to security settings No

All changes to authentication settings No

All access via remote service interface No

All changes to the audit trails configuration No

Other No

None Yes

Configuration Lockdown & Security Fixes

Is this OS configured to meet DOD - C2 Compliance? No
Have unnecessary services and protocols been turned off? Yes
Have unnecessary services and protocols been uninstalled? Yes
Are default passwords documented in any form of manual? Yes
Are passwords that are not changeable used for administrative accounts? No
Is the SNMP community name set to "public" or "private"? No
Is there documentation available that describes the services and protocols that are necessary for proper operation of the

Yes

product?
Is the customer free to apply any Operating System or tool vendor fixes to the product? No
Does the M4 release contain all security fixes for the OS, database, or any other third party tools within 6 months of the

Yes

M4 date?
For Operating Systems:

The typical time window between when a patch is available and when it can be applied to a customer system is 6

Yes

months

Revision A MUSE B-11

2033425-029

Appendix B – Summary of MUSE Security: AntiVirus

The typical time window between when a patch is available and when it can be applied to a customer system is 12

months

The customer can get OS fixes that are no more than 12 months old Yes

Is this database configured with the minimal services and protocols running? Yes
For Databases:

The typical time window between when a patch is available and when it can be applied to a customer system is 6

months

The typical time window between when a patch is available and when it can be applied to a customer system is 12

months

The customer can get database fixes that are no more than 12 months old Yes

Does the product include other third party tool or application (Backup software, SNMP agent, pcAnywhere,

maintenance tool, Microsoft Office, etc)
For other 3rd party tools:

The typical time window between when a patch is available and when it can be applied to a customer system is

6 months

The typical time window between when a patch is available and when it can be applied to a customer system is

12 months

The customer can get 3rd party tool fixes that are no more than 12 months old Yes

Yes

Yes

Yes

Yes

Yes

Yes

List any Third Party Applications, Tools, Libraries, Drivers? Insite 2,

Antivirus
software,
Digiboard,
IE,
MSDE,
MDAC,
MMC,
Disk

AntiVirus

Are all product releases and maintenance releases scanned for any malicious code (Virus, Worm, Trojan)? Yes
Identify all of the Malicious Code detection supported:

Host based Intrusion Detection No

Norton AntiVirus Yes

McAfee AntiVirus Yes

Other Windows AntiVirus No

Customer supplied AntiVirus software No

Customer administrated AntiVirus Signature Files No

Tripwire or other No

None No

Integrity Controls on Data

Does the product utilize transparent end-to-end data integrity controls? (memory parity, tcp checksums, etc) Yes

B-12 MUSE Revision A

2033425-029

Appendix B – Summary of MUSE Security: Backup and Recovery

Does the product enforce application managed data integrity controls like object checksums? No
Does the product support PKI based Digital Signatures to maintain data integrity? No
Does the product enforce required fields during data entry to ensure completeness of records? Yes
Does the product have a data entry validation mechanism such as double keying of patient identifiable data to ensure

No

accuracy of the data entered?
Does the product store rejected transactions with the reason for the rejection? Yes
Does the product ensure that database updates are done in a fail-safe way? Yes
Is there any Other form of integrity control provided? No

Backup and Recovery

How many patient records does this product store or manage? unlimited
Identify all the ways that the product protects against disasters/failures:

Export to removable media No

RAID hard drive Yes

backup of patient data only (typically to tape) Yes

backup of full system (typically to tape) Yes

UPS Yes

Off site mirroring No

Near-line storage No

Other No

None No
Backup and Recovery procedures are documented? Yes
Can the Integrity and completeness of the backup be verified by the operator through the use of offline means? Yes

Encryption

Is any form of encryption of patient identifiable data supported (not including the service interface)? Yes

De-Identification

Is there a bulk de-identification functionality that the user can use? (not service interface) No

Digital Signatures

Does the product provide for some form of electronic acceptance stamp on Patient Identifiable Data? Yes
Does the product provide for a PKI based digital signature? No
Does the product support DICOM supplement 41 Digital Signature Extensions? No

Service

Is there a method that service can use to access the system in the case of an emergency when normal administration is

Yes

not possible?
Does the product have at least one login specifically for servicing the equipment? Yes
Does the product restrict service individuals with multiple levels of access control? No
Does the product support multiple individual service accounts? Yes

Revision A MUSE B-13

2033425-029

Appendix B – Summary of MUSE Security: Service

Are Service accounts restricted from viewing, or manipulating Patient Data? No
Are all accesses to Patient Data by service restricted to de-identified data? No
Are Service actions accounted for in a log file somewhere? Manually
Are passwords that are not changeable used for Operating System administrative accounts? No
Are passwords that are not changeable used for service accounts? No
Are Service default passwords described in details in any form of manual? No
Is the customer allowed to change the service passwords? Yes
Does the product support remote service? Yes
Does the remote service session require authentication to a service user? Yes
Can the customer tell that a remote service session is in progress? Yes
Can the customer, through automatic or manual methods, know which specific service individual is currently remotely

No

logged in?
Can the customer see what is happening in an active remote service session? Yes
Can the customer stop an active remote service session? Yes
Specify the equivalent encryption strength that a remote service session can operate over? 3DES
Is the product specific GE Remote Service network isolated from the rest of the GE intranet? No
Are access points to the GE service network protected with an ICSA equivalent firewall? No
Are remote sessions ever initiated without a Service call being logged by the customer? No

B-14 MUSE Revision A

2033425-029

Appendix C – 21 CFR Part 11 Option:

C Appendix C – 21 CFR

Part 11 Option

Revision A MUSE C-1

2033425-029

Appendix C – 21 CFR Part 11 Option: Electronic Signature

Electronic Signature

21 CFR Part 11 states that users must be prompted for a password on
each site when they are not biometrically authenticated. The 21 CFR
Part 11 option is available with MUSE software version 7.x software.
When this option is enabled, the Site Information window contains two
additional check boxes.

 Enable 21 CFR Part 11

 Display Password Prompt when saving

006

1. To enable 21 CFR Part 11, at System > Setup > Sites > Advanced,
place a check mark in the box next to Enable 21 CFR Part 11.

C-2 MUSE Revision A

2033425-029

Appendix C – 21 CFR Part 11 Option: Electronic Signature

2. If biometric authentication is being used for EVERY USER on the
site, check the box next to Display Password Prompt when Saving.

3. If the site has some users who use biometric authentication and some
users who do not use biometric authentication, check 21 CFR Part 11
and leave Display Password Prompt when Saving unchecked.

When Display Password Prompt when Saving is left unchecked in
Site Setup, individual’s User Setups will be used by the system when
they save reports.

The table below summarizes how the individual user’s Display
Password Prompt when Saving option functions.

User Electronic Signature Summary

Site Setup Window User Setup Window

21 CFR Part 11 ;

Display Password Prompt
when Saving 

21 CFR Part 11 ;

Display Password Prompt
when Saving 

21 CFR Part 11 ;

Display Password Prompt
when Saving ;

Display Password Prompt when Saving ;

Display Password Prompt when Saving 

Display Password Prompt when Saving ;

-or-

Display Password Prompt when Saving 

Prompt for Password on each

Save?

Yes, for that user at that site.

No

Yes, for all users at that site.

Revision A MUSE C-3

2033425-029

Appendix C – 21 CFR Part 11 Option: Other 21 CFR Part 11 Features

Other 21 CFR Part 11 Features

Disable Automatic Updates to Report Data

When the 21 CFR Part 11 option is enabled, automatic updates to report
data are disabled on the system. This means that confirmed reports are
not updated when new reports for the same patient are confirmed. It also
means that the system does not update data entered/acquired at the cart.

 Patient demographic data (age, gender, race, height, and weight) are

not updated in confirmed data when new reports for the same patient
are confirmed on the system.

 After QTC has been calculated at the cart, the system does not re-

calculate QTC upon acquisition of this data.

 When user IDs have been entered at the cart, the system does not

assign user names to these IDs upon acquisition of this data.

C-4 MUSE Revision A

2033425-029

gemedical.com

World Headquarters
GE Medical Systems
Information Technologies, Inc.
8200 West Tower Avenue
Milwaukee, WI 53223 USA
Tel: + 1 414 355 5000

1 800 558 5120 (US only)

Fax: + 1 414 355 3790

European Representative
GE Medical Systems
Information Technologies GmbH
Munzinger Straße 3-5
D-79111 Freiburg
Germany
Tel: + 49 761 45 43 - 0
Fax: + 49 761 45 43 - 233

Asia Headquarters
GE Medical Systems
Information Technologies Asia; GE (China) Co., Ltd.
24th Floor, Shanghai MAXDO Center,
8 Xing Yi Road, Hong Qiao Development Zone
Shanghai 200336, P.R. China
Tel: + 86 21 5257 4650
Fax: + 86 21 5208 2008