As modern dental practices become more dependent on information technology, there will be an increasing need for secure acquisition, management, and transmission of the data in a patient�s record. Until now, the responsibility for data security has largely been left to the individual practices� discretion. With the passing of HIPAA, it is mandated by law that the data contained in a patient record be securely stored and protected from disclosure to unauthorized parties. Noncompliance with HIPAA regulations carries stiff penalties of up to 10 years in prison and $250,000 in fines.
At this point, you are probably asking, "What is HIPAA and why are there such ominous repercussions for noncompliance?" HIPAA is the Health Insurance Portability and Accountability Act passed in 1996. Its original intent was to insure "portability" when an employee covered by a group plan changed employers. That intent grew to encompass a variety of concepts centered around administrative simplification, standardization of insurance code sets, national identifiers, and privacy rights. This was done with the belief that mandating standardization of the manner in which health information is processed will reduce costs and administrative overhead associated with processing insurance claims, as well as managing patient information while protecting privacy rights.
Although HIPAA was passed in 1996, the HIPAA standards are being finalized along a timetable that might extend into 2002. The compliance deadline for large organizations (annual revenues exceeding $5 million) is 24 months after the final publication of rules. For small organizations (annual revenues less than $5 million), the deadline is 36 months. The rules that have reached final publication are for transactions, code sets, and privacy. In this article, I will examine how the final rule for privacy affects your practice. I also will discuss the software/hardware technologies that will assist you in meeting the requirements for compliance with HIPAA standards for privacy.
The HIPAA Privacy Rule applies to the protection of a patient�s health information (in electronic form) from unauthorized disclosure to health-care providers, insurance companies, employers, clearinghouses, and any party who may be involved in the use of such information. The following examples of privacy breaches from the Federal Register DHHS Standards for Privacy of Individually Identifiable Health Information (Vol.65, No.250) illustrate the relevance of this rule:
-- A Michigan-based health system accidentally posted the medical records of thousands of patients on the Internet (The Ann Arbor News, Feb. 10,1999).
-- A Utah-based pharmaceutical benefits-management firm used patient data to solicit business for its owner, a drug store (Kiplinger�s, February 2000).
-- An employee of the Tampa, Fla., health department took a computer disk containing the names of 4,000 people who had tested positive for HIV, the virus that causes AIDS (USA Today, Oct. 10, 1996).
-- The health insurance claims forms of thousands of patients blew out of a truck on its way to a recycling center in East Hartford, Conn. (The Hartford Courant, May 14, 1999).
-- A patient in a Boston-area hospital discovered that her medical record had been read by more than 200 of the hospital�s employees (The Boston Globe, Aug. 1, 2000).
-- A Nevada woman who purchased a used computer discovered that the computer still contained the prescription records of the customers of the pharmacy that had previously owned the computer. The pharmacy database included names, addresses, social security numbers, and a list of all the medicines the customers had purchased. (The New York Times, April 4, 1997 and April 12, 1997).
-- A speculator bid $4,000 for the patient records of a family practice in South Carolina. Among the businessman�s uses of the purchased records was selling them back to the former patients. (New York Times, Aug. 14, 1991).
-- In 1993, the Boston Globe reported that Johnson and Johnson marketed a list of five million names and addresses of elderly incontinent women. (ACLU Legislative Update, April 1998).
-- A few weeks after an Orlando woman had her doctor perform some routine tests, she received a letter from a drug company promoting a treatment for her high cholesterol. (Orlando Sentinel, Nov. 30, 1997).
No matter how or why a disclosure of personal information is made, the harm to the individual is the same. In the face of industry evolution, the potential benefits of our changing health-care system � and the real risks and occurrences of harm � protection of privacy must be built into the routine operations of our health care system.
What does all of this mean for your dental practice? Since electronic health records are being referenced, your practice-management software, computer network, staff, and any parties involved in the exchange of patient health information with your practice must be governed by written policies or procedures that control access to the patient record. Physical and technical safeguards must be implemented to enforce these policies and procedures. Physical safeguards include controlled access to facilities that house computer systems that store or have access to patient data. Technical safeguards must be provided for software, services, and products that secure your technology infrastructure. These safeguards can be hardware-based (such as tokens, smart cards, fingerprint scanners, etc.) or software-based (such as passwords, cryptography, Public Key Infrastructure, digital signatures, etc.). The HIPAA standards do not specify the use of a particular technology platform, but they do specify security objectives that must be achieved in order for an organization to be compliant. The key requirements of HIPAA security standards are:
-- Entity Authentication
-- Access Controls
-- Audit Controls
-- Data Confidentiality
-- Data Authentication
-- Nonrepudiation
-- Communications/Network Controls
-- Disaster Recovery
Public Key Infrastructure (PKI) technology stands out as a comprehensive technology platform that addresses the concerns raised by each of the security requirements. What is Public Key Infrastructure technology? An industry-leading PKI technology vendor provides the following explanation:
The core of PKI technology is the key pair. With PKI, each end user is issued a key pair, consisting of a public key and a private key. The key pair is a pair of numbers with a unique mathematical relationship. Keys are used for encryption/decryption and digital signing. Data that is encrypted with a public key can be decrypted only with the corresponding private key. Private keys are used to generate and attach a digital signature and the corresponding public key to verify that signature. For example, a private key is tightly held by the owner in software embedded in the Web browser or in hardware downloaded to a smart card or token. The corresponding public key is available to others who are communicating, conducting transactions, or exchanging data over the Internet with the owner of the key pair.
A PKI system indisputably binds the identity of the owner to the key pair. In a well-managed PKI, a trusted authority (i.e., a "Certificate Authority") corroborates the identity of the owner. This is what makes PKI a robust method for security and enables organizations to trust the identity of individual users. The digital certificate is a data file that embeds the user�s public key. It follows a rigid format (the X.509 standard for certificates) to include information on the holder of the certificate and on the authority that issued the certificate, as well as the digital signature of the Certificate Authority (CA), the organization that vouches for an individual. The digital certificate is presented as proof of an individual�s identity in cyberspace, much like a driver�s license is presented in the physical world. Since an individual�s digital certificate embeds the public key of the public/private key pair, it is tied to the corresponding private key held by that individual.
Now we�ll examine how PKI applies to each of the key HIPAA security requirements.
-- Entity Authentication. The requirement calls for entity authentication to restrict access to resources. Each user in a system must be uniquely identified. PKI provides for strong authentication (versus a password, which is weak authentication). A digital certificate authenticates an entity (end-user or authority) whose identity is bound to that certificate. Digital certificates provide a unique identifier that will meet HIPAA requirements for uniquely identifying individuals. Each certificate has a unique serial number and DN (distinguished name), as specified by the X.509 certificate and X.500 directory standards. To access information, an entity must present a valid certificate (not expired or revoked) that has been given access rights to that particular information. This digital certificate may reside on the end user�s computer, a smart card, or a token. Moreover, an end-user�s certificate contains the digital signature of a trusted "Certificate Authority" that has approved the individual and stands behind that person�s certificate. This ensuring that the individuals are who they say they are.
-- Access control. The mechanism for access control would restrict individual access to resources and allow access only by privileged entities (with a business need to access it). Organizations can use user-based, role-based, or context-based access. Policies and procedures must be in place to establish that only certain users are permitted access to certain information. A PKI solution can support these policies and procedures. An end-entity�s (user�s) digital certificate is used to gate access to resources. For example, any file on a server (Intranet, Extranet or Internet) can be subjected to access control. To be granted access to particular information, the user�s digital certificate must be valid and have the right to that information. Access Control List (ACL) rules are created to provide users with read/write access to specific directories or files. For user-based access, an ACL rule can be defined using the certificate�s common name; for role-based access, an ACL rule can be set up based on a role field in a certificate extension.
-- Audit controls. Mechanisms must be put in place to record and examine system activity. To log access to medical information, the system must be able to track the actions of individuals. PKI supports this by authenticating users through their digital certificate, thus providing a method of identity to uphold individual accountability. As part of the administrative functions, PKI-enabled software applications provide the ability to log all PKI events with the identity of the individual performing the action. Logging is configurable and events are time-stamped.
-- Data confidentiality. With PKI, data is made confidential by encrypting it with the recipient�s public key. This ensures that only the intended recipient can decrypt the information. Only the corresponding private key (of the recipient�s) in a public/private key pair can be used to decrypt the information.
-- Data authentication. This is to ensure that data has not been altered or destroyed in an unauthorized manner. PKI supports data authentication through digital signatures. A digital signature can be applied to data to ensure its integrity. The process of signing information involves applying a hash function (mathematical function) to the document or message � in other words, creating a digest and then encrypting the digest with the sender�s (or originator�s) private key. The resulting bit string is attached to the document/message as a signature.
To verify the integrity of the document/message, the recipient decrypts the digest with the sender�s public key (which is embedded in the sender�s digital certificate). The recipient also applies the same hash function to the document/message, creating a digest from the transmitted document/message. The decrypted digest is compared to the original digest, and if these two are the same, then the recipient is assured that the message has not been altered in transit. Also, the identity of the signer is proven since only the private key of the sender could have been used to encrypt the digest that was then decrypted by the sender�s corresponding public key.
-- Nonrepudiation. When using electronic signatures, the signer must not be able to later disavow the transaction. Currently, PKI technology is the only existing technology that can provide non-repudiation. PKI-enabled software applications use digital signatures for nonrepudiation since the identity of the signer can be verified by using the signer�s public key. Only the holder of the corresponding private key could have signed the document.
-- Communications/network controls. To ensure that communications over open networks cannot be easily intercepted, some form of encryption is required and provisions must be made for integrity controls, message authentication, access controls, the audit trail, and entity authentication. For communications over a network, messages are encrypted by using the intended recipient�s public key. Only the intended recipient�s private key can decrypt the message, which assures the sender that only the intended recipient can read its contents. PKI supports strong encryption up to 2048 bits (asymmetric) and 128 bits (symmetric). Integrity controls and message authentication are addressed by using digital signatures as described above. Access controls and entity authentication are addressed by using digital certificates.
-- Disaster Recovery. Irrespective of HIPAA regulations, every practice should have a comprehensive Disaster Recovery Plan (DRP) in place. HIPAA adds a security component to this mix. The practice�s DRP can�t be complete without a clear security position. Health-care organizations incorporate computer networks, with external ports (Internet connectivity, modems, and other communication ports), that have become important tools to assist in "best care practices." The challenge is that these "open systems" also create gaping holes for unwelcome intruders. To facilitate a strong security position and be ready for a potential disaster, health-care providers need to take the same steps that the financial community has embraced for years: constant, vigilant enterprise-security review, along with a solid disaster recovery plan.
Vigilant security starts with a "Technical Security Assessment." This assessment has four objectives:
-- Identify the technical requirements for information security
-- Provide a high-level assessment of the technical threats and risks to information
-- Assess effectiveness of existing policies and countermeasures
-- Provide recommendations to improve the information-security environment in an efficient and cost- effective manner
When HIPAA is added to this list, one more objective applies:
-- Identify areas of noncompliance with HIPAA regulations
A Technical Security Assessment encompasses both external (public) and internal (private) network- access points. The internal assessment examines the organization�s information-security posture from the position of a knowledgeable insider. The external assessment examines the organization from the perspective of an outsider. This is the view that a hacker might have if such a person were to target the organization.
The Technical Security Assessment identifies vulnerable points. Once the assessment is completed, all data is analyzed and a report is generated that makes recommendations to minimize the risks. All vulnerabilities (high, medium, and low) are brought to the organization�s attention with recommended remedies.
"High" vulnerabilities must be addressed immediately. They are found on systems and servers that can be easily and immediately compromised. Based on the information provided by the assessment, potential damage scenarios are created. For each scenario, recommendations are developed to manage the potential risk. This information is provided in a report, as part of risk identification. For HIPAA compliance, the assessment team also must analyze the organization against the privacy and security requirements of HIPAA regulations. For each area of noncompliance, a rating is developed to show the extent of noncompliance. Recommendations are developed to assist the organization to become HIPAA-compliant. It should be recognized that, irrespective of HIPAA, hospitals and any organization with patient health records or other sensitive information should conduct a Technical Security Assessment. Only then will an organization understand its risks and where they are situated.
Disaster Recovery Planning: First Steps
Once the assessment is completed, it probably will reveal several areas that need addressing, including security policy development, incident response plans, security awareness training, 24 x 7 network- intrusion monitoring, and alarm-reporting. All of these are vitally important, but one major concern � especially for health-care organizations � is a well thought out, documented Disaster Recovery Plan (DRP).
Before a DRP is developed, a requirements analysis is performed to determine the necessary actions to be performed � internally or with an external entity � to develop an actual DRP. What this means is that information is gathered, analyzed, and then reported to define what elements the DRP will have to include. The DRP preparation plan includes four stages:
-- Business Impact Analysis
-- Developing the Disaster Recovery Plan
-- Testing the Disaster Recovery Plan
-- Proposed Project Plan
For each of the first three stages, the current state of a DRP within an organization is identified and recommendations are made for further actions. The proposed project plan then outlines the steps needed to complete the DRP, if required, and estimates the level of effort required.
The most important stage is the business impact analysis, in which an attempt is made to determine the approximate impact on the staff and the business if a particular disaster occurs. A significant aspect of this phase entails identifying critical applications in all departments and the maximum amount of time a particular system or service can remain unavailable before an adverse impact is realized. This takes a thorough investigation by qualified, experienced individuals because every factor must be examined, from current network architecture to the history of natural disasters in the organization�s location.
The Bottom Line: Fundamental Issues
Overall, when it comes to technical security, you should be able to answer these questions:
-- Do I have a firm grasp of where my network and other security vulnerabilities are today? Have they been documented?
-- When was the last security assessment performed? Was it documented? Were the "fixes" completed and then retested? Were they documented?
-- Can someone outside or inside obtain information that he or she shouldn�t have? What documentation do I have to confirm this?
-- Do our security protections meet or exceed HIPAA Security Rule requirements? What documentation is available confirming this?
-- What disaster recovery plans do we have for servers, critical applications, and patient records? Is the plan documented? Has it been tested? Has it been reviewed by a qualified third party?
-- Are procedures in place to monitor and regularly reassess security? Is there documentation that procedures are followed?
If "I don�t know" � or worse, "no" � is the answer to even some of these questions, the organization should go to work on a Technical Security Assessment. If the answer to Question 5 above from any health-care provider is "No, there isn't a documented disaster recovery plan," the organization and, perhaps, patient lives are clearly at risk. It is imperative to develop a disaster recovery plan, with the first action item being a Technical Security Assessment.
Achieving HIPAA compliance will require a multifaceted approach to managing your patient data. There is no magic bullet for your technology needs, but there are many choices. Online applications offer many of the security features discussed above at an attractive cost/benefit ratio. Health-care organizations such as health plans, health-care providers, and clearing houses are increasingly using the Internet to reduce administrative costs, decrease paperwork, streamline communications, and increase efficiency. The Internet meets consumers� growing demand for more access to health information and allows organizations to increase quality of care and, at the same time, enhance revenues by adding new online services. Applications of the Internet in health care are extensive, including verification of insurance eligibility, online patient records, claims submission/ processing/payment, checking lab results, prescription fulfillment, research collaboration, consultations, referrals, accounting and billing, procurement of medical supplies, and communication with remote employees or locations. As part of this trend, application-service providers (ASP) have emerged that are delivering the full range of health-care specific applications over the Internet from practice management to benefits administration.
ASPs are offering efficient and cost-effective information systems online. Competitive health-care organizations are moving quickly to harness the power of the Internet to reap the economic rewards and improve quality of care. Major forces, based on market demands, risk of litigation, and impending regulations, call for securing health information. Creating and implementing policies, procedures, and technology solutions to ensure that your practice is HIPAA-compliant will be a major undertaking. Begin the process now because enforcement of HIPAA is just around the corner.
