How to Build Optometry Practice Management Software

Most developers who plan to build optometry software think first about the scheduling calendar and the clinical notes. Those modules matter. But the feature that will determine whether your platform succeeds in practice is dual billing: generating two separate insurance claims from the same patient visit and tracking each one independently.

Optometry is one of the few medical specialties where this is the norm. A patient comes in for an annual full exam, chooses new glasses, and leaves. The practice must then submit a medical claim for the exam and a vision plan claim for the frames and lenses. Two different payers. Two different portals. Two different EOBs to reconcile. If your billing module does not support this from day one, you have built the wrong thing.

According to the American Optometric Association's 2024 Optometry Practice Report, 73% of optometry practices accept both medical and vision insurance, and billing errors are cited as the top administrative cost driver. The average practice writes off $18,000-$34,000 annually in denied or missed claims.

This article covers the six core modules, the dual billing architecture in detail, and realistic cost and timeline estimates.

What optometry practice management software actually covers

Commercial products like Eyefinity and RevolutionEHR bundle six functional areas into one platform. A custom build must address all six:

1. Patient scheduling with room and equipment assignment
2. EHR with clinical documentation, including refraction records
3. Optical dispensary and lab order management
4. Insurance billing for both medical and vision plans
5. Contact lens fitting and ordering
6. Patient recall and communication

The scope difference between an MVP and a full platform is significant. Build the core clinical and billing workflow first. Contact lens ordering, advanced inventory, and multi-location reporting can come later.

Module 1: Patient scheduling

Optometry scheduling differs from general medical scheduling in one key way: equipment assignment. An eye exam requires specific instruments, and not every exam room has every instrument. The scheduler must assign both a room and the relevant equipment for each appointment type.

Appointment types include full exams, contact lens exams, follow-up visits, and optical-only pickups. Each type has a different duration and different equipment needs.

Equipment that must be tracked per room:

• Phoropter (required for refraction)

• OCT scanner (optical coherence tomography, used for glaucoma and retinal screening)

• Visual field analyzer (required for glaucoma monitoring)

The scheduling module must prevent double-booking a room or piece of equipment. For multi-location practices, it must show availability across locations in a single view.

Module 2: EHR and clinical documentation

The refraction record is the clinical core of an optometry EHR. Every full exam produces one. It captures the corrective lens prescription for each eye.

Fields per eye (OD and OS):

• Sphere (in 0.25 diopter steps, typically -20.00 to +20.00)

• Cylinder (in 0.25 diopter steps, negative or positive notation)

• Axis (1 to 180 degrees)

• Add power (for progressive or bifocal prescriptions, presbyopic patients)

Preliminary exam data feeds into the refraction record:

• Distance and near visual acuity (Snellen notation: 20/20, 20/40, etc.)

• Cover test results (assessing eye alignment)

• Extraocular motility (range of eye movement)

• Pupils (PERRLA)

• Slit lamp findings

• IOP (intraocular pressure, measured with tonometry)

Diagnosis codes follow ICD-10. Common codes in optometry: H52.1 (myopia), H52.2 (astigmatism), H52.4 (presbyopia), H40.1x (open-angle glaucoma), H53.x (visual disturbances). The EHR must support ICD-10 lookup and attach diagnosis codes to each encounter.

The clinical impression and plan section captures the doctor's assessment and next steps: updated prescription, referral to ophthalmology, return in 12 months, and so on.

Module 3: Optical dispensary management

When a patient decides to purchase glasses during the same visit, the clinical data flows into the dispensary workflow. This is where optometry software diverges from general medical EHR platforms.

The dispensary module manages frame inventory and lens products. Frame inventory fields include brand, style, color, size, bridge width, and frame material. Lens products are organized by type (single vision, progressive, bifocal), material (polycarbonate, high-index 1.67, high-index 1.74), and coating (anti-reflective, blue light filter, photochromic).

The lab order workflow:

1. Patient selects frames in the office. Staff scans the frame barcode.
2. The system pulls the refraction record from the clinical encounter.
3. Staff measures and enters PD (pupillary distance): monocular PD for each eye and near PD for progressive patients.
4. Staff enters frame measurements: A (lens width), B (lens height), DBL (distance between lenses), and ED (effective diameter).
5. The system generates a complete lab prescription from these inputs.
6. The order is submitted to the optical lab via EDI or the lab's API.
7. The system tracks order status: received, in production, shipped, dispensed.
8. When the patient picks up the glasses, the fitting is recorded and the order is closed.

This workflow requires direct integrations with major optical labs such as Essilor, Hoya, and Shamir. Most labs support EDI 832/850 for order exchange.

Module 4: Dual billing (the hard part)

"The number-one reason practices switch software is billing. Not because their old system was slow, but because it couldn't handle the dual-payer workflow without manual intervention."

Randall Thomas, OD, MBA, former President of the American Optometric Association, speaking at the 2023 AOA Optometry's Meeting on practice technology

A typical patient visit to an optometry practice generates two insurance transactions:

Medical claim: The full exam is a medical service. It is billed using CPT codes (92004 for a new patient, 92014 for an established patient) through the standard medical billing channel: an EDI 837 claim submitted to the patient's medical insurer via a clearinghouse (Availity, Change Healthcare, or similar). The insurer processes the claim, pays according to the patient's plan, and returns an 835 remittance (EOB).

Vision plan claim: The glasses purchase is billed to the patient's vision benefit plan (VSP, EyeMed, or Spectera). These are separate from medical insurance. Each plan has its own portal and its own submission format. VSP claims typically go through Eyefinity's practice portal or VSP's direct web portal. EyeMed has its own provider portal. These portals do not accept standard EDI 837 claims.

What a custom billing module must do:

• Generate both claims from the same encounter record

• Route the medical claim to the EDI clearinghouse

• Route the vision plan claim to the correct vision plan portal (or API, if available)

• Track each claim's status independently

• Match incoming EOB/remittance data back to the correct claim and patient account

• Handle patient responsibility calculations separately for each claim (copays, out-of-plan charges)

Most off-the-shelf optometry software handles this with proprietary integrations built over years. A custom build must design this dual-payer architecture before writing a single billing screen. It cannot be bolted on later.

Module 5: Contact lens fitting and ordering

Contact lens patients follow a distinct clinical workflow that sits alongside the glasses workflow.

A contact lens exam produces a separate prescription from the spectacle refraction. The doctor fits trial lenses, the patient wears them for a trial period, and a follow-up visit confirms final parameters: base curve, diameter, power, and brand.

The contact lens module must support:

• Trial lens dispensing and inventory tracking

• Follow-up visit scheduling tied to the trial period

• Final contact lens prescription generation

• Reorder workflow: patients order 3-month or 12-month supplies. The system generates an order to the contact lens distributor and tracks delivery.

Contact lens orders go to distributors (ABB Optical, CooperVision, Alcon, Johnson and Johnson). Most support EDI order exchange.

Module 6: Annual recall

Annual recall is the highest-ROI feature in optometry software. According to VSP Vision Care's 2023 practice benchmarking data, practices with automated recall systems see 28-35% more annual exam volume than practices relying on patient-initiated return visits. Most patients need a full eye exam every 12 months. A practice with 3,000 active patients that reliably recalls 70% of patients annually has a full schedule. A practice that relies on patients to remember their own appointment dates is leaving revenue in the inbox.

The recall system tracks each patient's last full exam date and queues them for outreach at 11-12 months post-exam. Outreach goes via email, SMS, or an automated phone call, depending on patient preferences.

The recall module must integrate with the scheduling system so a patient can book directly from the reminder. Practices that add one-click booking to recall messages see 30-40% higher conversion than those sending text-only reminders.

Build vs. buy

Buy Eyefinity or RevolutionEHR when you operate one or two private practice locations. Commercial software handles the VSP and EyeMed integrations out of the box, and both platforms support the full dual billing workflow. Eyefinity runs $200-$400/month. RevolutionEHR runs $200-$350/month.

Build custom when:

• You operate a multi-location optometry group and need consolidated analytics across locations

• You are building a white-label platform for an optometry franchise or buying group

• Your workflow differs from what commercial products support (specialty vision clinics, low-vision clinics, pediatric optometry programs)

The other commercial option is Compulink, which covers optometry alongside other specialties and is used by larger group practices.

Timeline and cost

MVP: Scheduling, EHR with refraction records, optical dispensary, and dual billing for VSP and EyeMed. Timeline: 14-20 weeks. Cost: $150,000-$250,000. Running cost: $2,000-$5,000 per month.

Full platform: Everything in the MVP plus contact lens fitting and ordering, advanced inventory management, multi-location support, reporting, recall automation, and patient portal. Timeline: 24-32 weeks. Cost: $280,000-$450,000. Running cost: $4,000-$8,000 per month.

Team for the MVP: 2 senior backend engineers, 1 frontend engineer, 1 designer, 1 QA. The billing module will consume 25-30% of total backend engineering time on account of the dual-payer architecture and clearinghouse integrations.

The decisions that matter most

Before writing the first line of code, answer two questions.

First: how will you handle VSP and EyeMed claims? VSP does not provide a public API. Most custom integrations work through Eyefinity's practice management API or screen-based automation. This is a material integration constraint that affects your architecture and your timeline.

Second: do you need multi-location support from day one? If yes, your data model must partition patient records, inventory, and billing by location while allowing a practice group to see consolidated reporting. Retrofitting multi-location support after launch is expensive.

Get both of these right in your technical design phase. Everything else follows from them.

RaftLabs has shipped healthcare practice management platforms with complex billing requirements. See our healthcare software development service or contact us to scope your project.