Healthcare automation platform

Context

A healthcare billing team gathered visit and authorisation information, checked that it matched and moved it between tools until billing was complete and payments were recorded. Spreadsheets and email coordinated the work the systems could not handle. A correction could mean revisiting work that seemed finished.

Volume was growing, and each new centre added to the team’s workload. We needed to automate repetitive operations while keeping a clear way to review exceptions. The service had to keep running throughout development, within the access restrictions and information formats already in place.

My role and technical leadership

I prepared the technical proposal, covering the architecture and infrastructure needs, and defined how to organise development and testing. I led the application design and worked with the team on implementation and launch. My responsibility included translating billing requirements into rules and states the software could handle.

I also helped coordinate delivery and resolve questions about scope. As development progressed, we encountered cases the initial requirements did not cover. I brought people who knew the daily operation into those discussions so we could work through real examples and decide what each release needed to include.

This reduced the interpretation required between business and development. We could set limits on new requests and understand their effect on planned work earlier. Budget and product decisions remained shared; I provided the technical judgement and explained the consequences of each option.

Challenges and trade-offs

We built on an existing application foundation to shorten the first delivery. I proposed a separate operational interface, but the decision was to extend the available administration panel to contain costs. That let us move sooner, at the expense of adapting a general tool to an increasingly specific workflow. Maintaining those customisations took more effort than expected.

The integrations also allowed different levels of automation. Some information required human access to an external system. We incorporated semiautomatic data collection into the wider flow to work within that restriction. Subsequent work could be automated once the data was available.

We also had to decide when the flow should stop. An incomplete authorisation or a discrepancy between records needed review. Alerts made those cases visible to the billing team and provided information to decide how to proceed.

Designing the workflow

I organised the application around persisted states: progress was saved and could be inspected after each execution. Scheduled jobs collected changes from the source systems and ran billing operations. Checkpoints recorded how far synchronisation had progressed and helped us locate pending or interrupted work.

I worked with the team on the data model and integrations. A visit, its authorisation and the billing outcome needed to remain connected even when they arrived at different times. We stored references to external records and checked whether they existed before repeating certain operations. We also handled responses indicating that an operation had already taken place, to avoid duplicates in a workflow with financial consequences.

Some authorisations arrived as text. We built extraction rules that recognised patterns in common formats and turned the information into data the application could use. Extraction accuracy was ≈85 to 90%. Cases needing correction still had a path for human review.

The interface allowed the team to monitor progress and handle alerts. Operational knowledge helped us refine the information accompanying each exception. Detecting a discrepancy was of limited use if someone then had to reconstruct the entire case to resolve it.

Performance and growth

Synchronisation became more expensive as volume grew and a requirement changed: some records could be corrected after their first import. We had to query earlier periods again. The accumulated work began to overlap with daily use of the application and degrade its response.

I investigated execution logs to locate expensive operations. We found calls that retrieved too little at a time and repeated queries for related data. This was an N+1 pattern: after fetching a list, another query ran for each item. As the number of records grew, so did the number of data accesses.

The team batched operations, paginated data retrieval and replaced some generic data access with specific queries. This reduced the calls required and improved synchronisation. Separating intensive processing from user requests remained unfinished: I proposed isolating that workload, but the structural change was not completed during my time on the project.

Results

Manual work fell by ≈90%. The operation started with 200 centres and grew to serve more than 1,000 on the platform. The team moved from running the workflow across tools to supervising exceptions and resolving cases that needed human judgement.

Direct involvement from operations also improved delivery predictability and communication with development. The platform went into production, entered maintenance and continued expanding after my time on the project.

Human attention focuses on the cases that need judgement.

What I learned and would change

I would have involved the people doing the billing earlier and tested the least understood integrations before fixing the scope. Several restrictions emerged after they were already influencing design decisions and delivery dates.

I would also have planned from the start to separate intensive tasks from interactive use and test with representative volumes. Corrections to older records needed to be part of those tests. Today I would define earlier what happens when an operation repeats, how interrupted work is recovered and which checks establish that synchronisation is complete.

For shared decisions, I would document the cost and limits of the alternatives. Evidence from actual use would then make it easier to revisit compromises that helped us start but were becoming more expensive to maintain.