Three Simple Tips to Conquer a Policy Analysis

I used this policy analysis method for healthcare policies.

News Item!

New regulation passes; organizations must have updated HIPAA (Health Insurance Portability and Accountability Act) policies that comply with the regulation by January 1 of next year.

You look at the item and think, “I’ve got 12 months. Nothing to do right now. I’ll calendar six months from now to look at this. How much could this new regulation impact the policies in my company?”

A lot! Think major legal ramifications. Or possibly privacy and security risks to the company. Depending on the regulation and the scope, there could be a substantial impact.

When do you start? In this scenario, it’s probably best to start within a month of reading the news item.

How? With a policy analysis.

The Policy Analysis Setting

My healthcare client brought me in as the consultant to conduct a policy analysis. Although I start projects with a needs analysis, the client had already performed that task internally. The client identified the key players for the project, had determined that the policies were out-of-date, and pinpointed the projected location of the policies (a shared library). Since the client operated in the United States, regulations included HIPAA, the HITECH Act (Health Information Technology for Economic and Clinical Health), and state privacy laws.

Approval, training, and publication responsibilities rested with the client.

Step 1: Inventory the Policies

I made sure I had received all the policies for the project. To do that, I repeated my question a few times to the project manager/client contact. The repetition yielded fruit: Although most of the policies were in the shared library, there were a few “homegrown” policies related to the project in department shared drives.

Along with the client, we identified the regulations that impacted these policies. In this scenario, we looked at HIPAA, the HITECH Act, and the state privacy requirements for this client. Example: California has some requirements that differ from the federal regulations; state law takes precedence.

Step 2: Map the Existing Policies to the Regulations

Once we identified the regulations, I created an Excel spreadsheet with columns for the regulations and for the client’s policy. The purposes for the spreadsheet: 1) Create an inventory and 2) Provide the client with a visual of the state of their policies relative to the regulations.

The spreadsheet included this data: HIPAA Standard and/or Implementation Specification; client’s policy title; client’s policy number; effective date; date approved; last date updated, and the approver’s name/title. To map the client’s information, I read through each policy. In some cases, policy text that the client had mapped to one Standard mapped to a different Standard, and I recorded those differences.

Part of the analysis included highlighting the missing policies. That way we could easily identify the deficiencies.

Step 3: Create a Complete Set of Policies

Once I had the map, I developed a full set of policies. Where the client had no policies, I provided a template version that matched the regulation, including references that matched their organizational structure/nomenclature (example: Medical Records instead of Health Information Management). For policies that needed updating, I edited the client’s existing policies, including the latest regulatory language.

I sent the full set of policies to the client’s project manager for review. After their review, the project manager sent me changes related to specific processes/department names/approver information. I revised the policies and sent the client the final version.

What I Learned About Policy Analysis

1. Have an approved project plan, using the organization’s standard process. Minimally include these stages: Analysis, Develop, Review, Approve, Publish, Implement, and Evaluate.
2. Identify the federal and state regulations. While the project focused on HIPAA, some of the payment policies might have been impacted by PCI DSS (Payment Card Industry Data Security Standard). I pointed that fact out to the client, explaining that a consultant certified in PCI DSS process review those policies for compliance.
3. Mapping is tedious, yet produces a clear picture of the status of the policies.
4. Compare the last date documentation was reviewed with the latest version of the regulations.
5. Help the client streamline their approval process by identifying the individuals best qualified to review and approve the policies.
6. Include this information either on the individual policies or in a summary policy: Approver, Date Approved, Date Reviewed, Review Cycle/Next Review Date (annual, biennial or an exact month and year).
7. I could—and did—use this method to map procedures, SOPs, and policies related to other regulations.