HIPAA: The Application and Challenges of Implementing Healthcare Information Technology

by Eric Kolman
May 2007

1. Introduction
2. Overview: Key Terms
3. Overview: What is HIPAA?
3.1. Title I
3.2. Title II
4. Review of Technology
5. Issues with Technology
5.1 Implementation status of clinical IT
6. Case Study: HIPAA Compliance Survey Results, Winter 2006
7. Conclusion
8. References

Introduction

The Healthcare Industry has been undergoing radical transformations and has been rapidly changing to adopt information technology solutions to meet the challenges of regulatory burdens, cost reduction, and patient care. A few examples of the solutions being implemented are computerized physician order entry initiatives (CPOE), electronic medical records (EMR), and electronic claims processing. A recently study has shown that healthcare providers in the United States will increase IT spending from $15.1 billion in 2002 to $17.3 billion in 2007 (Rotbert Law Group).The demand for healthcare technology has significantly increased and has created remarkable opportunities for health care solution providers. The expanding use of IT though has also created numerous challenges for organizations. As information in the healthcare industry moves to becoming completely electronic, privacy and security concerns are increasing. The foremost concerns hospitals and healthcare systems face are protecting the patients’ information and making sure it is secure and preventing people from accessing the information who should not have access. Healthcare organizations look to IT to help them solve this problem but fulfilling the promise of technology is an ongoing and daunting task due to limited budgets, the need for legacy system migration and new technology insertion. A regulatory framework has been put into place in order to respond to these rising concerns. Part of this regulatory framework is the Health Insurance Portability and Accountability Act, otherwise known as HIPAA. Health plans and health care providers who transmit health information in electronic form must be in compliance with HIPAA or face the possibility of significant fines or even jail time.

Read more : http://citebm.business.uiuc.edu/TWC%20Class/Project_reports_Spring2007/HIPAA/ekolman/eKolman.pdf

ISO 17799 It's a control, not a standard

By Patrick Lamphere
April 29, 2007
Computerworld

Im always interested when I learn that things arent the way I thought
they were. Mom put "Santa's" presents under the Christmas tree.
Columbus didnt discover America. Lee, Lifeson, and Peart arent equal to
the Father, Son, and Holy Spirit. And, most recently, ISO 17799:2005
shouldnt be used as a list of required controls for organizations to
deploy.

Dont get me wrong. For something written by committee, the
International Standards Organization and International Electrotechnical
Commission - Code of Practice for Information Security Management
Reference Number 17799:2005 (from here on out ISO 17799) isnt half bad.
As anyone familiar with it knows, its a fairly exhaustive list of
controls covering 11 major domains of information security (more on that
later), from policy to compliance.

Its not perfect. Aside from the Briticisms (it is their language, after
all), there are some areas where it doesnt give enough depth or detail,
others where it goes a little overboard, and some terminology that is
just plain odd ("Threat Vulnerability Management," anyone?). But these
relatively minor shortcomings are outweighed by the overall benefits for
those companies that turn to it for guidance.

If your company is adopting ISO 17799 as a "standard," however, youre
missing the point. ISO 17799 is a list of controls -- nothing more,
nothing less. Notice the ample use of the word should throughout the
document. Nowhere are there any requirements that an organization do
anything. No shall or shall not, no do or do not -- ISO 17799 is a list
of guidelines, not requirements.

This is a good thing.

ISO 17799 was originally British Standard 7799-1, and meant to be
adopted along with the other parts of the 7799 series, namely 7799-2
(Information Security Management Systems) and 7799-3 (Guidelines for
Information Security Risk Management. Further muddying the waters, BS
7799-2 was recently adopted as ISO 27001. BS 7799-1/ISO 17799 will
eventually be renumbered as ISO 27002 (PDF format).

So whats the point? Thats where ISO 27001 comes in. ISO 27001:2005 is
a specification for an Information Security Management System (ISMS):
These are things you must do to set up an ISMS. But what is an ISMS?
The ISMS is the framework you need to have in place to define, implement
and monitor the controls needed to protect the information in your
company.

And here we get back to information security. ISOs 17799 and 27001 arent
just concerned with the data sitting on your companys collection of hard
drives. They cover how your company protects its information in all its
forms, from bits on disks to black marks on dead trees and piles of
sentient meat.

This is also a good thing.

Getting started ISO 27001-style

There are 5 main clauses of the ISO 27001 standard (8 total, but 1-3 are
definitions and overview), plus an annex that maps directly to
17799/27002. Clause 4 is the meat of the standard. It outlines the
requirements for the ISMS.

First you establish the scope -- what is it going to cover? Your entire
organization? A smaller portion (like a datacenter or subsidiary)?
The scope is up to you, but needs to be reasonable -- if youre an online
backup firm, for instance, excluding the servers used to perform those
backups but leaving everything else in wouldnt make sense.

Once youve got scope defined, you create the policy to govern the ISMS.
This includes the usual high-level policy stuff such as management
support and alignment with the business; along with the interesting
parts that make ISO 27001 unique and more useful than any of the other
frameworks out there: contractual (PCI), business, legal and regulatory
(eg., SOX or HIPAA) requirements; and the risk management context,
including risk assessment and acceptance criteria.

After youve got your scope and policy, its time to get down to work
figuring out what information assets you have, and doing a risk
assessment of each of those assets. The assets can be as granular as is
reasonable for your business, though its easier to lump things together
(for example, one asset type defined as employee personal information
instead of separate categories for W-2, I-9, 1099, 401k, and so forth).
Once the assets are figured out, you can then choose your favorite risk
assessment methodology (OCTAVE, NIST 800-30 [PDF format], BS 7799-3,
Tarot) to determine the risks that apply to your defined information
assets.

Suggestions, not requirements

Now that youve determined your risks, its time to pick controls. And
heres the best part: while you do need to address the control areas
outlined in Annex A, the controls you select dont have to be as
stringent as whats outlined in ISO 17799/27002. The controls in ISO
17799/27002 are suggestions. Its up to you to pick the controls that
provide an appropriate level of mitigation for your business. Granted,
you still need to take into account the realities of your regulatory
environment (no 4 character passwords and ROT13 encryption for PCI), but
the controls beyond that, as long as they are reasonable for the defined
levels of risk, are entirely up to your business

A side note on risk -- as part of any risk assessment program, you
should have guidelines for how risks are going to be handled --
mitigation (the application of controls), acknowledged and deferred (we
know about that, we just cant afford to do anything about it right now,
hold off until the next budget cycle), transferred (insurance), and
acceptance (the level of risk that the business is able to live with).

The remainder of clauses 4-8 deal with the management acknowledgement
and acceptance of any residual risk, ensuring that the ISMS is kept up
to date through periodic management review, internal audit, and process
improvement; and of course proper documentation (if its not on paper, it
doesnt exist).

And the benefits?

So once youve gone through this long (18-30 months) and admittedly
difficult-at-times process, whats the benefit?

Controls that align with the business. No longer are your information
security controls applied based on the whims of management and
proclivities of your IT staff. Risk is managed as a whole -- no more
chasing down the rat-hole of SOX only to finally crawl back out again,
bruised, bloodied, and battered, to repeat the experience with HIPAA,
then with SB 1386, then PCI, USA PATRIOT (PDF format), FinCEN, OFAC,
PIPEDA, ad infinitum.

Best of all? You can get your business certified to the fact that you
have a functioning ISMS that incorporates the requirements of all the
legal, contractual, and regulatory requirements that you have included
in your scope. Its the closest thing out there to being certified
compliant to HIPAA or SOX. And the cost of certification is surprisingly
cheap -- $15K to $50K for three years, depending on the size and scope
of your ISMS. And despite what the security community is more than
willing to sell at the moment, you cant certify to ISO 17799/27002. The
controls outlined in ISO 17799 are simply guidelines, not requirements.

This isnt to say that an organization cant decide to use those
guidelines as the basis of their control framework, and then perform a
gap analysis against those controls. Its just by deploying ISO
17799/27002 and ignoring 27001, youre missing a fantastic opportunity to
bring your Information Security and IT Departments to a level of
maturity that is fully aligned with the realities your business faces.

-=-

Patrick Lamphere is a professional cynic, skeptic, and tubist who amuses
himself working as an information security consultant.

Article Source : http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9018158

HIPAA Security for Wireless Networks (Ebook)

By NetMotion Wireless for ITtoolbox Wireless

Securing data in a health care setting is a daunting task. Although most facilities contain up-to-date
medical technology, many have antiquated communication networks lacking the security and
encryption required to protect patient information. The physical structures of hospitals make it
difficult or even impossible to add wiring for adequate networking, which is why many IT departments
have opted for a wireless network. Implementing a wireless LAN can be both more costeffective
and less problematic then implementing a wireline network, but they are not without their
challenges. Security risks exist and connectivity is a concern while roaming through buildings that
contain elevators, radiology room shielding, or other physical structures that “break” wireless
network sessions.
Under the mandated provisions of the Health Insurance Portability & Accountability Act (HIPAA),
IT managers now have a timeline for implementing government-legislated security and privacy
measures to protect patient data. Although HIPAA may seem burdensome, it benefits caregiver
organizations by creating a proactive measure for managing and maintaining reasonable security
safeguards and protecting patient data from unauthorized users.

View all information : http://wireless.ittoolbox.com/pub/MM020102.pdf

Enhancing HIPAA Security Rule Compliance Efforts

Achieving compliance with the U.S. Health Insurance Portability and Accountability Act's Security Rule can be a daunting task. Internal auditors can play an instrumental role during the compliance process by helping organizations gain the most from their HIPAA security audits.

Gary Swindon, CISM, CHS-III
Chief Operating Officer, RiskWatch Inc.

Protecting and securing medical information is a major concern for private, public, and government organizations in the health-care industry. Internal auditors are equally aware of this importance: Ensuring health-care records and other sensitive information do not fall into the wrong hands is of special concern. Auditors must determine whether or not the organization has taken the necessary steps to prevent the inappropriate exposure, damage, or loss of confidential data.

Since 1996, the U.S. Health Insurance Portability and Accountability Act (HIPAA) has provided organizations in the United States with guidance regarding the proper ways to protect personal health information through the act's Privacy and Security rules. While HIPAA's Privacy Rule provides information to help organizations regulate how they use and disclose personal health information, its Security Rule lists 42 standards companies need to implement to ensure the confidentiality, integrity, and availability of digital personally identifiable health information. Although both rules should be used together, the Security Rule is of special importance to IT departments, because it identifies how organizations can protect personal health information from external and internal security threats, such as e-mail attacks and password compromises.

Internal auditors can help organizations prepare for the IT component of the HIPAA security audit by focusing management's attention on key compliance considerations, such as the organization's IT governance structure; helping IT departments identify how the Security Rule's 42 standards will affect the organization's current IT environment; and comparing each of the report's findings to IT guidance provided in the Security Rule. This will enable auditors to help organizations gain the most from their HIPAA security audits.

SECURITY RULE COMPLIANCE CONSIDERATIONS

HIPAA compliance audits should be based on three things:

• An identification of the organization's governance model. Examples of IT governance models organizations might consider using include the IT Infrastructure Library, ISACA's Control Objectives for Information and related Technology (CobiT), and the International Standards Organization's (ISO's) 17799 or 27001 standards.
• A traditional screening, sometimes called a checklist, of all controls, countermeasures, and items of interest as defined in the scope of the audit.
• An identification of the master rules or conditions required by the regulation based on the organization's type (i.e., private, nonprofit, or publicly traded).

In the case of HIPAA's Security Rule, audits should be based on the rule's provisions or standards (i.e., safeguards and outcomes specified in the body of the regulation, as opposed to industry best practices) and be supplemented by the organization's chosen governance model. Understanding the organization's IT governance model is important, because it enables auditors to determine which standards the company views as appropriate and should be used in the conduct of the audit. The IT governance model also helps auditors frame audit findings and recommendations pertaining to IT controls and identify whether these controls are effective based on HIPAA compliance requirements. If the firm has no adopted IT governance model, the use of generally accepted IT industry standards to conduct the audit would be appropriate, such as ISO's 17799 and 27001 standards, CobiT, or the National Institute of Standard and Technology's Security Self-Assessment Guide for Information Technology Systems (PDF, 1.48MB)

The findings of the audit should help to confirm or call into question the governance model chosen. Audit results that indicate a clear pattern of noncompliance with rules and regulations should warn executives that the company's governance model may not be appropriate.

Traditional screenings or checklists identify required compliance elements that will be reviewed during the audit, such as key items to be addressed, personnel to be interviewed, and new or existing policies. These checklists are important, because they enable the auditor to provide a list of the different areas that need to be improved or implemented for compliance to take place.

Finally, an identification of the master rules or conditions required by the regulation based on the organization's type is important, especially in situations where the company chooses to meet other standards as a demonstration of its good intentions. A good example of this is when a private nonprofit organization adopts IT controls outlined in Section 404 of the U.S. Sarbanes-Oxley Act of 2002, even though the company is exempt from Sarbanes-Oxley compliance. HIPAA's Security Rule identifies four minimum requirements or master conditions that all implemented IT measures and controls need to meet (refer to "HIPAA Security Rule Master Conditions" for more information).

THE AUDIT PROCESS

The Security Rule allows auditors to construct their audit plans more effectively by expressing desired outcomes under three safeguard categories — administrative, physical, and technical. Each of these safeguards is divided into a number of standards — 42 total — which are then categorized as required or addressable. These outcomes can be found in a matrix that has been incorporated into the final Security Rule and is available on the Centers for Medicare and Medicaid Services Web site. Although required standards must be implemented as outlined in the Security Rule, addressable standards can be structured by the entity to suit its particular needs as long as the outcome conforms to those found in the Security Rule. This process is outlined in Figure 1.

Figure 1: HIPAA Security Rule audit process

HIPAA security audits require the auditor to pay attention to the prevailing general conditions or stipulations that may impact the audit plan, as well as how existing controls and methods address each of the 42 security standards. In terms of IT, auditors need to review the organization's use of appropriate controls to ensure the protection of personally identifiable health information. The following list provides useful information auditors should keep in mind during Security Rule audits:

• The HIPAA Security Rule is tied directly to the HIPAA Privacy Rule and incorporates elements of the Privacy Rule through cross referencing. For instance, the requirement found in paragraph 164.530 of the Privacy Rule deals with policies and procedures, including IT, and is carried forward in the Security Rule in its requirement for appropriate policies and procedures and in the retention period for them.
• The Security Rule's scope is corporatewide and applies to the implementation of security standards in all relevant business processes, not just IT.
• The Security Rule represents a minimum set of security standards organizations must have in place for compliance. Many businesses have processes and requirements that are unique to the way they do their work. As a result, appropriate additional IT controls and procedures should be in place.
• The Privacy and Security rules incorporate the extension of adopted IT and other standards to business partners through the formal Business Associate Agreement process. This is a formal standard stated in both rules. The standards for privacy and security are found in the Privacy Rule and Security Rule, respectively.
• The standards found in the Security Rule and the company's implementation of corresponding IT and other controls must be based on the results of periodic risk assessments conducted by the company. The results of these risk assessments will help the auditor determine the effectiveness of companywide information security efforts to protect business assets.

  HIPPA SECURITY RULE MASTER CONDITIONS The Security Rule outlines four master conditions or minimum requirements that apply to business controls and processes used to address the rule's 42 standards. These minimum requirements state that all selected controls must be: Cost effective. A company should not spend more for the control's implementation than the probable value of the information or process it is designed to safeguard. Within the technical capability of the firm. The company must be able to maintain and enforce the controls they choose without having to rely on an outside party. For instance, although a company can outsource its IT functions, it must be able to create, maintain, and enforce all IT controls if they are brought back in-house, such as access and authorization controls and audit log evaluations. Within the resource capability of the enterprise. The business should have the necessary IT resources to monitor and manage each control throughout the year. Suitable when weighed against their desired results. General IT, compensating, or alternative controls should correspond directly to the standard in question. For example, the requirement to be able to back up and restore patient data should rely on access controls, data verification and integrity controls, and storage requirements, among others. During Security Rule compliance reviews, internal auditors need to identify how companywide IT measures and controls meet each of the four requirements.

EXAMINING THE REPORT'S FINDINGS

Prior to releasing audit findings, internal auditors should be able to answer questions regarding the report's IT recommendations. To do this, auditors can compare each of the report's findings to IT guidance provided in the Security Rule. The following questions can help auditors identify how current IT controls compare to IT guidance provided in the Security Rule, as well as determine whether existing controls meet compliance requirements:

• Given the IT governance model adopted by the firm, does the chosen IT control match the company's intention? If so, does it fit logically?
• Does the chosen IT control meet the general and master conditions outlined in the Security Rule? For example, does it meet the cost, capability, resource, and suitability requirement in the rule?
• Given the apparent investment level in the IT control, is the investment appropriate to accomplish the goal?
• As with any audit, are the IT controls documented adequately?
• Do IT controls tie to a stated security standard outlined in the Security Rule or to an identified business need above and beyond the rule's standards?
• Has the firm identified and documented addressable and required IT controls properly, including its rationale for the choice of action?
• For any given IT control, is there an obvious impact regarding the viability of the security system employed?
• Do audit findings represent a material condition or weakness (e.g. not being able to recognize revenue correctly and consistently or ensuring that pharmacy prescriptions are filled in a timely manner)? If so, is the finding material in its potential impact on financial systems, patient care safety standards, etc.?
• Do chosen IT controls support the company's risk posture? Auditors should look to the IT governance model for direction or to accepted industry standards if no governance model has been identified.
• Do the IT standards and controls make sense in the context of the company's choices as opposed to IT best practices?

LEVERAGING AUDIT RECOMMENDATIONS

Although the information above focuses primarily on the IT aspect of Security Rule compliance, these basic recommendations can be used for overall HIPAA compliance audits. These recommendations also can be applied to other regulations, particularly Sarbanes-Oxley and the U.S. Graham-Leach-Bliley Act (GLBA) of 1999. For instance, HIPAA, Sarbanes-Oxley, and GLBA share many common requirements, such as the need for companies to conduct regular risk assessments or the need to achieve cost effectiveness and stay within the company's IT capability. Furthermore, the blending of implemented audit compliance requirements from different regulations and the organization's adopted governance model can highlight the potential need for changes in the way the company views IT risks and uses IT resources.

For more information about HIPAA, visit:

• The U.S. Department of Health and Human Services' Web site: www.hhs.gov/ocr/hipaa/.
• The U.S. National Institute for Standards and Technology's Security Rule Resource Guide: http://csrc .nist.gov/publications/nistpubs/800-66/SP800-66.pdf. (PDF, 1.68KB)
• The HIPAA Security Rule Web page located on the U.S. Centers for Medicare and Medicaid Services Web site: www.cms.hhs.gov/SecurityStandard/Downloads/securityfinalrule.pdf. (PDF, 309KB).
  

Gary Swindon is the chief operating officer for RiskWatch Inc., a security risk assessment company. Prior to RiskWatch, Swindon held senior positions in both public and private organizations, including Orlando Regional Healthcare, where he was the hospital group's chief information security officer; WebMD, where he served as chief security and privacy officer; and the state of Michigan, where he was responsible for consolidating more than 20 data centers. He also has served as a director for the ISACA CISM certification board.

Source : www.theiia.org/ITAudit/

Understanding HIPAA Security Implications Of a Wireless LAN Subsystem Using the ISO/IEC 17799 ISMS Standard (Ebook)

Understanding HIPAA Security Implications Of a Wireless LAN Subsystem Using the ISO/IEC 17799 ISMS Standard
By: Frederick Hawkes

File Type : Pdf
Page : 49 Page
Read This Ebook : http://www.giac.org/certified_professionals/practicals/g7799/0012.php

Table of Contents

Define the System ....................................................................................................................4
Project Summary ....................................................................................................................4
Organization ...........................................................................................................................4
System Description.................................................................................................................6
Current Security Structure.......................................................................................................8
Plan-Do-Check-Act (PDCA) Process ......................................................................................9
ISMS Project Plan (PDCA … Plan)...............................................................................10
Project Scope .......................................................................................................................10
Project Timeline....................................................................................................................11
Organizational Structure and Responsibilities .......................................................................12
Policies, Guidelines, Standards or Procedures Requirements ..............................................14
Risk Identification Process ....................................................................................................16
Risks to the System..............................................................................................................19
Plans for Addressing the Risks .............................................................................................20
Selected ISO17799 Controls.................................................................................................21
ISMS Implementation Plan (PDCA … Do).....................................................................23
Overview..............................................................................................................................23
Creation and Staffing of the Security Management Team.....................................................23
Identification and Processing of Applicable Legislation .........................................................24
Data Protection and Privacy of Personal Information ............................................................25
Information Security Policy Document ..................................................................................25
Information Security Education and Training.........................................................................26
WLAN Access Control ..........................................................................................................27
Statements of Applicability....................................................................................................27
ISO 17799 Section 12.1.4 … Data Protection and Privacy of Personal Information..............28
ISO 17799 Section 12.1.2 … Intellectual Property Rights.....................................................28
ISMS Audit Plan (PDCA … Check)...............................................................................29
ISO 17799 Section 4.1.1 … Management Information Security Forum.................................29
ISO 17799 Section 12.1.1 … Identification of Applicable Legislation.....................................30
ISO 17799 Section 12.1.4 … Data Protection and Privacy of Personal Information..............31
ISO17799 Section 9.4.3 … User Authentication for External Connections............................32
ISO 17799 Section 3.1.1 … Information Security Policy Document.......................................34