Optometry Practice Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a two problem first release become a nine month project?

This is the most reliable way to fail here, and it is almost always well intentioned. The group has two obvious wounds, claims leakage and cross location inventory, and the first release is scoped to fix both. Nine months later neither is in production, because they are genuinely different systems that happen to share a patient.

The claims layer is a rules and reconciliation problem living against payer behaviour and a clearinghouse. The inventory layer is a real time distributed ledger problem living against six stores, unreliable connectivity and a point of sale (POS). They share almost no code and no domain expert, so running them together doubles the surface area while halving the attention each gets, and the first thing to slip is testing.

Pick one and ship it into your stores inside twelve to sixteen weeks. If your denial write-offs are larger than your walk-out losses, take claims. If your opticians are phoning other stores to find frames, take inventory. The groups that go live on one problem build the operational trust and the internal habits that make the second release faster. The groups that scope both go live on neither and spend the money anyway.

What goes wrong when you migrate charts off RevolutionEHR or Eyefinity?

Anyone quoting a chart migration as a two week export has not done one. The structured data is the easy part. Five things routinely go wrong.

• Prescription format drift. Twelve years of records span format changes, and a spectacle prescription, a contact lens prescription and a trial are not the same object even though they look similar in an export. Collapsing them destroys the clinical history a doctor relies on at the next visit.
• Scanned documents orphaned. Referral letters, outside imaging reports and signed consents live as attachments with weak links to encounters. Migrations that move the database and not the document store leave charts that look complete and are not.
• Claim history that does not reconcile. Payments, adjustments, patient responsibility and write-offs have to tie penny for penny, because your accounts receivable is the opening balance of the new system. If it does not tie, your billing lead will keep the old system open, and then you are running two.
• Optical orders and lab jobs treated as line items. An order has a lifecycle: ordered, at lab, remake, delivered. Flattening it to a sale destroys your remake analysis, which is one of the highest value reports you will ever run.
• Recall state lost. Last visit date survives migration. Why someone was recalled, and whether outreach already happened, usually does not, so your first month on the new system re contacts people you contacted last week.

Budget four to eight weeks of senior engineering time inside the project and plan to run parallel for a full billing cycle. Have your billing lead sign off on the accounts receivable reconciliation before cutover, not after.

Why do device, clearinghouse and lab integrations break after launch?

Integrations in this category do not fail loudly, they drift. Three patterns account for most of it.

Diagnostic devices are the first. Each manufacturer speaks its own dialect, some need a broker running on the store network, and that broker is a machine in a back room that someone will eventually reboot, replace or unplug. When a device stops exporting, the images simply stop arriving in the chart, and nobody notices until a doctor looks for a prior field test. Budget per device family rather than per device, and monitor for absence: if a device that produced results every clinic day produces none today, that is an alert.

Clearinghouse and payer behaviour is the second. The submission path is well trodden, but rejections arrive that the specification did not describe, and payer edits change without notice. A system that only handles documented rejection types will accumulate an unclassified pile that a human works by hand, which is the workflow you were trying to replace. Build the unclassified bucket as a first class queue with an owner and an age, and feed every resolution back as a rule so the same rejection stops twice.

Lab and catalogue synchronisation is the third. Catalogue imports create duplicate records for the same physical frame across locations, and once duplicates exist your reorder logic is working from fiction. Deduplicate on import with human confirmation, and reconcile lab job status on a schedule rather than trusting event delivery, because a missed status message is a patient waiting for glasses the system believes were delivered.

What happens when offline stores and HIPAA scope are not covered?

Two gaps in this vertical are structural rather than cosmetic.

The first is connectivity. Retail locations lose internet. If the exam room and the point of sale stop working when the line drops, staff will revert to paper and reconcile later, which is how two stores sell the same frame and how a day of encounters gets entered from memory. Offline capability has to be designed in, with an explicit answer for conflict resolution when two locations transacted against the same item while one was disconnected. Ask any prospective developer what happens when a store is offline for four hours and then reconnects with a day of activity queued. If the answer is that connectivity is assumed, they have not run software in retail.

The second is compliance scope, cheap when designed in and expensive when retrofitted. Audit logging on every read of protected health information, encryption at rest and in transit, role based access scoped to the location, signed business associate agreements with every vendor in the chain including whatever model provider sits behind a coding assistant, and a documented breach process. If you also sell to patients online you inherit payment card scope on top. Decide this at design time. We have been called in to retrofit it in month eight, and it is never cheap.

A third gap is quietly expensive: routing a visit as vision plan or medical after the fact. The doctor knew at minute four that the patient's condition made this a medical visit. If that decision is only reconstructed days later by a biller reading a note written for clinical purposes, you will route some of them wrong, and the correction costs more than the exam earned.

Should you build custom or configure what you already own?

If you run one to three locations doing under roughly 1,200 exams a month, stay on RevolutionEHR or Eyefinity Practice Management. They will hold you comfortably, and at that scale your problems are process problems that software will not solve. A custom build is a maintenance bill attached to a vanity project.

Before commissioning anything at any scale, audit what you already pay for. A lot of the pain at growing groups is configuration that stopped halfway: recall rules never tuned past the twelve month default, claim worklists never assigned to owners, frames modules loaded once and never reconciled. If a module is sitting unused beside a spreadsheet, a configuration engagement is faster and far cheaper than a build.

The middle path is the one we recommend most often, and it is not a rip and replace. Keep RevolutionEHR as the system of record for clinical charts and build only the layer that is bleeding: claims routing and denial recovery, unified inventory, group reporting or patient booking, connected through the application programming interface. That avoids a chart migration entirely, costs a fraction of a replacement, and can be reversed. Full replacement only earns its risk when the clinical model itself blocks a service line you need, such as myopia management with its own recall cadence and treatment protocols, or dry eye with device driven treatment plans.

Build when three signals hold together: denial write-offs plus the salary of whoever manually moves data between systems exceeds the build cost, you have a spreadsheet the business would stop without, and you are acquiring practices where every acquisition costs three months of cleanup because there is no clean way to fold a location into your stack.

How do hidden costs get into the quote?

• Device families. Quotes priced per project rather than per device family are wrong, and the difference is weeks. Count the manufacturers you need in the chart before signing, including the one in the store you are about to open.
• Payer specific edge cases. Connecting to a clearinghouse is a known quantity. Handling how your specific payers actually reject is not, and that is where the calendar goes.
• Parallel running. A full billing cycle in parallel means your staff work two systems for a month. That is a real cost in overtime and errors, and it belongs in the plan rather than in the surprise column.
• Frame catalogue licensing. A known quantity but not free, and duplicate resolution across locations is work on top of the licence.
• The rules owner after launch. Denial rules and routing logic need someone who maintains them as payers change. Costing the build without costing that role is how a scrub layer becomes stale within a year.

What separates a build that works from one that fails here?

Ask them to model the data on a whiteboard before you sign anything. Someone who has built in this category draws the encounter, the prescription, the optical order and the lab job as separate entities with their own lifecycles, and asks whether a contact lens prescription and a spectacle prescription are the same thing in your world. Someone who has not draws a patients table and an appointments table. That distinction is visible in fifteen minutes and it predicts the rest of the project.

Ask what they have shipped against a clearinghouse and which payers, and specifically what happened when a rejection came back that the specification did not describe. Ask about vision plan claims as distinct from medical claims, because a developer who has only done medical will not understand why one exam routes two ways. Ask what happens when a store loses internet, and require an answer covering offline exam room and point of sale plus conflict resolution on reconnect. Ask how the system will make your denial number visible in week one, because that is the measurement that tells you whether the rest of the build is working.

Finally, get ownership in writing before the first invoice: the repository, the cloud accounts, the deployment pipeline and the documentation, transferable to another firm on short notice without negotiation. At Digital Heroes the client owns all of it from the first commit. Ask the same question about business associate agreements with every subprocessor, including any model provider behind an assistant feature, because that liability is yours rather than the developer's.