HIPAA Healthcare Security Rules and Domino

• Administrative – management activities related to security, such as risk analysis, identifying a security officer and employee termination procedures.
• Physical – securing rooms and media, including items such as door locks and re-use of backup media.
• Technical – areas that are thought of as core "computer security" such as user IDs, encryption and automatic logoff.
• Organizational – contracts with business partners, to make sure the contracts address security concerns.
• Policies, Procedures and Documentation – management of the documentation related to the security rules.

• Under the Administrative section, there is an item that calls for "procedures for terminating access to electronic protected health information when the employment of a workforce member ends." With Domino, this is a simple matter of implementing a Terminations group in the NAB, and then adding ex-employees to this group.
• Also in the Administrative section, there is a line item that requires "procedures for monitoring log-in attempts and reporting discrepancies." Easy to do in Domino, since this information is automatically saved in the server log file.
• The Technical section asks for "unique user identification." Of course, this feature has existed in Domino and Notes for many years in the form of Notes ID files.
• An interesting requirement is to "establish procedures for obtaining necessary electronic protected health information during an emergency." In other words, healthcare staff should be able to "break the glass" and get information they need to save someone's life, even if they don't normally have the proper access. The system should document any actual emergency access for later review. This requirement can be met in Domino with special a user ID that has unlimited access, and a documented procedure for getting this ID.
• The Technical rules call for "procedures that terminate an electronic session after a predetermined time of inactivity." Again, this feature is built into the Notes client and is simple to implement.
• As a final example, HIPAA asks for "technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network." Domino meets this rule with its support for SSL over the Internet, and Notes includes port encryption for native Notes traffic on a LAN.

Below is a link to the HIPAA security audit tool I created as a Notes database. Each detailed item of the security rules is a separate document in the database. Within each document are fields for: a summary of the item, full details of the item rules, the audit status of that item (not started, passed, failed), a flag to indicate if the item is required or addressable and detailed results information.

http://www.chc-3.com/downloads/hipaa_security_audit.zip

This is the first public release of this tool, so it is not perfect. Feel free to improve the database and, if you want, send it back to me. I will add the best changes to the public copy.


______________________________

Tripp's notes studying for certification to be able to work at various companies. No warranty is applied her to the completion or complete accuracy of these study notes.

HIPAA Overview:
Like all regulatory compliance, it's about "Risk Management" and is institutionally enforced because of perceived vs actual private-sector mismanagement.
- RM: Process of identifying, managing, and preventing physical and logical risks that pose threats to the organizations or industries specifically with important individuals, customer/patient information "asset" embarrassments, and loss of business credibility because of a breech. Used by an organization to measure, integrate, and consider cost effective risk mitigation, in this case of PHI types of information.
- The HIPAA guidelines were published and enforced via the US Dept. of HSS.


- Breaches:
-- "Breach Notification Rule". Requires organizations/business to provide public notification in the cases of a breach of unsecured/under-secured PHI data. Notification must take place w/in 60 days following breach discovery. PHI properly secured via these compulsory guidelines exempts companies from the embarrassment of notification.
-- "Impermissible" use / access / leak or disclosure of PHI that compromises the privacy and security of the PHI data that can cause privacy, financial, or reputational embarrassment / harm to a patient / individual.
-- Note: There are exceptions documented on the HSS official web site.


Password Mgmt:
- Individuals working for a company w/potential access or access to PHI data must comply to standards for creating, updating and safeguarding passwords.
- Rules include:
-- Individual (person) IDs used by only one person. (No generic multi-user accounts allowed.)
-- Passwords must not be given to anyone.
-- Passwords must meet minimum "quality" and "complexity" guidelines and not be "trivial" or predictable.
-- Workstations must password lock w/in 30 minutes of inactivity.
- This is covered in HHS docs: ITCS300, ITCS104, ISec, and GSD331.


General IT and End User Responsibilities:
- Workstation must be "secured at all times".
- Employ whole disk encryption.
- Use workstations approved / ITCS300 certified/reviewed compliant for "approved job roles and responsibilities".
- Have appropriate anti-virus and anti-malware software installed, running, and actively scanning (both real-time and scheduled).
- Have CIO-required software patches, and OS and vendor software security patches applied.
- Follow guidelines for secure erasing and disposal of drives of PCs and equipment, including "smart" copiers.
- Never leave media or hardware that contains on it's disks PHI information.
- Ensure that only the minimum PHI information is available and presented to users to complete their job role -- just enough to get their job done, nothing in addition.
- All log-in attempts, documents accessed, PHI attributes accessed, displayed, and updated are logged by the who, where, and when. Procedures exist for any violations or breeches in conduct or data.
- "Mitigate", meaning get any PHI data deemed exposed, not secure enough, into a secure environment that is isolated from the "normal" business data environment. This often includes separate VLANs, network segments isolated with firewalls, separate domain logins, etc. as deemed necessary by the consultant lawyers and auditing companies who are interpreting the guidelines into individual requirements.
- Participate in regular, usually at least quarterly, audits and (re)certifications of systems, databases, applications, network, and workstations by both administrators, and end-users; and provide continual education for compliance. Training is generally required yearly at minimum for "recertification".
- Retain record "artifacts" of HIPAA "execution" of the regulatory compliance actions that are made for 6 years. Note: Legal may also indicate that holding records for longer than the minimum 6 years can be "exposing" and may say EXACTLY 6 years. Docs may not be altered, copied, or destroyed except the 6 year mark. Procedures and policies on how to hold/archive/backup/store are created to protect for "exposure".


Developer:
- Ensure that only the minimum PHI information is available, presented, and retained after use for users to complete their job role -- just enough to get their job done, nothing in addition.
- Ensure that PHI information cannot be copy-and-pasted, printed, or otherwise exported unless that duty is done within planned and designed guidelines of the item above, and that any such exports from an application/database, also be just as secured (if not more), than the main repository.
- All log-in attempts, documents accessed, PHI attributes accessed, displayed, and updated are logged by the who, where, and when.
- Know what types of data are PHI, PII, and PCI types of data and ensure application design and database storage is compliant.


HIPAA PHI Data Types:
- Data regarding the planning, provision, and payments (or lack thereof) for/of health care.
- Health history of a patient.
- Mental or physical health of a patient.
- Overlaps PII (personal) data including name, personal address, personal phone number(s), birth date, and SSN.


Privacy Rules - Audit the Business Processes:
- Identity where PHI data lives, how it is entered, it's life cycle and use, and it's storage and re-use.
- Assign a "Privacy Official", usually w/in Legal, who takes the documented PHI workflows, develops policies, and guidelines around the workflows. Workflows include how collected/entered, how managed, and how used, and how transmitted (saved, exported, printed, etc).
- The training is then done by the PO or other knowledgeable trainers for whoever touches PHI data during any of its workflow areas. Retraining ("recertification") is generally required and performed yearly.
- Applications and processes are updated to limit PHI exposure for abuse, so that only those who have need are exposed, and only exposed at the "minimum access level required for the role". In plain English, just enough access to the job, and nothing extra.


Safeguards:
Safeguards are classified as:
- Required (R) - specified explicitly and must be followed per the rules/HIPAA guidelines for compliance.
- Addressable (A) - customized PHI safeguarding that is appropriate to the application and workflow as unique and implemented in a particular business workflow.

- Administrative oversight
-- Mgmt - Risk Analysis and Management (R), "Sanction" policy (R), System Activities, PHI Review (R), and Assigned Security Roles/Responsibilities (R)
-- Section 164.308(a)(1)
-- Workforce Security Assignements (R)
-- Section 164.308(a)(2)
-- Workforce/Users - "Workforce Security", authorizations/approvals for role access (A), "Workforce Clearance" approval and access procedures (A), and removal/termination procedures (A).
-- Section 164.308(a)(3)
-- Information Access Management: "Clearinghouse Functions" (A), Isolating PHI information from general office information (other applications and processes), access authorizations and establishments (A), access modifications/updates and removals (A).
-- Section 164.308(a)(4)
-- Security Awareness and Training: Awareness reminders/notifications (A), protection for malware (A), login auditing (who, what, when login logging (A)), and Password Management (process and guidelines (A))
-- Section 164.308(a)(5)
-- Security Incident Procedures: For Process, Process Enforcement, Response Discipline/ Mitigation, and Response and Reporting of all (R).
-- Section 164.308(a)(6)
-- Contingency Plans: Data Storage/Backup (R), Disaster Recovery Plan (R), Emergency "Mode Operation" Plan (R), Testing and Revisions of the Plans (R).
-- Section 164.308(a)(7)
-- Evaluations / Audits (R)
-- Section 164.308(a)(8)
-- Business Associates Written Contracts and Arrangements (R)
-- Section 164.308(b)(1)

- Physical safeguards of the data and access (who, what, when)
-- Facility Access Controls: Facility Physical Access restrictions and Security Plan (A), "Contingency Operations" (A), validation of Access Control Plan (A), and Maintenance Records and Access Control (A).
-- Section 164.310(a)
-- Workstation Usage (R)
-- Section 164.310(b)
-- Workstation Security (R)
-- Section 164.310(c)
-- Device and Media Access Controls: Backup and Storage(A), Re-use of back-up media (R), Disposal (R), and Workforce Accountability (A).

- Technical safeguards (IT)
-- Access Controls: Unique user IDs (No generic shared accounts (A)), Emergency Access Procedure (A), Encryption and Decryption (A), Automatic Logoff (A)
-- Section 164.312(a)(1)
-- Audit Controls (R)
-- Section 164.312(b)
-- PHI System/Data integrity (A): The mechanism to authenticate and keep PHI integrity.
-- Section 164.312(c)
-- Person Authentication (R)
-- Section 164.312(d)
-- "Transmission Security" - Basically SSL and minimum requirements for "Integrity Controls" (A) and Encryption (A).
-- Section 164.312(e)(1)









______________________________


previous page