Contact lens practice has watched a curious thing happen over the past decade. Artificial intelligence has transformed corneal imaging, retinal screening, and ophthalmic diagnostics generally, with peer-reviewed validation, FDA-cleared algorithms, and routine clinical adoption all arriving in succession. Meanwhile, the actual selection of contact lenses — the daily clinical decision about which lens to put on which eye — has remained almost entirely in the hands of clinicians working from manufacturer fitting guides, lab consultant phone calls, and accumulated personal experience.
The gap is not because contact lens practice is somehow harder than corneal imaging. It is because the data has not been ready.
This post argues that the bottleneck for AI in contact lens practice has never been the AI. It has been the underlying information — the parameters, specifications, indications, and outcomes that describe what lenses exist and how they perform. That information has always been present in the field, but it has lived in formats that resist computation. Until that changes, no AI tool can do meaningful clinical work in contact lens selection. As that changes, an entire category of decision support becomes possible.
The Imaging Lesson
To understand why contact lens AI has lagged, it helps to look at where AI in eye care has succeeded.
Corneal topography produces structured, quantitative output by design. A topographer measures thousands of points across the cornea and returns numerical maps that downstream software can read directly. Tomography adds elevation data, biomechanical measurements add deformation parameters, and the result is a data substrate that machine learning can operate on. When researchers wanted to train models to detect subclinical keratoconus, the input data was already in a form that algorithms could ingest.
Anterior segment OCT produces structured cross-sectional images. Meibography produces gradeable photographs. Visual field testing produces numerical thresholds. In each of these areas, AI applications have advanced quickly because the input data was structured from the moment of capture.
Contact lens information has none of these properties. A lens parameter is not a measurement — it is a specification, written by a manufacturer, distributed in a fitting guide, and updated through revisions that may or may not propagate uniformly across distributors. The same lens may appear in different formats across different sources. Two lenses with similar names from different manufacturers may have substantially different parameters. Indications and contraindications live in product literature that varies in level of detail. Outcome data, when it exists, lives in clinical records that are not connected to the lens parameter information in any structured way.
The information is real. It is also fundamentally unstructured. Software cannot operate on it without first being given a structure to work with.
Why This Has Persisted
The data infrastructure problem in contact lens practice has been quiet for a reason. It is not glamorous to fix. Building a unified record of contact lens parameters does not produce the kind of headline that attracts research funding or media attention. It is the unspectacular work that everything else depends on — the kind of infrastructure investment that only pays back once the downstream applications start working.
The structure of the industry has also reinforced the problem. Contact lens manufacturers have legitimate reasons to maintain control over their own product information, and there has historically been no neutral entity charged with consolidating that information across the field. Lab consultants build internal databases of the lenses they work with, but those databases are proprietary and tied to specific labs. Practitioners build personal mental models of the lens landscape, but those models are non-transferable and degrade when the practitioner is unavailable. Academic researchers occasionally produce comparative analyses, but those are point-in-time snapshots that go stale quickly.
The result is a field where the information needed for evidence-based lens selection exists in fragments scattered across hundreds of sources, with no shared substrate that allows computation across the whole.
This has clinical consequences that practitioners feel daily. The patient with a complex cornea presents in the chair, and the question of which lens to start with depends on parameters and indications that no single clinician can hold in memory. The answer rarely comes during the visit. The patient is rescheduled, the chart sits on the desk, and the work of selecting a lens happens between visits — often in fragments, across phone calls and product brochures, until enough information has been assembled to make a decision. The cost is real, both in time and in the quality of the decision that eventually gets made.
What AI Actually Needs
The discourse around AI in clinical practice has generally focused on the algorithmic side: which models are most accurate, which architectures are most appropriate for medical applications, which outputs are most clinically useful. This focus is reasonable but incomplete. It assumes the input data is available in the form the model needs, which is often not true.
For decision support in contact lens practice, the AI requirements are clear. A useful system needs to be able to answer clinically meaningful questions about lens availability, parameter ranges, material properties, design features, and indications. It needs to do this in a way that integrates with how practitioners actually think about cases — meaning the system needs to handle natural-language queries, not just structured ones. And it needs to do this across the full population of available lenses, not just a curated subset.
That set of requirements points to a specific architecture. The system needs:
A unified, structured record of available contact lenses, normalized across manufacturers so that comparable parameters can actually be compared. This is the substrate.
A retrieval layer that can match natural-language clinical questions to the underlying structured data. This is what allows a practitioner to ask a clinical question in plain language and get a useful answer back.
A reasoning layer that can apply clinical decision logic on top of retrieval results — accounting for indications, contraindications, candidacy criteria, and the kind of judgment that experienced practitioners bring to lens selection.
None of these layers can do their work without the others. The retrieval and reasoning components depend entirely on the underlying data being structured well. The data, in turn, becomes useful only when it can be queried and reasoned over. The system is integrated by necessity.
Building the Substrate
This is the work TheRightContact has been doing. Building a unified, structured database of contact lens parameters across soft, GP, scleral, hybrid, and orthokeratology categories is the first layer of the architecture above. It has involved consolidating product information from manufacturer specifications, normalizing parameter representations so that lenses can actually be compared, and validating the data against multiple sources to catch the inconsistencies that creep into any large dataset.
The work is not glamorous. A meaningful portion of the effort has gone into resolving conflicts between sources, standardizing how parameters like oxygen permeability or peripheral curve geometry are represented across manufacturers, and building the validation infrastructure that catches errors as the dataset grows. The database currently spans more than 1,700 lenses, and each addition requires careful normalization to remain useful.
The retrieval and reasoning layers are built on top of that substrate. A natural-language query — for example, a practitioner asking which soft toric lenses are available in a high cylinder power on an oblique axis in a high-Dk material — gets translated into a structured query against the underlying database, with the relevant lenses returned along with the parameter information needed for clinical decision-making. The translation from clinical language to structured retrieval is a real engineering problem, but it is solvable when the underlying data is in the right form.
A clinical decision framework runs above retrieval. The progression from soft toric to multifocal to corneal GP to hybrid to scleral to orthokeratology is well understood by experienced specialty practitioners, but it has rarely been encoded in a way that less experienced clinicians or software can use. Codifying that decision tree — the indications, contraindications, candidacy criteria, and failure modes that drive lens type selection — turns expert clinical judgment into a resource that can be queried, taught, and improved with new outcome data.
These layers are not theoretical. They are direct consequences of the underlying data being usable.
What Becomes Possible
When the substrate is in place, applications that have been promised for years become genuinely accessible. A practitioner facing a complex case can query the available lens space in seconds rather than hours. A new graduate who has not yet built a personal mental model of the lens landscape has access to the kind of information that previously required years of accumulated experience. A specialty practice can systematize its decision-making in ways that improve consistency across providers.
The downstream effects extend beyond decision support. Outcome data, once linked to the specific lenses that produced it, becomes a substrate for predictive analytics — dropout risk, dry eye trajectory, compliance modeling. Comparative effectiveness research, currently bottlenecked by the difficulty of standardizing lens parameter data across studies, becomes more tractable. Clinical education, currently dependent on individual mentorship, can incorporate structured access to the lens landscape that experienced practitioners hold in their heads.
None of these are speculative projections. They are the natural extensions of what the underlying data infrastructure makes possible. The applications have been waiting for the substrate.
A Note on What This Is Not
It is worth being explicit about what structured contact lens data does not replace. The clinician's judgment, the practitioner's relationship with the patient, the experienced fitter's intuition about how a particular cornea will respond to a particular lens — none of these are being automated. The data infrastructure described here is the prerequisite for better-supported clinical decisions, not the replacement of clinical decision-making.
The relationship between AI and clinical expertise in contact lens practice is the same as in other clinical domains where AI has matured. The technology handles the parts of the work that scale poorly with human attention — searching across hundreds of products, holding parameter information in memory, integrating multiple sources of clinical guidance. It frees the clinician for the parts that scale only with human judgment — interpreting the specific patient in the chair, weighing tradeoffs that cannot be reduced to algorithmic logic, communicating with patients in ways that build trust.
That redistribution is the actual promise of AI in this field. Not the replacement of contact lens practitioners, but the augmentation of their work with the kind of information access that has been theoretically possible for years and practically unavailable until now.
The Decade Ahead
Contact lens practice is at the beginning of its AI moment, not the end of it. The data infrastructure work that has unblocked decision support is the foundation for a category of clinical applications that will continue to develop over the coming decade. Predictive analytics, comparative effectiveness research, structured outcome tracking, and AI-assisted patient communication are all natural extensions of the same substrate.
The clinicians who learn to work fluently with these tools will be the ones who define what the field becomes. The infrastructure has been the bottleneck. As that bottleneck clears, what gets built on top of it is the next chapter.