OpBill was designed by a team of surgical assistants, surgeons and physicians who knew exactly how much of a clinician's week disappears into billing. Inpatient claiming in Australia runs across Medicare, private health funds, the Department of Veterans' Affairs, WorkCover and third-party payers, and the software built for it was desktop-bound and tied practitioners to a clinic. OpBill proved the demand with a first mobile app released on 20 February 2017, but that build left the slowest part of the job untouched: a practitioner still had to read a hospital sticker and type its contents into a phone, case after case, which is precisely the work a mobile-first product exists to remove.
An AI-powered OCR claiming flow that made medical billing 90 percent faster, built in 4 months.
Snap, Scroll, Done
OpBill is an Australian medical billing app for surgical assistants, surgeons and physicians. PixelForce rebuilt it around an AI-powered OCR claiming flow - Snap, Scroll, Done - that made medical billing 90 percent faster with 98 percent user satisfaction, delivered in 4 months.
Faster billing 90%
User satisfaction 98%
Rebuild delivered in 4 months
The Problem
The Solution
PixelForce rebuilt OpBill as a single cross-platform product and put optical character recognition at the centre of the claiming flow. The practitioner photographs the hospital sticker, OpBill reads the patient and case details off it, and the practitioner scrolls to confirm the hospital, the surgeon and the item numbers before submitting. Snap, Scroll, Done. The typing step that used to define the workflow is now a review step, and the same healthcare application handles Medicare, health fund, DVA, WorkCover and third-party claims from one screen.
The Outcome
The rebuilt app made medical billing 90 percent faster with 98 percent user satisfaction, and it was built in 4 months. OpBill states on its own site that a case now takes about ten seconds to submit, and that the OCR system improves accuracy while keeping its processing costs low.
A validated app that had not yet removed the real work
OpBill is a product of OpBill Pty Ltd, created by practising surgical assistants, surgeons and physicians rather than by a software company that decided to enter healthcare. That origin shows in what the product refuses to do. It does not try to be a practice management suite. It does one job - getting an inpatient claim out of a hospital corridor and into a payer's system - and it is judged on how few seconds that takes. The app is free to download and covers billing for privately insured patients, third-party and WorkCover cases, Medicare and DVA.
The first version, released in February 2017, established that clinicians would bill from a phone. What it did not do was remove the transcription. Every claim still began with someone reading a hospital sticker and retyping it, which capped how fast the app could ever be and made accuracy a function of how tired the person holding the phone was. It was also two native codebases, so every change had to be built twice. By 2024 the OpBill team had enough real usage data to know exactly which parts of the workflow were costing their users time, and they returned to PixelForce for a full redesign and rebuild rather than another round of incremental fixes.
Transcription was the bottleneck
Every claim started with a practitioner reading a hospital sticker and typing its contents into the app. Until that step was removed, no amount of interface polish would make billing meaningfully faster.
Two codebases, one product
The original app was built as separate native applications for iOS and Android. Every feature had to be specified once and implemented twice, which slowed delivery and doubled the maintenance surface.
Five payer types, one flow
Medicare, private health funds, DVA, WorkCover and third-party claims each carry their own requirements. The rebuild had to absorb that variation without exposing it as five different journeys.
Sensitive data from the first line of code
<p>The app handles patient and financial information. How that data is stored, accessed and audited had to be designed into the architecture during scoping rather than retrofitted once the product was working.</p>
OpBill's founders are working surgical assistants, surgeons and physicians, which meant the people signing off the design were also the people using the product between cases. The engagement was structured around that reality: decisions were settled in short, focused sessions rather than long review meetings, and every proposed change was tested against one question - does this remove a step from a claim, or add one. Requirements were written down and agreed before development started, which is what allowed a four-month build to hold its shape.
Hinney Lo Founder & CEO, PixelForce
Book a consultationA billing app is not judged on its feature list. It is judged on how long a claim takes when someone is standing in a corridor between cases. Once you accept that, scoping stops being an argument about what to build and becomes an argument about what to remove, and the camera turns out to be worth more than any screen you could have designed.
Swipe to explore
How we rebuilt the claiming flow
The engagement began with Phase 1 Scoping and Design. Workshops with the clinician founders produced a Business Requirements Document, a full UX/UI design, a Product Requirements Document and a fixed-cost Statement of Work. Scoping and design always precedes development at PixelForce, and on a product whose entire value proposition is measured in seconds per case that discipline decides the outcome. The design question was not which features to add. It was which taps to delete.
The answer was to make the camera the input method. OCR reads the hospital sticker and pre-fills the case, so the practitioner's job changes from entering data to confirming it. Frequently used item numbers, surgeons and accredited locations are saved against the practitioner's profile, so the fields that OCR cannot read are usually one tap away rather than a search. Push notifications and email cover the exceptions - a flagged case, a status change - so the practitioner does not have to open the app to find out whether anything needs attention. Claims are trackable from upload through to payment, and monthly statements go out by email.
The product was rebuilt as one cross-platform codebase serving iOS and Android, which removed the duplicate implementation work and let a single release reach every user at once. Because modernising an existing product means inheriting live users as well as live data, the architecture was designed so that additional practitioners and additional payer integrations are capacity decisions rather than re-engineering projects, with data protection and access control specified in Phase 1 rather than added afterwards. Every release moved through structured quality assurance before it reached a clinician mid-shift.
Snap · Scroll · Done
Medicare, health funds, DVA, WorkCover and third party, from one screen.
A hospital sticker, a photograph, and a claim on its way.
- OCR claim capture
- Saved billing preferences
- Five payer types
- Claim tracking
- Flagged case alerts
- One cross-platform codebase
01 06
OCR claim capture
The practitioner photographs the hospital sticker and OpBill reads the case details off it. OpBill states on its own site that the system improves accuracy and keeps its processing costs low, and that submitting a case takes about ten seconds.
This is the change that carries the whole rebuild. Removing transcription does not just save the typing time - it removes the point in the workflow where a claim was most likely to be entered wrong and rejected later.
02 06
Saved billing preferences
Item numbers, surgeons and accredited hospital locations are saved against the practitioner's profile. The fields the camera cannot fill are the ones the practitioner uses most often, so they are presented as a short pre-selected list rather than a search.
03 06
Five payer types
OpBill accepts claims for Medicare, private health funds, the Department of Veterans' Affairs, WorkCover, third-party payers and publicly outsourced patients. Each has its own requirements, and the design work was in absorbing that variation inside one submission flow rather than exposing it as separate journeys.
04 06
Claim tracking
Every case is trackable from upload through to payment, so a practitioner can see where a claim sits without contacting anyone. Monthly statements are emailed out, showing how many cases have been billed and what has been received.
05 06
Flagged case alerts
Push notifications and email cover the exceptions. When a case is flagged or its status changes, the practitioner is told rather than having to check. The default state of the app is that nothing needs your attention, which is the correct default for software used between operations.
06 06
One cross-platform codebase
The rebuild replaced two separate native applications with a single cross-platform codebase serving iOS and Android. One implementation, one test pass, one release, and both halves of the user base receive a change at the same time.
Services in the OpBill build
Frequently Asked Questions
OpBill is an Australian medical billing app for surgical assistants, surgeons and physicians. It lets a practitioner submit an inpatient claim from a phone by photographing the hospital sticker, confirming the hospital, surgeon and item numbers, and uploading. It handles Medicare, private health fund, Department of Veterans' Affairs, WorkCover and third-party claims. OpBill is a product of OpBill Pty Ltd, created by practising clinicians. PixelForce designed and built it.
PixelForce delivered a full redesign and rebuild of the OpBill mobile app. The work replaced two separate native codebases with a single cross-platform codebase serving iOS and Android, and rebuilt the claiming journey around an AI-powered OCR flow that reads the hospital sticker instead of asking the practitioner to retype it. The rebuild made medical billing 90 percent faster with 98 percent user satisfaction, and was built in 4 months.
Optical character recognition turns the slowest part of a claim into the fastest. Instead of reading a hospital sticker and typing the patient and case details into a form, the practitioner photographs it and the app extracts the details. Data entry becomes data confirmation. OpBill states on its own site that its OCR system improves accuracy and keeps processing costs low, and that a case now takes about ten seconds to submit.
The OpBill rebuild was delivered in 4 months. PixelForce runs every engagement in the same sequence: a free consultation, then Phase 1 Scoping and Design producing a Business Requirements Document, UX/UI design, a Product Requirements Document and a fixed-cost Statement of Work, then Phase 2 Development, QA and Release, then Phase 3 Post Launch Support. The timeline is fixed at the end of Phase 1, once the feature set is agreed, rather than estimated before the product is defined.
Scoping and development are priced separately. At PixelForce, Phase 1 Scoping and Design runs $35,000 to $65,000 and produces the blueprint. Phase 2 Development, QA and Release typically ranges between $100,000 and $350,000 depending on scope. A billing product usually sits in the middle of that range, because the complexity is concentrated in payer rules and data handling rather than in screen count. The exact figure is fixed in a Statement of Work before development starts.
By designing for it during scoping rather than retrofitting it. On the OpBill rebuild, data protection, access control and the handling of sensitive financial and clinical information were specified in Phase 1 Scoping and Design, alongside the feature set, so the architecture was built to meet them from the first line of code. Retrofitting security into a working product is expensive and rarely as complete, which is why PixelForce issues no development quote without a completed blueprint.
It depends on what the app does. OpBill was originally two separate native applications for iOS and Android, which meant every feature was implemented twice. PixelForce rebuilt it on a single cross-platform codebase, so one implementation ships to both platforms and clinicians on either device receive a change at the same time. Cross-platform suits products like this, where the value is in workflow and data handling rather than in deep device-specific capability.
Yes. Phase 3 Post Launch Support is a standing part of every PixelForce engagement, available as a warranty, monitoring and support arrangement from $4,000 per month, or as a full product retainer from Steady at $10,000 to Momentum at $50,000 per four-week cycle for clients who want continuous development. Healthcare products carry regulatory and payer changes that arrive on someone else's schedule, so ongoing support is a practical requirement rather than an optional extra.
Up next
More products we have designed, built and launched end to end.
