Notice that the title of this article does not say 10 easy steps. Also notice that the title states "Launch" (not "Complete") your initiative. You will certainly have made significant progress at the end of these 10 Steps but in no way do we mean to imply that you will be done. Clearly you won't be. However, if you are a long time reader you know that we assert, every chance we get, that you will never be done with your HIPAA initiative because by definition, it is a ongoing process. Also, for the sake of transparency, we use our Agile Methodology Project Plans to describe the 10 steps. That said, these 10 steps are written generally so as to apply no matter what purchased or "home grown" tool sets you may be using.
1. Designate a HIPAA Privacy Officer and Security Officer (Track = "Foundation")
1.1. Present candidates with the necessary credentials or candidates willing to obtain the necessary credentials to the executive team.
1.2. Name a HIPAA Privacy Officer.
1.3. Name a HIPAA Security Officer.
1.4. Distribute designations to your entire WorkForce.
2. Disseminate Model Policies (Track = "Foundation")
2.1. Present the model policies (e.g. Security Rule Policy, Privacy Rule Policy, Breach Notification Policy and others as required for your organization).
2.2. Make changes to the policies based on executive team feedback.
2.3. Allow the executive team to review the FINAL policies.
2.4. Distribute the policies to the entire organization and ensure that each individual indicates that he/she has read and understood the policy by signing his/her name in the signature block.
2.5. Scan signed policies and store them in the Organization's Compliance Repository
2.6. Distribute policies to new Workforce Members as required.
2.7. Once a year review the policies with the executive team to ensure continued applicability.
3. Training & Awareness (Track = "Foundation")
3.1. Introduce the training program to executive team and get buyin
3.2. Introduce the training program to the rest of the staff
3.3. Have Key stakeholders (i.e. Privacy Officer, Security Officer, one Administrative Staff, and one Clinical Staff) ("Core Training Team") review the exam(s) and participate in the training program; including taking the exams.
3.4. Depending on the size of the organization cross functional team(s) of Workforce Members participate in joint training; take the exam, and signoff on having taken and passed the exam.
3.4.1. Schedule which Workforce member will take which classes and ensure availability for the majority of the class (Workforce members unavailable will have to take the class at some other time or on their own).
3.4.2. Each class discusses the training and provides feedback to the Core Training Team.
3.4.3. Any individual that does not make 70% or better on an exam must go through the training again and retake the exam.
3.4.4. The Core Training Team may want to produce several variations of each test to make test re-takes meaningful.
3.5. Executive team members participate in "regular" classes along with other Workforce Members
3.6. Get feedback from the executive on the training program and make modifications as required.
4. Compliance Repository (Track = "Foundation")
4.1. Review with the executive team where the Compliance Repository should be stored and maintained. An in-house Intranet/Wiki (secured obviously on a need to know basis) is a perfect place for it. A "network share" would work just as well. If you are tempted to store on it on the Cloud then it better be on your own private cloud or you will need a Business Associate Agreement with your cloud provider (e.g. Microsoft, Amazon, etc.).
4.2. Your electronic Compliance Repository is the equivalent of your "old 3-ring binder" only much more effective. Here you can clearly determine what the latest version of a policy is (i.e. a single version of the "truth"). However, your Compliance Repository also stores your written processes and also process results (e.g. your training tracking spreadsheet, your security incidents, your patients and Workforce Member's signed policies). In other words your Compliance Repository is where you store your Visible, Demonstrable, Evidence of compliance (i.e. proof that your organization is complying with your policies and processes).
4.3. Create the Root folder/page ("Folder") and call it Compliance Repository (or something to that effect).
4.3.1. Under the Root create a directory for "Policies and Procedures"-we suggest that you further breakdown this folder in to subject matter domains such as:
184.108.40.206. Privacy Rule
220.127.116.11. Security Rule
18.104.22.168. Breach Notification Rule
22.214.171.124. Disaster Recovery
126.96.36.199. Risk Assessments
188.8.131.52. Risk Management
184.108.40.206. Patient requests under the Patients' Bill of Rights ("PBR")-§§164.520 through §§164.528
220.127.116.11.1. Notice of Privacy Practices §164.520
18.104.22.168.2. Rights to Request Restrictions §164.522
22.214.171.124.3. Rights to Access PHI §164.524
126.96.36.199.4. Rights to Amend PHI §164.526
188.8.131.52.5. Rights for an Accounting of Disclosures for PHI §164.528
4.3.2. Under the Root create a Folder for Business Associates-further break down this Folder into one Sub-Folder for each Business Associates.
4.3.3. Under the Root create a Folder for Sub-Contractors-further break down this Folder into one Sub-Folder per Sub-Contractor.
4.3.4. Under the Root create a Folder for Workforce Members-further break down this Folder into one Sub-Folder per Member.
4.3.5. Under the Root create a Folder for Training-further break down this Folder into types of Training.
4.3.6. Under the Root create a Folder for Security Incidents-further breakdown this Folder into one Sub-Folder per incident with a date attached to the Sub-Folder name.
4.3.7. Create additional Folder and Sub-Folders under the Root as required.
4.3.8. Ensure that the Compliance Repository gets backed up on a daily basis and is otherwise protected from a Disaster Recovery perspective like you would protect PHI.
5. Risk Assessment (Track = "Foundation")
5.1. Present the rationale for doing the current Risk Assessment ("RA") to the executive team (e.g. baseline, Meaningful Use, post a security incident, after a year, etc.).
5.1.1. Get approval for budget.
5.1.2. Get approval for resources.
5.1.3. Identify third parties vendors needed (e.g. IT security consultants)
5.2. Conduct the RA.
5.2.1. Gather and capture inventory data pertaining to Security Objects
5.2.2. Identify Threats and Vulnerabilities
5.2.3. .Assess current Security Controls.
5.2.4. Determine the likelihood of a Threat.
5.2.5. Determine the potential Impact of a Threat.
5.2.6. Determine the level of Risk associated with Threat/Vulnerability pairs.
5.2.7. Identify new/modified Security Controls and finalize documentation.
5.3. Present results of RA to executive team and revisit the budget and resources required based on the number of Risks to be "attacked."
6. Business Associates (Track = "Foundation")
6.1. Ensure the appropriate Business Associate Agreements ("BAAs") are in place with all Business Associates and executed by both parties.
6.2. Review of BAAs on an annual basis at a minimum to ensure continued compliance by both parties.
6.3. Get "Satisfactory Assurances" from your Business Associate that they are comply with the HIPAA Rules in a manner required by the HITECH
Act and corresponding regulations, and by the BAA.
6.3.1. Request to review Visible, Demonstrable, Evidence of Compliance
184.108.40.206. Tracking Mechanisms (i.e. pursuant to process results)
6.3.2. Additional Due Diligence for Business Associates that "store or maintain" your PHI
220.127.116.11. Get "Satisfactory Assurances" as to the Business Associate's encryption strategy
18.104.22.168. Review the implementation of the Security Rule's Administrative, Technical, and Physical Safeguards
22.214.171.124.1. A more detailed review of the Business Associate's last Risk Assessment is required
126.96.36.199.2. A more detailed review of the Business Associate's Risk Management Program is also required.
188.8.131.52.3. Where necessary and practical may onsite visits to ensure that the Business Associate is complying with applicable law (both
state and federal)
184.108.40.206.4. Where onsite visits are not practical, make virtual visits any number of cost effective tools now available in the marketplace that supports this kind of activity.
6.4. Business Associate Incident Reporting
6.4.1. Ensure that Business Associates clearly understand the reporting requirements under the Breach Notification Rule.
6.4.2. Ensure that Business Associates clearly understand what triggers breach notification.
6.4.3. Have a Breach Notification Communication plan thirty days after executive/renewal of the BAA in all cases where the Business Associate.
"stores and maintains" ePHI on your behalf.
6.5. International Business Associate Issues
6.5.1. Get "Satisfactory Assurances" that your International Business Associates are in compliance with privacy & data protection laws of
their country of origin
6.5.2. Ensure that International Business Associates comply with the HIPAA Rules using the BAA as the controlling device.
6.5.3. Ensure that International Business Associates agree to the jurisdiction of U.S. Courts in a forum and venue of your choosing.
7. Incident Tracking & Reporting (Track = "Foundation")
7.1. Present the rationale for a Security Incident Tracking System ("SITS") to the executive team.
7.2. Get approval for budget and resources to develop and deploy the SITS.
7.3. Distribute the Breach Notification Policy for signature by all Workforce Members. Ensure that everyone has indicated that they have read and understood it.
7.3.1. Provide specifics about who security incidents should be reported to
7.3.2. Provide specific about how security incidents should be reported
7.3.3. Indicate that there will be Sanctions against Workforce Members who fail to report security incidents
7.4. File signed Breach Notification Policies in the Compliance Repository in the Workforce Member's Sub-Folder.
7.5. Follow-up with Breach Notification Training if you have not already accomplished this objective in another Sprint.
7.6. Ensure that everyone takes and passes the Breach Notification Training exam.
8. Patient's Bill of Rights (Track = "Essential")
8.1. Notice of Privacy Practices ("NOPP")-review/revise processes for distributing, updating and revising your NOPP as required
8.1.1. Walk In-in person visits.
8.1.2. Electronic-visits to your "Portal" on the Internet
8.1.3. Updates & Reviews-vetting for amendments and revisions
8.2. Access to PHI
8.3. Amendment to PHI
8.4. Accounting for Disclosures
9. Patients' Bill of Rights: Access to PHI (Track="Essential")
9.1. Ensure that your Organization understands the changes to the right to access of PHI introduced by the HITECH Act Section 13405(e)
(i.e. with respect to the use of an EHR), and the changes introduced by the Omnibus Rule
(i.e. with respect to any electronic PHI including, but not limited to, documents in the following format: MS Word, Excel, PDF, etc.).
9.2. Ensure that you adequately train Workforce members that have responsibility for fulfilling PHI access requests:
9.2.1. Job titles must reflect this responsibility
9.2.2. Designated Workforce members must clearly understand the "due process" requirements of providing access (e.g. 30 day requirement unless an extension is asked for and obtained in writing).
9.2.3. The Designated Workforce member processing the request is responsible for delivering the PHI to the patient in the form requested
9.2.4. If the access request is denied, the designated Workforce member must provide the patient the reason for denial in writing
9.3. Ensure each patient access request is signed, dated, and logged in the Patient Request Log.
9.4. Ensure that an Access Request Form is compiled for each access request
9.5. Store the Patient Request Log and the Access Request Form in the Compliance Repository
10. Patients' Bill of Rights: PHI Amendments (Track="Essential")
10.1. Ensure that our Organization allows amendments to PHI except in the following cases:
1) the PHI was not created by us;
2) the PHI is excluded from access and inspection under applicable law
3) the PHI is accurate and complete
10.2. Ensure that you adequately train Workforce members that have responsibility for fulfilling PHI amendment requests:
10.2.1. Job titles must reflect this responsibility
10.2.2. Designated Workforce members must clearly understand the "due process" requirements of providing amendments (e.g. 60 day requirement unless an extension is asked for and obtained in writing).
10.2.3. If the amendment request is granted, the designated Workforce member processing the request is responsible for working with the patient to identify other healthcare stakeholders that may need to be notified of the amendment
10.2.4. If the amendment request is denied, the designated Workforce member must provide the patient the reason for denial in writing
10.3. Ensure each patient amendment request is signed, dated, and logged in the Patient Request Log.
10.4. Ensure that an Amendment Request Form is compiled for each amendment request
10.5. Store the Patient Request Log and the Amendment Request Form in the Compliance Repository
This is not an exhaustive list of our Agile Methodology's "Tracks" and "Chunks" but it is a representative sample that should help you make significant progress on your HIPAA compliance initiative in short order.