How and Why I Built a Customized Healthcare Practice Management Portal

About me

I'm an engineer of many trades and a business owner who is passionate about streamlining and automating processes and workflows.

The problem I wanted to solve

Insurance billing for healthcare offices is nothing short of a nightmare. It is a multi-step process from sending the claims to receiving them, and problems can, and do, occur at each step.

We needed a way to automate as much as possible, so our staff could spend more time with patients and we could accommodate accelerated growth without having to add new staff.

We also needed a central storage location that could aggregate data so that we could run custom reports and keep patient accounting in one location.

What is a "customized healthcare practice management portal?"

I built a multi-faceted database with different user stories that streamlines workflows. It allows for the ability to create and manage patient demographics and visits, insurances, payments, and healthcare providers of differing types.

It automates the insurance billing and receiving process as well as patient invoicing. A separate tool syncs our point of sale with the database to automate payment entry and application.

A back-end sync tool connects the database to our accounting software to track payments. The database allows multiple reporting tools for provider and owner insights.

Tech stack

We used Django and PostgreSQL for the back-end and AngularJS for the front-end. We are hosting on Heroku. I chose these technologies because I needed open source solutions that were well documented.

Because it is such a big project and I was working on my own, I needed well-tested, mature open source technologies. This stack has been a joy to work with and the community has been very supportive.

The process of building the portal

Even though the other stakeholders were unaware of the process, we employed an Agile development process — I've made many releases and had them reviewed as we went on. I started with simple CRUD operations on the various database classes we needed and built from there.

Challenges I faced

The most difficult aspect is the changing needs of the project over time. The Agile process helps greatly with this, but stakeholders often don't understand feature creep and the associated increase in costs and time that this entails. The other difficulty is that the stakeholders were largely non-technical, so the impacts of decisions were sometimes unclear and required more time to explain.

Key learnings

It was a huge project that is still underway. I think I would have spent more time educating stakeholders upfront so that they understood the process in more detail and knew more about what to expect.

Tips and advice

It's always bigger than you think it is when you first envision it. Being disciplined in the design phase and avoiding feature creep will really help you be successful. Understand what the MVP (minimum viable product) is and focus there.

Final thoughts and next steps

This project is a huge foundation for this business and will allow the business to grow and keep costs low for many years. We will certainly be adding data visualizations and increased reporting to the database in the near future.