Disclaimer

1. Disclaimer • This Presentation is provided “as is” without any express or implied warranty. This Presentation is for educational purposes only and does not constitute legal advice. If you require legal advice, you should consult with an attorney.

2. Section III Roles and Responsibilities • Preview of key points • In this section, we will discuss the roles and responsibilities of the following: • Information security officer • Privacy officer • Information security committee • Organizational models for information security

3. Information Security Officer (ISO) • Per HIPPA, this position is necessary “to provide an organizational focus and importance to security and to pinpoint responsibility” • Responsibilities include “the management and supervision of” • The use of security measures to protect data • The conduct of personnel in relation to the protection of data • HIPPA requires “assigned responsibility” for the security program, that is, must document “who” • In small organizations (e.g., small practice), this position may be less than fulltime (e.g., office manager)

4. Privacy Officer • HIPPA requires this be a single individual, not a board, for better responsibility and accountability • However, the privacy officer may convene a board to assist • The role is to be “responsible for development of policies and procedures for the use and disclosure of protected health information”.

5. Information Security Committee • By function: • Chair: Information Security Officer • CIO • CFO • HR • Legal • Risk management • Audit • QA • Corporate compliance • Privacy officer • Physician rep • Nursing rep • Research rep • Patient relations • Labs • By ENTITY: A representative of each major covered entity in organization (members should wear multiple hats to keep committee size manageable)

6. Committee responsibilities (suggested) • Promote the information security program throughout the organization • Give advice and support to the information security officer • Review and approve policies and standards • Review and approve education programs • Mediate problematic access (use/disclosure) requests Note: Committee is not an explicit requirement of HIPPA. This is a suggestion to use for compliance awareness and to use as a mechanism for removing obstacles to compliance

7. Organizational Models for Information Security • Considerations: • Recognize full scope of information security management: • Physical controls • Technical controls • Policies • Procedures • Education • Recognize operational responsibilities, such as: • Access administration • Network, server, and application monitoring • Recognize strategic responsibilities, such as: • Ongoing risk assessment • Planning technologies for future business goals

8. Centralized Model • Responsibility is concentrated in Information Security Officer. All operational and strategic processes report to ISO (may be “dotted line”) • Pros: Tightest control over security, least risk; security is priority; security skills developed • Con: In large organizations, requires large staff • Works best in small organizations… • With “vanilla” technical environment (few systems/vendors/platforms) • With simple organization structure, a single entity

9. De-centralized or Distributed Model • Leave security up to each department • PRO: least expensive • CONS: Greatest risk • Lack of security control, accountability • Dependence on voluntary compliance • Less likely to make security a priority • Less likely to make security skills • Leads to uneven security, and security is only as good as the weakest link • Most common model today. Doesn’t meet HIPPA requirements or good business practice

10. Hybrid Model – Centralized and Distributed • ISO holds responsibility and authority • Core staff set standards and guidelines, provide oversight, etc. • Dotted line staff implement security throughout the organization Most practical for all but the smallest organizations, Sample responsibilities of ISO with core team: • Draft policies and procedure templates • Develop training and awareness programs • Set technical standards, drive security technology purchases • Administrator access to private network and primary system (e.g. EMR systems) • Sample dotted line relationships to ISO: • DBA’s • System and network administrators • Application administrators • Trainers

11. Review and Discussion • What two positions does HIPPA require in covered entities • Describe their roles and responsibilities

12. Section IV Education • In this section, the discussion related to the HIPPA education program will focus on: • The audience • Frequency of training • Content of the training program • Workforce certification • Suggestions for routine education • Suggestions for reminders

13. The Audience • Your audience should include, as applicable: • Employees (don’t forget senior management) • Physicians with privileges • Students (Medical, nursing, pharmacy, social services, etc.) • Volunteers • Consultants/contractors (not just IS/IT!) • Vendors (possibly!) • People with access to protected health information

14. The Audience (cont) • Audience may or may not include business partners, depending on agreement/contract • Be sure business partners, if not trained by you, have their own education program that covers all HIPPA-required points • Audience does not include other HIPPA “covered entities” who should have their own training • This audience is your “workforce” per HIPPA. To restate, anyone working for your organization (even in a volunteer capacity) with access to protected health information is part of your workforce and must receive training

15. Frequency of Training • Both the Security Rule and the Privacy Rule require education and training programs. The Privacy Rule further specifies the frequency • Train the current workforce by the privacy compliance date • Train all newcomers on arrival • Hold periodic security/privacy training thereafter when there are “material changes to privacy policies or procedures” • Sign certification after training • Use periodic “reminders” (e.g., posters, screen saver massages, oral reminders in recurring meetings) on an ongoing basis

16. Content of the Training Program • Security, Confidentiality, Privacy Policies • Summarize your security, confidentiality, privacy, Policies…your leaderships position • Explain why the policies are necessary and important • Personal Accountability and Responsibilities • Stress personal accountability, describe individual responsibilities, include: • Good password management (and what the password management expectations are) • Safe workstation management including virus protection • Monitoring and reporting log in success/failure message discrepancy • Reporting Security incidents • Where full text of policies can be found

17. Violations • Define what constitutes a violation; give examples. Describe the penalties for violation; • Violations may result in “notification to law enforcement officials and regulatory, accreditation, and licensure organizations” • Violations may result in “civil of criminal penalties for misuse or misappropriation of [protected] health information”

18. Policy Copies • Tell where to find complete policies (e.g., intranet web site and one hard-copy in each department) • Specialized Content for Personnel with High Level Privileges • Add special content for audience with high level of privileges (e.g., system administrators). Ensure they understand their increased risk. Be explicit about expectations of behavior, for example, so that they will not abuse their power

19. Workforce Certification • The privacy rule requires that every member of the workforce sign an acknowledgement of the organizations policies, called “certification” • Workforce certification is required after initial training and then at least every 3 years thereafter. (This is a minimum. Your information security program and accreditation program may require training and signing more often) • The certification form must include the date of training and signed acknowledgement that the person “will honor all of the entity’s policies and procedures” as required by HIPPA

20. Suggestion for Routine Education • Develop a core curriculum of primary points. This ensures that all required items are included and ensures consistency of the message • Then customize the program for each type of audience (e.g., senior management, clinicians, support staff) • Use a train-the-trainer approach to develop many individuals who can spread the word. Encourage trainees to customize the content to their audience (whom they know best) • Piggyback on existing vehicles such as: • New employee, volunteer, and student orientation programs • Annual education for accreditation • Physician, nurse (re-)credentialing processes • Use a variety of tools to keep it interesting. For example, mix oral presentations with videos and handouts

21. Suggestions for Reminders • Tips: • Focus on simple goals (e.g., keep your passwords secret). Leave the complex issues for in-depth training • Keep messages short and direct • Use multiple, changing techniques and messages. Variety gets attention • Look for opportunities for internal publicity. For example, play up the security features of a new system; take advantage of National Security Day; describe how good security practices foiled an attempted breach. (Be aware of impression, however, and be sure not to give away information that would make you vulnerable)

22. Techniques • Display brief, varying messages at login • Broadcast short email messages • Submit newsletter articles • Put up posters • Hold a security fair • Provide give-aways with a security message

23. Review and Discussion • Who needs to receive periodic education and awareness training? • Describe the key points to convey in the core education program • What is “workforce certification?”

24. Section V Physical Controls • In this section, we will discuss the following topics: • Controlling access to non-public buildings and areas • Controlling access to equipment and workstations • Influencing behavior

25. Controlling Access to Non-Public Buildings and Areas • Physical controls protect against environmental hazards and intrusion • Have a facility security plan that covers your entire campus and offsite facilities • Know who is walking around, especially in non-public buildings or areas • Consider policy requiring wearing of a badge • Have visitor procedures (e.g., sign-in, badge, escort as appropriate/needed) • Protect access to non-public buildings and areas. Protect access to computer rooms/data centers, to server rooms, to data closets, etc.

26. Controlling Access to Non-Public Buildings and Areas (cont) • Document the procedure. Allow access for “need to know” only. Ensure individual authorization. Keep database of people allowed entry; keep it up to date • If using card keys: Issue to specific individual; deactivate when no longer necessary (job change or termination) • If using traditional keys: Issue to individual; prohibit copying, require turn-in when no longer needed • If using combination locks: Have procedure to change combination periodically and when person with combination no longer has need to know

27. Controlling Access to Equipment and Workstations • Access to Equipment: • Assure access is limited to “need to know” • Ensure procedures to control equipment movement in and out of facility • Access to Workstations: • Ensure policy/guidelines regarding securing workstation (e.g., consider locking to desktop in public areas) • Ensure policy/guidelines regarding what you may and may not run on a workstation • For example, prohibit bootleg unlicensed software • For example, prohibit software or data files from home unless licensed, if appropriate, and virus-scanned

28. Controlling Access to Equipment and Workstations (cont) • Ensure policy/guidelines regarding workstation use • For example, requirement to log off when leaving the workstation • Ensure policy/guidelines regarding protecting screen from viewing by others

29. Influencing Behavior • Physical access controls are often where “the rubber meets the road”. Physical breaches are sometimes easiest and most damaging. Physical breaches can only be prevented if every individual understands and supports the policies and procedures • Must have clear, explicit policies and/or guidelines • Educate the workforce. Explain policies and the rationale • Take disciplinary action when violations (and re-education as needed) • Consider publicizing violations (without specifics) • Perform “midnight audits”. Reward and publicize good, safe work habits.

30. Review and Discussion • How should visitors to a non-public area of your facility be treated so as to reduce risk • Give examples of areas in your facility that should be kept secure • Describe how access to a computer room, for example, could be kept secure • What are key points to teach about workstation use

31. Section VI Technical Controls • In this section we will discuss the following topics: • Security Rule technical requirements • Privacy Rule technical requirements • Identification, authentication, and authorization • Automatic logoff • Data integrity • Auditing • Protecting data in transit • Secure remote access • Secure event auditing • System/network certification • Disaster recovery/business continuity • Virus protection • Minimum necessary access: de-identification of data • Use/disclosure auditing • Complying with patient intent

32. Security Rule Technical Requirements • Required Technical Controls: • Access controls including role-, user-, or context-based access • Audit controls (to monitor system activity, to identify suspect data accesses) • Authorization controls (role- or user-based) • Data authentication including: • Automatic logoff • Unique user identifier • Password or PIN or biometric or token or callback

33. Security Rule Technical Requirements (cont) • If Transmitting Data, also need: • Integrity controls • Message authentication • Access controls and/or encryption plus, if transmitting over open networks: • Alarms • Audit trails • Entity authentication • Event reporting

34. Required at the System and Level: • Certification • Disaster recovery/business continuity mechanisms • Virus protection • Protection of “remote access points” and “external electronic communications”

35. Privacy Rule Technical Requirements • Explicit Requirements: • Security safeguards (as in Security Rule) • Use and disclosure of only the minimum necessary data; option of using de-identified data • Audit uses and disclosures beyond primary (and be able to report) • Implicit Requirements (and based on Organizations policies) • Track patient authorizations and revocations, and check before using or disclosing data for non-primary purposes • Amend and/or correct health records

36. Identification, Authentication, and Authorization (IAA) • Central Concepts for Security and Access Control • “Identification” uniquely identifies you by a unique user ID (associated with your full name and other identifying information) • “Authentication” proves or verifies that you are who you say you are, according to your user ID • “Authorization” describes your access rights or privileges, what you’re authorized to see and do

37. Identification Requirements of HIPPA • A unique user ID is required for every person and process. This is necessary for accountability. (who did this?) • No shared, group user ID’s permitted • Semi-permanent audit trail record (internal to application) includes user ID. So user ID field needs to be designed to be permanent (or else alternate mechanism for audit trail), non-reusable

38. Authentication • There are 3 categories of authentication • Something you know – password, PIN • Something you have – token, smart card • Something you are – biometric • “2-factor authentication” is strongest • e.g., PIN plus token • e.g., fingerprint on smart card • Recommended for remote access, especially over the Internet, and highly privileged access (e.g., to security server)

39. Authentication Requirements of HIPPA • Must have one or more of previous page forms of authentication…including call-back, but… • Call-back is easily spoofed • Call-back doesn’t work for roaming workforce • Communication over “open” networks requires “irrefutable” authentication (generally assumed to be 2-factor authentication) • Comment: Passwords alone are acceptable and cost-effective when well managed and used locally but avoid for remote access

40. Authorization • Authorization requirements of HIPPA • Must use user-based or role-based authorization, that is, [least necessary] privileges are assigned directly to user ID, or to role when user ID is linked to role • Optionally modified by logon location, time of day, day of week,… for further control • Privileges should describe: • What files or data elements you can access • What level: read, update, delete… • What functions you can execute

41. Ability to review user authorization • Access request forms must specify what’s being authorized • Access setup must be able to reflect what privileges have been authorized • Systems must be able to report all users and authorization or privileges each user has (not always easy!)

42. Automatic Logoff Feature • This is another access control mechanism, also known as auto logoff or inactivity timeout. Per HIPPA, this feature “causes electronic session to terminate after a predetermined time of inactivity”, thus preventing someone else from using the logged-on user’s access privileges in case the user forgot to log off. (It should only be viewed as a safety net and does not replace individual responsibilities to log off and training to do so). This helps assure “entity authentication” as required by HIPPA • Auto logoff is a HIPPA requirement. But each organization must determine period of idle time and set own standards • There are various designs with pros and cons. Not all designs are equally secure; beware of designs that tie auto logoff to screen saver. Be sure that logoff is clean and complete

43. Date Integrity • This is referred to as data authentication by HIPPA. It is the assurance that there has been no unauthorized or inappropriate alteration of the data • Suggested mechanisms used to ensure data integrity, per the Security Rule: • Check sums • Double keying • Message authorization code • Digital signature (message hash)

44. Requirements for Data in Transit over Open Networks • All network controls as above plus: • Alarms, i.e., “signal of abnormality” such as auto shutdown • Audit trails • Entity authorization (“ network mechanism to irrefutably identify users, programs, or processes” and allow or deny access) • Event reporting of “operational irregularities in physical elements of network…or response to occurrence of a significant task, e.g., completion of request for information

45. Secure Remote Access • The Security Rule requires the protection of “remote access points” and “external electronic communications” • HIPPA is non-specific and “technology-neutral”. But organizations should have detailed policies, procedures, and technical controls suitable for own business and technical environment • Technologies should • Prevent through strong access controls, hardened configurations, etc.. • Detect through monitoring software

46. Remote Access Considerations • Policies should define who is allowed in and what they are allowed to do. How is the policy implemented through technology. The technical solutions should ensure confidentiality, integrity, and availability • And they should be… • Strong enough to control access sufficiently • Scalable • Flexible for different protocols and platforms • Manageable

47. Dial-up Considerations • Centralize and control user to identification, authentication, authorization (IAA) • Maintain and monitor audit logs • Run a war-dialer periodically to find rogue modems • Scan for remote control software

48. Internet Considerations • Centralize and control IAA. Maintain and monitor logs. • Use tools such as: • Firewall(s) • Virtual private networks (VPNs) • Encryption • Host – and network – based security scanners • Intrusion detection systems (IDS) [refer to Section VIII using the Internet for more detail]

49. Security Event Auditing • This is “traditional” auditing on systems, databases, and networks. Unlike use/disclosure auditing, the tools are usually available “out of the box”. But they still require configuration and tuning • Audit security events such as: • Unsuccessful logon attempts • Security parameters change • Security-related events • Other suspicious or unusual activity • Be aware of potential resource issue. Who reviews logs. Is log review for security a priority. Does the reviewer understand the security issues. What filters are in use.

50. System/Network Certification • Certification is driven by documented policies and specific standards and procedures. For example, an organization using NT should document the NT setup in secure mode. If an NT server is running an Oracle database and an application, each components setup should be documented • To achieve and maintain certification, all appropriate security features and functions should be implemented according to standards and documentation • Components (OS, database, application) should be “hardened” by turning off or removing unnecessary services, functions, and features. For example, delete FTP from servers which don’t absolutely require it. • Security patches and upgrades should be tested and applied in a controlled, documented process. Patches should be applied promptly