HIPAA Security Rule

1. HIPAA Summit WestJune 6, 2003HIPAA Security: Documentation and Evaluation Requirements Under the HIPAA Security Rule - Overview and Practical Guidance Jeff Jinnett, CISSPPartnerEpstein Becker & Green, P.C.

2. HIPAA Security Rule • Proposed Security Rule issued in 1998 • Final Security Rule published in Federal Register on February 20, 2003 • compliance date of April 21, 2005 for all covered entities other than small health plans, which must comply by April 21, 2006 • But HIPAA act itself mandates covered entities who maintain or transmit health information to maintain reasonable and appropriate administrative, technical and physical safeguards to ensure the integrity and confidentiality of the health information and to protect against security threats and unauthorized disclosures (see Section 1173(d)(2)) • And security requirements in Privacy Rule require appropriate security for all PHI, regardless of its format (see Section 164.530(c)) • also, security access controls are necessary in order to implement the Privacy Rule minimum necessary analysis

3. Scope of Security Rule • Represents a “floor of protection”, not best practices • CE’s can implement security measures that exceed the mandated floor • Rule is technology-neutral • Rule is scalable - larger organizations expected to commit more resources • Covers only electronic Protected Health Information • Rule covers electronic PHI both in transmission and at rest (i.e., in storage) • DHHS reserves right to propose security standards for other types of PHI in future • Electronic signatures to be covered in separate rule • De-identified health information not covered

4. Structure • 18 security standards implemented through 35 “required” and “addressable” implementation specifications • Security standards are listed in order of importance • “requirement” and “implementation feature” of proposed rule became “standard” and “implementation specification” in final rule • Represents a reduction from the 69 implementation features in the proposed rule, with some formerly mandatory implementation features reduced to addressable implementation specifications • Definitions in final Security Rule conformed to definitions in the Privacy Rule and placed in new Section 164.103 (e.g., PHI definition)

5. Structure • Section 164.306(a) describes permissible level of risk, requiring covered entities to: • ensure confidentiality, integrity and availability of all electronic PHI • protect against any reasonably anticipated threats or hazards to the security or integrity of such information • protect against any reasonably anticipated uses or disclosures of such information that are not permitted under the Privacy Rule • ensure compliance with the Security Rule by the covered entity’s workforce

6. Structure • In deciding which security measures to use, a covered entity must take into account: • the size, complexity and capabilities of the covered entity • the CE’s technical infrastructure, hardware and software security capabilities • the costs of the security measures • the probability and criticality of potential risks to electronic PHI • note that cost is only one factor and not an excuse for failure to comply with security standards • Final rule heightens emphasis on internal risk analysis and risk management; risk analysis should consider “all relevant losses” that would be expected if security measures are not in place • DHHS notes that analysis of data flows and data uses that CE’s undertake to comply with Privacy Rule could be the starting point for the risk analysis under the Security Rule

7. Transition to Management-Based Final Rule • The 55 technical standards referenced in the proposed rule have been dropped in the final rule because they were not up to date or comprehensive enough to satisfy DHHS • Final rule references WEDI/SNIP white papers and the NIST 800 series (e.g., NIST SP 800-14, SP 800-16 and SP 800-33) • See NIST-URAC effort at developing a cross-walk between the NIST security standards and HIPAA • Only a few of the implementation specifications are required, with the majority being “addressable” • e.g., security training is required, but training in password management is addressable, since if the CE uses biometric access controls, password training is not relevant • DHHS anticipates that CE’s likely will meet some of the Security Rule requirements through implementation of the Privacy Rule requirements (e.g., email authentication procedures and access controls)

8. Addressable Implementation Specifications • Entity has three options: • (1) implement the addressable implementation specification, if it is reasonable and appropriate; • (2) if implementation of the addressable implementation specification is not reasonable or appropriate, implement an appropriate and reasonable alternative security measure to accomplish the purposes of the standard; or • (3) not implement anything if the addressable specification is not reasonable and appropriate and the security standard can still be met. • Rationale for not adopting addressable implementation specification must be documented, for options (2) and (3) above

9. Security Categories • Administrative Safeguards • nine security standards • Physical Safeguards • four security standards • Technical Safeguards • five security standards • combines the “technical security services” and “technical security mechanisms” of the proposed Security Rule • 35 Required (R) and Addressable (A) Implementation Specifications

10. Category I: Administrative Safeguards • (1) Security Management Process [policies and procedures to prevent, detect, contain and correct security violations - the “foundation” of security] • (i) risk analysis (R) [assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic PHI held by entity] • (ii) risk management (R) [implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level] • (iii) sanction policy (R) [apply appropriate sanctions against workforce members who fail to comply with security policies and procedures]; and • (iv) information system activity review (R) [procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports]

11. Category I: Administrative Safeguards • (2) Assigned Security Responsibility (R) [identify security official responsible for development and implementation of the required security policies and procedures] • (3) Workforce Security [implement policies and procedures to permit or deny access by the entity’s workforce to electronic PHI, as appropriate] • (i) authorization and/or supervision (A) [procedures relating to workforce accessing PHI or locations where PHI might be accessed] • (ii) workforce clearance procedure (A) [procedures to determine if access is appropriate]; and • (iii) termination procedures (A) [terminate employee’s access to PHI when employment ends or as otherwise required]

12. Category I: Administrative Safeguards • (4) Information Access Management [policies and procedures to authorize access to electronic PHI in conformity with Privacy Rule] • (i) isolating health care clearinghouse functions (R) [if clearinghouse is part of larger organization, protect unauthorized access of clearinghouse’s PHI by larger organization] • (ii) access authorization (A) [policies and procedures for granting access to PHI]; and • (iii) access establishment and modification (A) [establish, document, review and modify user’s right of access to workstation, transaction, program or process based on entity’s access authorization policies]

13. Category I: Administrative Safeguards • (5) Security Awareness and Training [for both workforce and management] • (i) security reminders (A) [periodic security updates]; • (ii) protection from malicious software (A); • (iii) log-in monitoring (A) [monitor log-in attempts and report discrepancies]; and • (iv) password management (A) [create, change and safeguard passwords] • (6) Security Incident Procedures • (i) response and reporting (R) [identify and respond to suspected or known security incidents; mitigate harmful effects; document incidents and outcomes]

14. Category I: Administrative Safeguards • (7) Contingency Plan [protect systems containing PHI from emergencies and other occurrences, such as fire, vandalism, system failure and natural disaster] • (i) data backup plan (R) [create and maintain retrievable exact copies of PHI] • (ii) disaster recovery plan (R) [restore any loss of data] • (iii) emergency mode operation plan (R) [enable continuation of critical business processes] • (iv) testing and revision procedures (A) [periodic testing and revision of contingency plans]; and • (v) applications and data criticality analysis (A) [assess relative criticality of specific applications and data in support of contingency plan]

15. Category I: Administrative Safeguards • (8) Evaluation (R) [performance of a periodic technical and non-technical evaluation] • evaluation covers all components of the Security Rule and not just the information systems • (9) Business Associate Contracts and Other Arrangements [permits a business associate to create, receive, maintain or transmit electronic PHI on the CE’s behalf only if the BA gives assurances to appropriately safeguard the PHI] • (i) written contract or other arrangement (R) [“other arrangements” if CE and BA are governmental entities: see Section 164.314(a)]

16. Category I:Administrative Safeguards (Notes) • “Information system activity review” replaces “internal audit” from proposed rule - no formal audit required • No absolute requirement for background checks, but some personnel screening is required based on risk analysis • Responsibility for security compliance must reside with one individual within covered entity -Chief Privacy Officer could be named Chief Security Officer as well • “Certification” of proposed rule became “Evaluation” in final rule • Technical and non-technical “evaluation” by covered entity or by third party accreditation agency required, based initially on standards of Security Rule and thereafter in response to significant changes in entity’s risk profile or IT systems • Security training is “critical activity”, regardless of entity’s size • CE need not provide security training for BA’s - cover in contract • Business associate contract replaces “chain of trust” agreement

17. HIPAA to Spur Appointment of Chief Security Officers? • “Serious About Security” in the February 23, 2002 issue of Information Week reports that: • the Chief Security Officer job function in the financial services industry is becoming the model for the healthcare industry • The CSO job is being elevated to C-level status because the risks to people and data have “multiplied in complexity within just a few years” • 41% of CEO’s are now actively involved in setting security policy • About 20% of Meta Group’s 2,000 corporate clients have CSO’s on board, and it is predicted that number will grow to 40% within 5 years

18. Category II: Physical Safeguards • (1) Facility Access Controls [limit physical access to IT systems and the facilities in which they are housed, while permitting authorized access] • (i) contingency operations (A) [allow facility access in support of restoration of lost data under disaster recovery plan and emergency mode operations plan in event of emergency]; • (ii) facility security plan (A) [safeguard facility and equipment from unauthorized physical access, tampering and theft]; • (iii) access control and validation procedures (A) [control and validate access to facility and software for testing and revision purposes, based on role or function]; and • (iv) maintenance records (A) [document repairs and modifications to facility security components] • (2) Workstation Use (R) [specify proper functions and attributes of surroundings of workstations accessing PHI]

19. Category II: Physical Safeguards • (3) Workstation Security (R) [physical safeguards for workstations that access PHI, to restrict access to authorized users] • (4) Device and Media Controls • (i) disposal (R) [address final disposition of electronic PHI and/or the hardware or electronic media on which it is stored]; • (ii) media re-use (R) [removal of electronic PHI from media before media is made available for re-use]; • (iii) accountability (A) [maintain record of movements of hardware and electronic media and any responsible person]; and • (iv) data backup storage (A) [create a retrievable, exact copy of electronic PHI, when needed, before movement of equipment]

20. Category II: Physical Safeguards (Notes) • Facility access controls • Covered entity responsible for considering facility security even in situations where it shares space within a building • workstation use • includes portable devices, such as laptops • device and maintenance controls • addressable requirement of data backup and storage: backup should be sufficient to allow entity to continue business as usual • “Accountability” does not address audit trails within systems or software, but rather the recording of receipt and removal of hardware and/or software into and out of a facility, traceable to a person

21. Category III: Technical Safeguards • (1) Access Control [policies and procedures to allow access only to authorized persons and programs] • (i) unique user identification (R) [assign a unique name and/or number for identifying and tracking user identity] • (ii) emergency access procedure (R) [obtain necessary electronic PHI during emergency] • (iii) automatic logoff (A) [terminate electronic session after predetermined time of inactivity]; and • (iv) encryption and decryption (A) [mechanism to encrypt or decrypt electronic PHI] • (2) Audit Controls (R) [hardware, software and/or procedural mechanisms that record and examine activity in IT systems containing or using electronic PHI]

22. Category III: Technical Safeguards • (3) Integrity [protect electronic PHI from improper alteration or destruction] • (i) mechanism to authenticate electronic PHI (A) • (4) Person or Entity Authentication (R) [verify that a person or entity seeking access to electronic PHI is the one claimed] • (5) Transmission Security [technical security measures to guard against unauthorized access to electronic PHI that is being transmitted over an electronic communications network] • (i) integrity controls (A) [security measures to ensure that electronically transmitted PHI is not improperly modified without detection until disposed of]; and • (ii) encryption (A) [mechanism to encrypt electronic PHI whenever deemed appropriate]

23. Category III: Technical Safeguards (Notes) • References in proposed rule to 55 technical standards eliminated; new references to NIST “800 Series” security guides • Automatic logoff and encryption now addressable requirements • Audit controls are mandatory, but intensity of audit is determined by risk assessment • Digital signatures and “soft tokens” can be used for person or entity authentication • “Open network” term eliminated and use of encryption for network transmissions is addressable, not required - encryption is required if risk of interception is “significant” • telephone voice response and “faxback” covered under rule; faxes covered if sent by computer

24. Documentation Requirement • Covered entities must maintain written documentation (which may be electronic) of the implemented policies and procedures and of any required action, activity or assessment • need not be “formal”, but must be detailed enough to communicate the security measures and to facilitate periodic evaluations and be updated as needed to reflect the security measures currently in effect • update documentation in response to environmental or operational changes affecting the security of the electronic PHI • covered entity must document rationale for non-use of addressable implementation specifications • CE must maintain documentation for six years from the date of its creation or the date when it was last in effect, whichever is later

25. Evaluation Requirement • The “evaluation” security standard requires the performance of a periodic technical and non-technical evaluation, based initially on the standards of the Security Rule and thereafter in response to the CE’s environment or operations affecting the security of electronic PHI, that establishes the extent to which the CE’s security policies and procedures meet the requirements of the Security Rule. • The evaluation can be done by the entity’s internal workforce or by a third party “accreditation agency”, which would be acting as a business associate (e.g., URAC HIPAA Security Accreditation) • Documentation and evaluation must be updated if the CE’s risk profile changes materially (e.g., due to the acquisition of a new subsidiary or a change in the CE’s IT systems) • URAC HIPAA Security Accreditation valid for 2 years, subject to interim update (see “www.urac.org”)

26. Some Preliminary Conclusions • Final Security Rule not a repudiation of the proposed Security Rule, but rather is a modification to provide flexibility and scalability • Unintended result - no safe harbor created for CE’s • Covered entities required to create documentation and evaluation, with one officer responsible for compliance • Documentation and evaluation to be kept current • Consider reference to industry standards and best practices, especially where an addressable implementation specification is not implemented and an alternative security measure is adopted • Potential litigation risk if plaintiffs commence state actions based on tort law or unfair business practices and refer to HIPAA as the de facto federal standard of care for privacy and security • Possible resulting incentive for CE’s to rely on outside privacy and security experts

27. The HIPAA Challenge HIPAA Project Implementation and the HIPAA Security Rule “Documentation” and “Evaluation”Requirements

28. HIPAA Documentation and Evaluation Requirements - Litigation Issue • CE’s are required to document their compliance and either self-evaluate or obtain a third party evaluation as to compliance with the HIPAA Security Rule • CE’s may seek URAC HIPAA Security accreditation or other third party evaluation • CE’s may wish to self-evaluate and obtain HIPAA insurance, rather than pay third party evaluation fees • No private right of action under HIPAA, but plaintiffs in state tort or unfair trade practices actions may cite to HIPAA as the de facto federal standard of care for privacy and security, which CE violated, and seek punitive damages, urging the jury to “send a message” to the healthcare industry • HIPAA documentation and evaluation can be useful to show the CE’s good faith efforts to implement effective privacy and security policies and procedures • compensatory damages would be paid to state court plaintiffs, but punitive damages might be avoided

29. Document Entire HIPAA Project Due to the privacy and security litigation risk, CE’s should consider documenting not just their efforts to comply with the HIPAA Security Rule, but rather their entire HIPAA project, in a summary due diligence document, which also could serve as a HIPAA risk mitigation plan

30. Board of Directors Duty of Care and Application of the Business Judgment Rule • Under state law, directors are expected to perform their duties with due care and to be reasonably well-informed when making decisions, taking the best interests of the corporation into account • In many states, so long as the directors acted with due care, they are not personally liable unless they are guilty of gross negligence or willful misconduct • If directors fail to act with due care, they can be held liable if only guilty of simple negligence • A due diligence record can help establish the business judgment rule defense for the CE’s board of directors • Due diligence record made a part of periodic reports to the Board of Directors may be admissible in litigation as a pre-existing business record kept in the normal course

31. HIPAA Criminal Penalties • Criminal penalties: Wrongful Use/Disclosure of Individually Identifiable Health Information • Knowingly using a “unique health identifier” or knowingly obtaining or disclosing individually identifiable health information to another person • $50,000 maximum penalty, • One (1) year maximum imprisonment, or • Both • Offenses committed under “false pretenses” • $100,000 maximum penalty, • Five (5) years maximum imprisonment, or • Both • Offenses committed with the intent to sell, transfer or use individually identifiable health information for commercial advantage, personal gain or malicious harm • $250,000 maximum penalty, • Ten (10) years maximum imprisonment, or • Both

32. HIPAA Civil Penalties • Section 1176 of HIPAA establishes civil monetary penalties: • Penalties may be not more than $100 per person per violation of a provision • Penalties may be not more than $25,000 per person per violation of an identical requirement or prohibition for a calendar year • Interim HIPAA Enforcement Rule issued • Due diligence record can establish the CE’s good faith efforts to comply with HIPAA and can help the CE avoid or mitigate potential criminal and civil penalties in the event of a misuse or wrongful disclosure of PHI or other HIPAA violation

33. Other Benefits From a HIPAA SummaryDue Diligence Record • For public companies, due diligence record can help establish defense under securities laws • Although accreditation agencies are not HIPAA enforcers, they may in the future decide to incorporate some HIPAA standards into their accreditation process (e.g., Joint Commission on Accreditation of Healthcare Organizations (JCAHO) and National Committee for Quality Assurance (NCQA)) and due diligence record can be useful in these accreditation reviews • Due diligence record can match CE’s HIPAA plan against industry standards and “best practices” - this can be especially helpful in cases where an addressable implementation specification has not been implemented

34. Due Diligence Record Also Servesas a Risk Mitigation Plan • Ensures that the enterprise HIPAA project is correctly prioritized from a technical, business and legal point of view in case a significant percentage of the enterprise cannot be brought into compliance by the deadline • “Bottlenecks” are identified which could delay full and timely project compliance • Reliance on outside HIPAA experts and guidance can be documented • CE’s approach can be matched to approach taken by peer companies within industry

35. Obtain Third Party “Best Practices” Confirmations to the Extent Possible • Independent HIPAA “best practices” confirmations • audit by outside HIPAA consultant • legal review of HIPAA interpretation (e.g., memorandum of law to support interpretation of compliance with de-identification “safe harbor”, combined with statistical expert report) • Qualification for HIPAA insurance (e.g., Chubb Executive Risk endorsement to D&O policy and AJ Gallagher/Healthcare First policy) • Seek to have CE’s approach cited in publication as example of “best practices” • SAS 70 or comparable audit

36. Identify and Document “External Validators” • Identify any listserv submissions (e.g., Hipaadvisory and WEDI) which support enterprise’s HIPAA security approach • Match enterprise approach against industry guidelines (e.g., HIPAA Security Summit Guidelines or the Association of American Medical Centers Guidelines for Academic Medical Centers on Security and Privacy) • Compare enterprise project status to peer companies as reported in healthcare industry HIPAA status surveys (e.g., Gartner Group and First Consulting Group)

37. Identify and Document “External Validators” • Compare enterprise definitions of internal and external risk against industry definitions (e.g., AFEHCT Security Best Practices Proposal) • Identify external validators for assessment, remediation and testing tools used (e.g., SEI Octave™ risk assessment methodology, WEDI Standard National Implementation Process (SNIP) Security and Privacy Workgroup White Paper or the CPRI Toolkit: Managing Information Security in Health Care) • Review special security issues (e.g., email security) against industry white papers (e.g., AHIMA email white paper)

38. HIPAA: An Enterprise ProcessManagement Challenge • Cost of HIPAA compliance and Solution Approach • 3 to 4 times the information technology (IT) cost of Y2K (Fitch Report, “HIPAA: Wake-UP Call for Health Care Providers”) • Although the bulk of the cost will be in IT remediation, only 30% of HIPAA impact will be on IT, while 70% of impact will be on business processes (Lee Barrett, WEDI and EHNAC) • Therefore, an enterprise process management (EPM) approach is better suited to HIPAA than a pure IT-driven approach

39. Conclusion: Institute and Maintain an Enterprise Process Management Approach to Secure Your Healthcare Enterprise • Avoid fragmented HIPAA project teams, where issues can fall between the cracks • Don’t lose the forest for the trees • Map the enterprise business processes and existing IT infrastructure security features against the mandated security requirements - only business processes and IT infrastructure involving electronic PHI are relevant • Identify third party confirmations as to “best practices” and external validators which match your project approach, especially if they can support alternative measures used in place of addressable implementation specifications • Document compliance with security mandates and keep the documentation updated • Produce a summary due diligence document (e.g., 20-30 pages) which can be produced to explain your privacy and security approach

40. Additional HIPAA Materials • For the following additional HIPAA reference materials: • 15 page overview of the HIPAA Security Rule • 27 page annotated template for a HIPAA project due diligence record and risk mitigation plan • HIPAA enterprise process management (EPM) project approach materials Contact: Jeff Jinnett, CISSP Partner Epstein Becker & Green, P.C. 111 Huntington Avenue - 26th Floor Boston, MA 02199 Email: jjinnett@ebglaw.com Tel. No.: 617-342-4049

41. QUESTIONS AND ANSWERS