Optometry Practice Software for Multi-Location Groups: Where Off-the-Shelf Breaks and What to Build Instead

Why practice software makes or breaks a multi-location optometry group

A six-location optometry group is really three businesses wearing one coat. There is a medical practice billing exams and medical eye visits to Blue Cross and Medicare. There is a retail store selling $400 frames and $250 progressive lenses with vision plan allowances applied. And there is a lab logistics operation moving jobs to Essilor or a local finishing lab and back. Your practice management system was built for one of those three. Usually the first one. The other two get spreadsheets.

The scene we get called about is always some version of this. It is Tuesday morning at the third-busiest location. The optician has a patient at the board who wants a specific Ray-Ban frame. The system says two in stock. The optician walks the wall, does not find them, calls the flagship store, waits three minutes while someone else walks their wall. The frames were sold Saturday at the flagship because inventory syncs nightly and Saturday's sale posted after the sync window. The patient waits eleven minutes, picks a frame she likes less, and walks out with a smaller ticket. That happens somewhere in your group several times a day and you have no report that names it.

Meanwhile the billing coordinator is working a denial queue in a browser tab next to VSP's portal and EyeMed's portal, because RevolutionEHR pushes claims out but the plan-side rejections come back in formats the system does not reconcile. She works denials in a Google Sheet. She catches most of them. The ones she does not catch are real money. Run the math on your own book: a four percent uncaptured denial rate on a $185 average medical claim, at 3,000 exams a month across six locations, is six figures a year that quietly becomes a write-off after it ages past the timely filing window. Most groups cannot produce that number without a two-day audit, which is the actual problem.

Problem one: inventory and the exam room do not know about each other

Optical inventory is not warehouse inventory. A frame has a SKU, but it also has a color, an eye size, a bridge, a temple length, a status (board stock, backorder, or on a patient's face for a trial), and a vision plan tier that determines whether the patient's allowance covers it or they pay an upgrade out of pocket. Off-the-shelf practice systems model frames as a flat SKU with a count. Everything after that lives in the optician's head.

Eyefinity Practice Management and RevolutionEHR both have a frames module. Neither treats real-time cross-location availability as a first-class thing, because their architecture assumes a location is an island that syncs on a schedule. You cannot bolt real-time onto a nightly batch. And when you add Frames Data catalog imports on top, you get duplicate SKUs for the same physical frame across locations, which means your reorder logic is working from a fiction.

What a custom build does: one inventory ledger, event-sourced, with every movement (receipt, sale, transfer, trial, return, discontinue) written as an event with a location and a timestamp. The optician's tablet queries live availability across all six stores and shows a hold button that reserves the frame at the flagship for 48 hours and generates the transfer pick ticket. The doctor's exam room screen shows, during the refraction, which frames on this store's board actually fit this patient's PD and this Rx's lens thickness, so the handoff to optical is a recommendation and not a browse. Reorder rules run per location, per brand, per price band, using that location's own sell-through instead of a chain-wide average that keeps shipping $89 frames to the store that only sells $300 ones.

Problem two: the claim is built after the exam instead of during it

The doctor documents the exam. Hours or days later, the biller opens the chart, reads the note, decides whether this was a routine vision exam (bill VSP) or a medical visit (bill the medical carrier), picks the codes, and submits. That gap is where the money leaks. The doctor knew at minute four that the patient's diabetes made this a medical visit. The biller finds out on Thursday and has to interpret a note written for clinical purposes rather than billing ones.

Off-the-shelf systems cannot close this gap because their exam module and their claims module are separate products that talk through a document. Eyefinity and RevolutionEHR both push to a clearinghouse and both give you a claims worklist. What neither gives you is a rules engine that knows your payer mix, your plan contracts, and your historical denial patterns, because no vendor can write payer-specific logic for tens of thousands of practices on different contracts.

What a custom build does: the claim assembles itself while the exam is documented. Chief complaint and diagnosis codes drive a routing decision (vision plan or medical carrier) at the point of care, and the doctor sees a one-line prompt when the system thinks this should be medical. A scrub layer runs your own denial history as rules before submission: if this payer denied this CPT and modifier combination thirty times in the last year, the claim stops in a queue before it goes out rather than coming back as a rejection four weeks later. AI does real work here. A model reads the clinical note and proposes the routing and the codes with a confidence score, the biller confirms or corrects, and every correction becomes training data for your practice's own patterns. On the intake side, an extraction model reads the insurance card photo and the eligibility response and pre-fills the plan, the allowance remaining, and the last exam date, which kills the two-minute front-desk portal lookup your team repeats 3,000 times a month.

Problem three: recall and no-shows are treated as a marketing problem

Every optometry group has a recall list. Most run it through Solutionreach, Weave, or Demandforce, which fire a text at the 12-month mark and call it done. The result is a chair that sits empty at 2:40 on a Wednesday while a patient who has not been seen in 26 months gets the same generic text as the patient who was in last month.

The recall tools cannot fix this because they sit outside your data. They get a name, a phone number, and a last-visit date through an integration. They do not know that the patient is a myopia-control kid whose parent will absolutely book 4:30 but never 10 a.m., or that this patient's VSP benefit resets in November with the allowance unused, or that they bought a six-month supply of contacts eight months ago and are rationing.

What a custom build does: recall priority computed from your own data rather than a calendar. Benefit reset date, unused allowance, contact lens supply burn rate, the last three appointment behaviors, and the specific chair gaps at their preferred location combine into a ranked outreach list that gets worked in that order. AI helps at two concrete points. First, an after-hours booking agent on your site and phone line that has real availability, understands "I need a contact lens exam, I wear Acuvue Oasys, and I have VSP", and books into the right appointment type with the right duration, so the 6 p.m. to 8 a.m. window stops being a voicemail graveyard. Second, a short-horizon forecast that reads next week's schedule and your own historical no-show rates by patient and by slot, and tells the manager on Friday which slots are likely to open, so overbooking becomes a decision instead of a gamble.

Problem four: you cannot see the group, only the stores

Ask your practice system which location has the best capture rate, meaning patients who had an exam and bought glasses from you rather than walking out with the Rx. You will get six answers you have to assemble in Excel, and they will not agree, because each location's staff records the walk-out differently. Ask which doctor's exams convert best into optical revenue and you will get nothing, because the exam and the optical sale live in tables that were never designed to be joined for that question.

That is a data model consequence, not a reporting bug. Multi-location was added to these products as a tenant flag rather than a design premise, which is why the rollups are shallow and why anything cross-store is a CSV export. Buying a BI (Business Intelligence) tool on top does not fix it. You pay a consultant to build dashboards over a schema that does not contain the relationships you need.

What a custom build does: a shared model where a patient, an encounter, a claim, an optical order, and a lab job are linked entities carrying the location and the provider on each. Then the questions answer themselves. Capture rate by location, by doctor, by day of week. Remake rate by lab and by lens design, which is how you find out that the finishing lab handling two of your stores remakes at more than double the rate of the others, and that difference is worth a renegotiation. Days to deliver by lab. Revenue per exam hour by provider, which is the number that actually tells you where to add a chair.

What this costs and how long it takes

These are Digital Heroes numbers from our own delivery across 2,000+ projects, not industry survey figures. A focused first release, meaning one hard problem solved properly and running in your stores, is $60k to $130k and ships in 12 to 16 weeks. For an optometry group that first release is usually either the claims layer (routing, scrub, denial worklist, reconciliation against VSP and EyeMed) or the unified inventory and optical order layer. Pick one. The groups that try to do both in release one are the groups that ship in month nine.

A full platform, meaning you replace the practice management layer and run exams, optical, claims, labs, and reporting on your own system, is $150k to $400k phased over 6 to 12 months. That range is wide because of what drives it in this category specifically.

Integrations are the biggest single lever. Every diagnostic device you want in the chart is its own project. Zeiss, Topcon, Optos, and Icare each speak their own dialect of DICOM or something worse, and some require a device-side broker on the store network. Budget per device family, not per device. Clearinghouse integration (Change Healthcare, Availity, Trizetto) is well-trodden, but the payer-specific edge cases are where weeks go. Lab integrations via DVI or a direct Essilor connection add real time. Frames Data licensing and catalog sync is a known quantity but not free.

HIPAA is not a line item you skip, and it is not expensive if you design for it. Audit logging on every PHI read, encryption at rest and in transit, role-based access down to the location level, BAAs with every vendor including your AI provider, and a documented breach process. If you also sell to patients online, you inherit PCI scope. The expensive version of compliance is the one you retrofit in month eight.

Migration is the underestimated one. Twelve years of charts in RevolutionEHR, with scanned documents, historical Rx data, and claim history, is not a CSV export. Budget four to eight weeks of a real engineer's time and expect to run parallel for a full billing cycle.

Build or buy: take the position

Buy if you are one to three locations doing under about 1,200 exams a month. RevolutionEHR or Eyefinity, priced per provider per month, will hold you, and your problems are process problems that software will not solve. A custom build at this scale is a vanity project with a maintenance bill.

Build when three of these are true at once. Your denial and write-off leakage exceeds the annual cost of a build, which for most groups happens between four and six locations. You employ someone whose actual job is moving data between systems, or you have a spreadsheet the business would stop without. You have a service line the market does not serve well, like myopia management with its own recall cadence and treatment protocols, or dry eye with device-driven treatment plans, and your system cannot model it. Or you are acquiring practices, and every acquisition costs you three months of data cleanup because there is no clean way to fold a new location into your stack.

There is a middle path and we recommend it more often than a rip-and-replace: keep RevolutionEHR as the system of record for charts and build the layer that is bleeding. Claims intelligence, unified inventory, group reporting, and patient booking can all sit on top through the API while the clinical record stays where it is. That is the $60k to $130k first release, it pays back inside a year at six locations, and it does not bet the practice on a migration.

How to choose a developer for optometry practice software

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

Ask what they have shipped against a clearinghouse and a vision plan. Which clearinghouse, which payers, and what happened when a claim came back with a rejection the spec did not describe. The answer tells you whether they have lived inside an 837 and a 999 or only read about them. Ask specifically about vision plan claims versus medical claims, because a developer who has only done medical will not understand why the same exam routes two ways.

Ask how they handle a store with bad internet. Your locations lose connectivity. If the answer does not include offline capability for the exam room and the point of sale (POS), with a conflict resolution story for what happens when two stores sold the same frame while one was offline, they have not run software in a retail environment.

Ask who owns the code and get it in writing before the first invoice. You should own the repository, the infrastructure accounts, and the deployment pipeline, and you should be able to hand the whole thing to another firm on thirty days notice without a conversation. Any hesitation there is your answer. Also ask what the BAA situation is with every subprocessor including whatever AI vendor sits behind the coding assistant, because that liability is yours, not theirs.