The state of ophthalmology software in Australia.

An ophthalmologist generates more imaging before morning tea than some specialties see in a week, and yet the software you are handed makes you fight for nearly all of it.

Eye care is one of the most data-dense fields in medicine, because OCT, fundus photography, visual fields, biometry and topography often pile up on the same patient at the same visit. The instruments that capture all of this are superb, but the software is among the worst-served in medicine, because the systems meant to tie the instruments together were built for a different job. That mismatch is not a one-off complaint; it shows up in every clinic that runs these systems, and it is worth taking apart piece by piece.

The imaging silo problem

The first problem is that every device tends to arrive with its own viewer, its own database, and its own idea of what "export" means, so the OCT, the fundus camera and the field analyser each capture beautifully and then keep what they captured to themselves. The everyday cost of that is concrete, because comparing today's OCT to last year's, beside the visual field and the disc photo, can mean three logins, three viewers and a manual export just to get one machine's image to sit next to another's. The result is that the longitudinal view, the one that actually tells you whether the disc is changing, is the single view no system reliably gives you, even though it is the whole point of following the patient.

DICOM exists precisely to standardise this, and the better instruments speak it,¹ so in principle the silos should not survive. In practice a great deal of installed hardware exports proprietary formats, or exports DICOM with enough vendor-specific quirks that "DICOM-compatible" quietly stops meaning interoperable, and a single practice rarely has the buying power to force a fleet of devices from different makers into one coherent record. So the clinician becomes the integration layer, which means the most expensive and least reliable middleware in the building is reconciling by memory what the software will not reconcile by design.

This compounds the moment you ask the software to do anything clever with the data, because a vendor's progression analysis, the trend lines that flag a thinning retinal nerve fibre layer or a widening field defect, generally only runs on that vendor's own captures. Mix an OCT from one maker with fields from another and the automated trend simply is not on the table, so you are back to eyeballing change across printouts. The data is rich enough to drive real decision support, which makes it all the more frustrating that the silos are most of what keeps that support from arriving.

The practice system was built for billing, not for your clinic

Most general practice-management platforms grew up around appointments, Medicare claiming and the front desk, and clinical content was added afterwards. In a high-throughput imaging specialty that ordering shows, because the clinical record is often a thin note hanging off a billing system, rather than a clinical system that also happens to bill. That inheritance is the root of most of what feels wrong about these systems in an eye clinic.

What is missing is specialty fit, and it shows in the details that an eye clinic deals with all day. Laterality should never be ambiguous, which means OD, OS and OU captured as structured data rather than typed into a sentence you hope the next reader parses correctly. The examination should be laid out the way you actually work, moving through anterior segment, posterior segment, pressures, fields and drops, and the intraocular pressure should be something you can trend across visits at a glance rather than re-read out of prose each time, with imaging surfaced beside the note instead of behind another login. Generic software treats the eye as an afterthought, but in an eye clinic the eye should be the primary object the whole system is organised around.

The same gap shows in the shape of the visit, because a glaucoma cohort lives or dies on reliable recall, on the "review in four months with repeat OCT and fields"² that has to actually happen. A system built around one-off billable appointments tends to model that recall poorly, so the safety net quietly becomes a spreadsheet and a diary in someone's head. The clinical risk there is not abstract, because it is the patient who slips out of the recall cycle and is next seen with damage a timely review would have caught.

Referrals still arrive as paper and PDF

A large share of referrals, results and correspondence still moves by fax or scanned PDF, even though secure-messaging networks exist and work.³ Those networks carry clinical documents between practices, largely over HL7 v2,⁴ but coverage is uneven, and whether a letter actually reaches the practitioner you intended depends on directory entries being correct at both ends. The distinction matters in practice, because "supports secure messaging" is not the same as "the letter landed in the right inbox".

For a referral-driven specialty this is not cosmetic, because a referral that arrives as an unsearchable scan is a triage decision and a data-entry job before it is a patient. Someone retypes the history, the medications and the reason for referral by hand, with the transcription errors that implies, and the structured detail an algorithm could have triaged is flattened into an image. So getting structured referrals into the right inbox, reliably, is one of the highest-value and least glamorous problems in the field, and it is mostly unsolved at the level a busy clinic actually experiences. A busy practice can take dozens of referrals a day across that mix of fax, PDF and message, which means every one that arrives unstructured is minutes of someone's time spent on transcription before any clinical decision gets made.

Billing logic nobody wants to own

Ophthalmology billing is a discipline in itself, as a routine case shows: a procedure on both eyes on the same day. The multiple-services rules change how the second eye is remunerated,⁵ and whether a consultation at the same visit is separately claimable turns on whether it was genuinely distinct from the procedure. Add the Department of Veterans' Affairs,⁶ the rules around multiple operators, and the interaction of items that cannot be claimed together, and a single visit becomes a small ruleset. Get the item wrong and the cost is either revenue quietly left on the table or a rejected claim, and at worst a compliance question that surfaces long after the visit.

Software should own this complexity so the clinician and the front desk do not have to, which means encoding the rules and making the correct item the path of least resistance rather than something staff reconstruct from a laminated cheat-sheet. Most generic systems instead push it back onto people and call the spreadsheet that results a workflow. None of it is intellectually hard; it is just unforgiving, it changes over time, and it sits in exactly the spot, between the clinician's decision and the practice's revenue, where mistakes stay quiet until they become expensive.

Your data is yours, until you try to move it

You find out what your data is really worth the day a colleague moves practices and asks for a patient's full imaging history. Too often the answer is a flattened PDF, so the images render but the structured record underneath, the measurements, the trends and the coded findings that make longitudinal eye care possible, stays behind, locked in a format only the old system can read.

That export gap is rarely an accident, because a record that travels cleanly is a record that makes leaving easy, and few systems are built to make leaving easy. From the chair, though, the test is simple: when a patient turns up at the next clinic, does their history arrive as something you can actually use and build on, or do you start it over from a stack of paper? Owning your patients' records means being able to take the structured version with you, not just a printout of it.

What good would look like

Good ophthalmology software is not exotic, because it is simply the specialty treated as the first-class case. That means imaging and notes in a single timeline, laterality that is never guessed, an exam structured the way you examine, referrals that arrive structured and reach the right person, billing that is correct by construction, and a record you can take with you when the patient moves on. None of those are moonshots; each one is the obvious answer to a problem the earlier sections describe.

That is the bar Trenthos is building Lumen toward, a clinical system designed around how an eye clinic actually runs and hosted in Australia, rather than a billing ledger that learned to take notes. It is early, so it is described here as direction rather than a finished claim. But the distance between what the specialty needs and what it has been given is wide enough to be worth closing.