The receipts.

The application had been around for years and documentation was scarce. Before I could replace it, I had to understand it.

I worked directly with its primary user to learn how she actually used the system, what information mattered, what could change, and what absolutely could not.

Some of the business rules weren't documented anywhere. At one point, answering questions about how data reached the application meant tracking down emails that were more than ten years old.

Software archaeology is apparently part of the job.

I designed and developed a modern replacement using a Blazor user interface, a Web API between the application and data layers, Entity Framework, SQL Server, and Microsoft Entra ID authentication.

Before development, I used Balsamiq to work through screens and workflows with the user. The goal wasn’t to build a prettier version of the old application (Although I was totally gonna build something that felt fresh). It was to build something around the way Revenue Management actually worked.

For example, When a user entered a patient account number, the application could retrieve existing patient and insurance information from another hospital system rather than requiring Accounting to enter information the organization already had.

Typing the same data twice is not a feature.

We intentionally kept the existing database, even though parts of the schema were less than lovely. Some tables didn’t even have primary keys.

A new database would have been cleaner, but the existing one could also have been supporting SSRS reports and other dependencies that weren't fully documented. Replacing it without knowing everything that depended on it would have introduced unnecessary risk.

Sometimes good modernization means knowing what not to replace.

By the end of the six-month engagement, the replacement application was substantially complete. The remaining work depended on an organization-level solution for securely moving data between servers, which was ultimately assigned a lower priority before my contract ended.

Development was managed through user stories, Git, pull requests, code reviews, and weekly sprint meetings with the project manager, technical leads, and system analyst.

I also documented the new system as I built it, so the next developer hopefully won’t have to search decade-old emails to figure out what I was thinking.

Over roughly two years, I worked as one of three peer developers designing and building a replacement LIMS from the ground up. I was responsible for a substantial portion of the application.

The system tracked patients, physicians, requisitions, specimens, ordered tests, assay results, billing, shipping, and the questions or problems that can crop up between “the specimen arrived” and “the job is done.”

When a specimen arrived, its requisition was scanned and the sample entered the laboratory workflow. Staff recorded patient and physician information, ordered tests, shipment problems, and other issues. As testing progressed, assay results were imported into the system and the appropriate departments completed their work and signed off.

The three developers worked directly with laboratory staff and Administration. We weren’t designing software in a vacuum and hoping everyone liked it when we were finished.

I kept listening after launch, too.

One result was a more robust search feature for finding specimens and physicians. A later performance evaluation specifically noted that the new search saved users time and significantly increased user buy-in.

Turns out people are much happier with software when it helps them find the thing they’re looking for.

The application handled protected health information, so accountability was built into the system.

Changes could be traced to the user who made them and the time they were made, creating an audit history around records and workflow activity.

Each department reviewed the requisition, handled its portion of the process, signed off, and passed the paper along.

It was slow, difficult to track, and depended on employees being physically present in the building.

Then COVID sent everyone home, which made the whole “passing pieces of paper around the office” system considerably less practical.

I completed a paperless workflow inside the LIMS so scanned requisitions could move electronically through the organization.

Each requisition PDF was associated with a unique identifier. Employees could review it and sign off digitally, while the system recorded the employee, department, date and time, status or reason, and related notes.

Users could see not only who had already completed their work, but which departments were still waiting to take action.

In other words, instead of wondering where the paper went, they could actually know where the work was.