Case Study - Data Visualization Solution

Problem Statements:

Patient medical data is spread across 3 disparate systems where the data does not match where it must in many cases
No mechanism to visualize a patients' journey through the data ecosystem
There is no single-source to determine if a patient is enrolled in home health care

Background

Insurance companies (the clients) will send lists of their members who they believe would benefit from home health care. These members will have medical issues that could cause them to need to go to the ER or need a hospital stay. Studies have shown that being visited at home by a medical professional on a regularly scheduled basis cuts down these hospital visits. The less hospital visits, the less the insurance company needs to pay in claims.

When the clients send a list of members that need to be called in an attempt to enroll them in home health care services, the data is housed in the data warehouse. When action is taken on one of these patients, the patients' data flows through two other systems; an EMR and Salesforce. As the scheduling team reaches out to each patient, both systems are updated. The problem is, the data is not being migrated in a timely basis and not always accurate. So, we're left with three systems that may show data on a patient that is different in all three. This causes a huge problem with enrollment, reporting, and accuracy in a patients' status at any given time.

Thinking Through the Problem

These particular data issues were all part of systems I had no prior working knowledge of. I had to first learn about the home health care side of the house. I had to get up to speed on how the data warehouse is designed and where patient data lives inside of it. I also had to learn how our scheduling team used Salesforce and how our home health care professionals used the EMR. All three systems work in conjunction so I needed to understand all the data flows amongst the three.

I knew a solution to solve for the problem statements could not wait until I knew everything. So, my thought process was to understand just enough about the process to be able to talk intelligently about requirements with the many stakeholders.

Requirements Process

The stakeholders for this project were the following:

The CEO
The CFO
Vice President of Operations
Vice President of Engineering
Chief Medical Officer
Vice President of Medical Operations
And Others

The requirements gathering process did not require speaking with each stakeholder as each was in agreement what needed to be done. The stakeholders who were involved in the requirements stage were clear as to what they would like for us to accomplish. What the final solution would look/act like was something my team had to figure out. After many discussions, these were the main requirements:

The system must be able to report on a patients' journey through the data ecosystem (from the time a patient shows up in the data for the first time all the way through home visits if enrolled)
The system must be able to have the same piece of data for a patient match across each disparate system
The system must be able to know if a patient is enrolled or not enrolled
The system must be able to know if a patient who is not yet enrolled has an initial home visit scheduled
The system must be able to accurately invoice each client for enrolled patients
The system must be able to migrate data from once system to another quickly and accurately
The system must be able to identify which program a patient is currently included in

The Solution

To solution for these requirements, the project turned into a data-driven solution that sits behind a new front-end. I spent many hours and weeks analyzing the current state of the data in an attempt to pinpoint the holes and gaps. What I found was depending on the stakeholder (scheduling team, medical team, project team), each had a different idea of the source of truth of the data.

Knowing that once an initial visit with a patient was completed and documented as such, that patient is considered enrolled. That data is housed and updated in the EMR. So, that was now the source of truth for which patients were enrolled.

If a patient is not enrolled, Salesforce will show if that patient has an upcoming initial visit or has at least been contacted. So, Salesforce will be the source of truth for the status of a non-enrolled patient.

The tricky part was to fix the data migration issues. Data entered/updated in Salesforce and the EMR would need to match. I found out we were not using APIs to coordinate the data. A third-party migration tool was being used that had many issues which led to many of these problems. Using APIs allowed this data to flow from one system to another quickly and accurately.

While working through fixing the data issues, I began designing a new front-end application as a visualization tool. Since I now knew the source of truth for all the relevant pieces of data for a patient I was able to design a solution that would capture each 'interesting' event for a patient:

What campaign patient belonged to
Previous campaigns patient belonged to
If patient has been contacted in an attempt to enroll the patient
When patient was enrolled (initial visit completed)
Each home visit for an enrolled patient
Each time patient was included on an invoice to the client
If patient was contacted and asked us to not call again
If patient was deceased

One major piece that came out of this project was finding out we were under-billing clients for years. The result of my findings for that is explained in more detail in the Client Billing Issues project case study.

The Result

The result of the initial phase of this project was the business was finally able to see the full patients' journey through the data ecosystem; and the data was accurate. Further phases of this project were on the project plan that would enhance what was already started.

Back to Projects