Background
Each month, any enrolled patient (patient has agreed to home health care services) is to be billed to the client. As long as the patient remains enrolled, that patient will be included in the monthly invoice to the client.
​
In the Data Visualization case study, I explained how stakeholders had a difference of opinion on which system was the source of truth. In this case, which system accurately represented if a patient was enrolled. Everybody had to be on the same page in order to determine which patients should be billed to the client.
​
While working on the data visualization project, I came across data that didn't make much sense. Using a series of SQL queries, I determined the enrollment count of patients did not match our invoices. In some cases by a large count.
​
Thinking Through the Problem
This project was not something that was identified by any stakeholder. I found the issue in the data and immediately alerted those who were involved in the billing process.
​
In order to fix what I believed was a major problem, I needed to understand how invoices to clients were generated (the code itself). My initial thought was there was some bugs in the code that were leaving patients off invoices. At this time, I didn't quite know all the rules so I began my research.
Requirements Process
I began the requirements process by checking the SOW to see if there is a clear indication of why or why not an enrolled patient should or should not be billed to the client. Unfortunately, there was nothing in the SOW to provide direction. After speaking with a couple of stakeholders, the requirements were very straightforward:
​
-
All enrolled patients must be included on the client invoice
-
Any unenrolled patients must not be included on the client invoice
​
I reached out to the developer who manually ran client invoices. I needed a step-by-step process on the what the code was doing, along with any stored procedures that gathered the data to create the invoice. It was a very difficult undertaking because the code itself was written years ago and even the developer had a difficult time explaining exactly what the code was doing.
​
I asked the developer to simply take the 2 requirements stated above and compare that to what the code appears to be doing. I had the developer run an invoice from the previous month to use as comparison to the data I was seeing in the database.
​
​
​
The Solution
The invoice compare was off by about $20,000 for the previous month (what was billed to the client vs the enrollee count). I then brought in another developer to take a look at the code to see why we're not capturing all enrollees. The following issues were found in the code:
​
-
If a patient showed as enrolled in one system but not enrolled in another system, the patient was not being included on the invoice. The code was not assuming the EMR was the source of truth, which was a huge error
-
There was a snippet of code that was not accounting for any patient enrolled in the last 2 days of a month. So, any initial visit for a patient (enrolled patient) was being left off the invoice for that month
​
The solution was to update the code to use the EMR as the source of truth for enrolled patients and remove the snippet of code that didn't include a patient if enrolled the last couple days of the month.
The Result
Once the code was updated, the invoice was re-run and we captured an extra $22,000+ for that month. All invoices going forward were correct and would bring in approximately an extra $250,000 per year.