Home  |   Subscribe  |   Resources  |   Reprints  |   Writers' Guidelines

February 1, 2010

Precarious Position
By Brenda J. Hurley, CMT, AHDI-F
For The Record
Vol. 22 No. 2 P. 18

Thorough security risk analysis is a must if medical transcription businesses are to avoid the pitfalls of impending HITECH requirements.

The world of HIPAA business associates (BAs) is about to be rocked like never before. Expanded requirements and obligations included in the HITECH Act, which take effect February 17, promise to make security concerns an even thornier issue.

While medical transcription businesses have already been complying with HIPAA BA agreements requiring them to have adequate administrative, physical, and technical safeguards in place to safeguard clients’ protected health information (PHI or ePHI), most BAs do not have a formal security risk analysis with written documentation. Given the large amount of data processed daily by medical transcription businesses, the importance of conducting and documenting a diligent security risk analysis process cannot be overstated.

As this article describes strategies for attacking this challenge, it is important to have an understanding of the definitions of the following essential terms (These definitions are adapted from the National Institute of Standards and Technology Special Publication 800-30 and published in “Basics of Risk Analysis and Risk Management,” the sixth part of the Centers for Medicare & Medicaid Services Security Series.):

Vulnerability: A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

Threat: The potential for a person or thing to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.

Risk: A function of the likelihood of a given threat triggering or exploiting a particular vulnerability and the resulting impact on the organization. Risk is not a single factor or event, but rather it is a combination of factors or events (threats and vulnerabilities) that, if they occur, may have an adverse impact on the organization.

The HITECH Act does not prescribe a specific risk analysis process or risk management methodology, only that it be performed and documented. In fact, both assessments are excellent tools to support an organization’s strategy to protect the confidentiality, integrity, and access of HIPAA-defined personal data from potential risks. (See the sidebar for key components to be included in the security risk analysis.)

Where to Start
The first step is to establish a project team. The number of individuals in the group depends on an organization’s size and complexity. Assignments should be made to those who fully understand the current process. Their assessment and documentation of each item (see sidebar) may proceed in a process similar to the following:

1. Gather all data about the current process that is being assessed.
a) Review past and/or existing projects.
b) Perform interviews.
c) Review pertinent documentation (eg, policies and procedures, memos, instructions, training materials, published standards, published best practices, information from system user community).

2. Identify potential threats and vulnerabilities.
a) Focus on those that can be reasonably anticipated.

3. Assess the current security measures.
a) Look at both technical and nontechnical measures.
b) Identify whether current security measures are configured and used properly.

4. Determine the likelihood (reasonably anticipated) of threat occurrence and the potential impact.
a) Rate the likelihood of occurrence as high, medium, or low.
b) The most common potential impacts include unauthorized access to system, breach of PHI/ePHI; permanent loss or corruption of PHI/ePHI; temporary loss or unavailability of PHI/ePHI; and workforce unable to perform its duties to maintain business continuity and negatively impact patient care.

5. Determine the level of risk and remediation measures for each risk.
a) Risk ranking performed during this step will help organizations prioritize the activities that must be performed to mitigate each risk.
b) Each risk is labeled with a corrective action description and timeline based on its ranking.

6. Identify, evaluate, and implement security measures.
a) When identifying security measures, consider their effectiveness, regulatory compliance, and client requirements.
b) Any potential security measure that can be used to reduce identified risks should be included in the documentation.

7. Establish a schedule for periodic audits to evaluate the effectiveness of risk mitigation measures.
a) HITECH does not specify how frequently audits should be performed. Depending on an organization’s size and complexity, annually or biannually will likely suffice.
b) An audit should be performed before and after new technologies are implemented or major operational changes occur to immediately manage any potential associated risk.

No Shortcuts
It is important to understand that because every organization is unique, the outcomes of these processes may be different when compared with similar businesses. For example, a medical transcription business that picks up dictation recorded on cassette tapes—yes, they are still out there—and delivers printed documents back to its clients will have a different set of potential vulnerabilities, threats, and risks from a service that does not handle tapes or deliver paper. This is why there is no “plug-and-play” security risk analysis. Because your processes and potential vulnerabilities, threats, and risks are unique to your organization, the analysis needs to be completed and the documentation maintained.

Taking a Closer Look
To successfully handle technical safeguards (see below), detailed written instructions, as well as policies and procedures, are critical. For example, access control, a written policy that defines who has access to what data, is needed to establish role-based permissions and should be assigned to individuals for the specific information they need to perform their duties. It is critical that the written policy accurately reflects what is actually happening in the organization. There is only one thing worse than having no written policy: having a written policy that is not being followed.

System access is often available to clients as well, making it essential that policy (and practice) include role-based permissions that limit access to only their information.

Several vendors offer solutions to help organizations maintain access control. For example, WebChartMD provides 16 different user-specific permissions for dictation and document access. Chief Technology Officer Andrew Jebasingh says some healthcare facilities grant access to support staff only after a document has been e-signed. Managers can then set user permissions to permit access to the Final folder (where documents migrate after being e-signed) and deny access to the Inbox (where completed documents first arrive into the system). In another scenario, management can grant view and print permissions for staff with billing and coding responsibilities, giving them read-only access to documents.

Two important strategies employed by WebChartMD for ensuring integrity are versioning and audit trails. All document and dictation access is captured in an extensive audit trail, allowing sanctioned users to view every action taken against the document or dictation via a secure Web portal. Each action is also marked with a date/time stamp, the type of action, and the username of the person who performed the action (see Graphic 1 below).

For those BAs who have not yet established an audit trail system (a requirement under HITECH), it is time—or past time—to do so.

Versioning is a technique that adds value to the auditing process. No matter how many individuals have revised a single document, all previous versions are available—even the original. All document edits are stored in a document history archive, which retains each version of the document and displays who made edits and when.

Now We Really Get Technical
Another new HITECH Act requirement makes it necessary to have data encryption (either 128 bit or 256 bit) both at rest (stored) and in motion (transmission). This provision will be reviewed and published annually by Health and Human Services (HHS).

While many medical transcription businesses have already been using encryption for transmitting data, only some have used encryption for stored data. This will need to change. Jebasingh says WebChartMD employs several high-tech solutions to handle the transmission and data security requirement:

• All Web traffic is sent over a 128-bit encrypted SSL channel.

• All dictations and documents are stored in the database using a 256-bit AES (Rijndael) encryption scheme.

• All passwords are encrypted when stored, meaning that no one (not even WebChartMD’s staff) has access to a user’s password.

Switching Gears
The items under HITECH’s Physical Safeguard section include some obvious and some perhaps not-so-obvious items. Facility access controls include common protections such as locked doors requiring keys or coded cards for scanning to achieve access. Some organizations may opt for a more high-tech approach and use biometric scanning to confirm access into the facility or data center. Just as system access is role based, facility access can be designed in the same way to limit entry by staff to specific key areas such as the data center for improved security and systems protection.

Workstation security is a twofold challenge. When analyzing the situation involving workstations within the corporate office, determine whether the physical location or placement is appropriate for the role performed by the user. If the individual is the receptionist, then a location by the entry door to the office is appropriate. If the individual is a medical transcriptionist or a quality editor—both of whom would have confidential patient information on their monitors throughout the day—his or her location should not be in a public area.

Of particular challenge are remote workstations. Are they password protected? Are they placed in appropriate locations within staff members’ homes? For example, it is not uncommon to require that medical transcriptionists work in a designated room away from the most frequently occupied areas. Is there any patient-identifying information stored on remote workstations? If so, it will need to be encrypted.

Many Web-based systems inadvertently store files accessed from Web-based applications in a temporary Internet folder. Jebasingh says WebChartMD’s system sweeps the user’s temporary directory and automatically purges all PHI—including documents and audio files—that was opened by the user during that online session.

Don’t Forget Laptops
It’s easy to focus only on the workstations around the office and those used by remote medical transcriptionists, but many times staff members use laptops for various functions such as accessing data. Because laptops are such huge targets for thieves, encryption is critical. Establish strict guidelines for laptop use to limit system access, as well as what can and cannot be stored on the device. Nearly every week there is a headline about how some company official’s laptop containing consumers’ personal information has been breached. Under HITECH’s breach notification rules, such a mishap becomes a serious violation with potential long-lasting implications.

The market features several interesting devices that allow organizations to perform remote authentication that would provide an extra level of systems protection. One example is a fingerprint scanner. Registered users place their index finger in the scanner slot, prompting the appearance of a log-in screen from which individuals have 15 seconds to type in their password. If the machine does not register a match, the log-in screen does not become available. This clearly offers more protection than a password.

Is It Time to Purge?
A considerable number of medical transcription businesses have archived years’ worth of their clients’ electronic documents. Some have also saved voice files for an extended period of time. Be realistic: The more data that are stored, the more information that will need to be encrypted, making the potential for a catastrophic breach more pronounced. Such an event would likely put someone out of business.

Electronic media need to be cleared, purged, or destroyed according to the guidelines in the National Institute of Standards and Technology publication on guidelines for media sanitization.

This Is Your Wake-Up Call
Clearly, the medical transcription industry faces formidable challenges to reach compliance with the new HITECH requirements, not only because of the enormous amount of data that are handled, stored, and transmitted on a daily basis but also because of the large number of remote staff. In fact, the medical transcription industry likely represents the largest remote workforce in the entire U.S. healthcare system. Even with that reality, there is almost a “wait-and-see-what-happens” consensus, or what may be dubbed post-HIPAA (version 1) implementation complacency (“We survived it before and it wasn’t so bad.”). This is a dangerous game to play while HHS readies to conduct periodic audits to both covered entities and BAs.

Increased penalties range from $100 to $50,000 per violation with a cap of $1.5 million per year. In case that is not enough, when violations occur, HHS will notify the state attorney general’s office to determine whether state privacy laws were also violated. If so, the state will have the opportunity to assess fines and/or pursue criminal prosecution.
Are you ready for HITECH? If not now, when?

— Brenda J. Hurley, CMT, AHDI-F, is a consultant in the medical transcription industry.


Graphic 1


Security Risk Analysis
Items to Include

Administrative Safeguards:
Security management process
Assigned security responsibilities
Workforce security
Information access management
Security awareness and training
Security incident procedures
Contingency plan evaluation

Physical Safeguards:
Facility access controls
Workstation use
Workstation security
Device and media control

Technical Safeguards:
Access control
Audit controls
Person or entity authentication
Transmission and data security