Section 1.

1 Adopt - Assess

HIT Security Risk Analysis

Use this inventory to identify the technical security controls in place in your current health information technology (HIT) applications, help you
determine where controls are adequate or where they may need to be made stronger, and what controls you may need in future HIT acquisitions.
Note, this tool does not address the administrative requirements for managing these controls, which are included in the 2.1 Security Risk Analysis
and HITECH Requirements tool in this toolkit.

Instructions for Use

1. This spreadsheet has two worksheets. Use the Analysis worksheet to record your information. To annotate who compiled the information and
the date compiled, use the Page Setup feature in File to record this information in the document's footer. This tool should be completed by IT
staff and reviewed by the HIT steering committee and other organizational unit responsible for oversight of security compliance.
2. Applications. List all information systems applications present; and add/delete/update as new applications are acquired.
3. Application Criticality. Assess and record the application criticality for each application:
Mission Critical = your organization cannot survive without this application
Critical = this application is very important to your organization and would be difficult to manage without
Important = this application is necessary for key functions, but there are alternatives to achieve the functionality without the application
Deferrable = the application is useful but the organization could operate for some period of time without it
Unknown = the
4. Store/Transmit application's
PHI? criticalityortonot
Identify whether thethis
organization
applicationneeds toand/or
Stores be determined
Transmits Protected Health Information (PHI), according to the
definition in HIPAA.
5. Data Sensitivity. Assess and record the application's data sensitivity:
Unrestricted = anyone can have access to the data processed by this application
Restricted = there are specific policies around who may have access to the data processed by this application. (For example, only a
physician who is treating a specific patient should have access to this data.)
Need to know = there are special sensitivities that would require extra security precautions. (For example, this application includes a
patient's real name for insurance purposes, even though a pseudonym has been given to the patient who is a VIP for all other applications.)
6. Unique User ID. Determine whether the application requires unique user identification for access. Distinguish between control is available,
and actually used.
7. Access Control. Identify the type of access controls used in the application:
None
Role-based = access is driven by the role the individual has been authorized to perform in your organization. (For example, Paul Smith is a
physician and has access to all data in the application.)

Section 1.1 Adopt Assess HIT Security Risk Analysis - 1

 Context-based = access is driven by role individual has been authorized to perform and relationship indivdiual has to data in application,
location at which individual accesses application, and/or any time or other constraints around access. (For example, Dr. Smith may access
only patients with which s/he has a documented treatment relationship, unless s/he is accessing application from Emergency Department on
Sundays, then
8. Emergency s/he Identify
Access? has access to all patients
whether emergencyin hospital.)
access control capability exists and is used. This is frequently called "break-the-glass" and
enables an individual who does not normally have access to gain access via a second level of control, followed up with a special logging of the
access in an audit trail.
9. Form of Authentication. Identify the form of authentication required for the user to access the application and/or data within the application.
These include: password, PIN, token, callback, biometric, or other.
10. Audit Control. Identify the type of audit controls in the application: by type (see below) and lowest level available (i.e., network level,
application level, patient record [file level], data element [field level])
Audit Write = a log of all changes is kept by the system
Audit Read = a log of all times there has been a viewing
11. Auto Log Off? Identify whether there is auto log off so that the application accessibility times out after a specific period of time. Record time
in minutes

Copyright 2009, Margret\A Consulting, LLC. Used with permission of author.

For support using the toolkit

Stratis Health Health Information Technology Services
952-854-3306 info@stratishealth.org
www.stratishealth.org

Section 1.1 Adopt Assess HIT Security Risk Analysis - 2

 Application Application Store/ Data Unique User Access Emergency Form of Audit Control Audit Control Auto Log
Access? Write Access? Read Access?
Criticality Transmit Sensitivity ID? Control Authenti- Off?
PHI? cation
Available Used Level Used Level Used Y/N Time in
Available Available Minutes

Date Completed:
Completed by:
Date Completed:
Completed by:
Date Completed:
Completed by: