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

It security and Risk Management : ISO 17799 [PDF]

Madina Nurguzhina

Table of contents

1. Introduction
2. COBIT versus ISO 17799 in IT Governance
2.1. COBIT 4.0
2.2. ISO 17799
3. Implementation of ISO 17799
3.1. ISO 17799’s implementation example
3.2. Benefits of ISO17799
4. Conclusion
Reference

Introduction

In order to be compliant with current laws and regulations, to be competitive and successful a company in the big world must consider not only such things as profit, personnel, supply chain management, and so on, but also information technologies that play a very high role in aforementioned processes. Information is a very important element of every process within a company. If a company can successfully protect and manage information, it would contribute a lot into its business purposes as a whole.

In the global community there are many different types of standards and frameworks that help a company to manage and secure IT such as COSO, COBIT, ISO, ITIL and many others. In order to have a strong and sound IT governance, a company has to implement appropriate IT frameworks that would fit a company’s main processes.

COSO is a very broad group of standards that includes different financial and auditing institutions’ functions, while COBIT, ISO and ITIL are more specific and focuses more on IT security and risk management. As a part of my individual project, I want to narrow my search to COBIT and ISO standards. ISO standards are used globally more often than COBIT due to the fact that ISO fits more smoothly into different frameworks of most of the countries in terms of business processes since COBIT addresses standards only, while ISO concerns about both standards and processes (e.g. organizational security, personnel security, communications and operations management, business continuity management, and so on). I will show it in my report supporting my ideas with relevant cases and examples from certain companies.

Let us talk a little bit about COSO (the Committee of Sponsoring Organizations of the Treadway Commission) and its role in IT Governance. As was mentioned earlier COSO is a very broad set of standards (to be precise a private sector organization) that focuses not only on IT Governance control and improvement, but also and mostly focuses on financial reporting’ quality, internal control and corporate governance. This organization was formed in order to find out factors that lead to frauds in financial reporting as well as give recommendations how to prevent these factors for companies, auditors, educational institutions and so on. Among sponsoring organizations within the Committee there are “five major professional associations in the United States, the American Accounting Association, the American Institute of Certified Public Accountants, Financial Executives International, the Institute of Internal Auditors, and the National Association of Accountants (now the Institute of Management Accountants)” (1). In spite of the fact that there is a sponsorship deal, the Commission is independent from all of the sponsoring organizations, and has representatives from industry, public accounting, the New York Stock Exchange, and different investment firms.

COSO defines Internal Control as “a process, effected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives” in such categories as effectiveness and efficiency of operations, reliability of financial reporting and compliance with applicable laws and regulations. IT Governance is part of internal control within the COSO framework. Therefore, different frameworks for IT security and management (COBIT, ITIL, ISO, and so on) should comply with COSO organization’s rules and requirements. While COSO is generally accepted as the internal control framework for enterprises, COBIT, ISO and other similar frameworks are the generally accepted internal control frameworks for IT.

Read More : http://citebm.business.uiuc.edu

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