A previous article on this blog argued that the bottleneck for AI in contact lens practice has been the underlying data infrastructure rather than the AI itself. With the substrate problem in active resolution — structured, normalized contact lens parameter data is increasingly available across academic, clinical, and commercial efforts — a different question becomes pressing: what gets built on top of it?
This article examines the application layer. Two architectural advances are now translating structured lens data into clinical utility, and both deserve closer technical attention than they have received in the clinical literature. The first is natural-language access to parameter data through NL2SQL and retrieval-augmented generation (RAG) architectures. The second is the formalization of clinical decision frameworks into encoded reasoning systems that operate across the structured data layer. Together, they define what a modern contact lens decision support system actually does.
The Query Problem in Clinical Practice
Consider how a contact lens practitioner currently searches for a specific lens. A patient presents with a complex prescription, the practitioner needs to identify which available lenses match the relevant parameters, and the search begins. It moves through fitting guides, lab consultant phone calls, half-remembered cases, and the multiple fitting sets in the back of the office. The query is fundamentally a database lookup, but the database is unstructured and distributed across many sources, so the lookup happens through human memory and human conversation.
The friction this creates is well documented. Decisions get fragmented across visits, patients get rescheduled while the practitioner assembles enough information to make a recommendation, and the quality of the eventual decision depends on how completely the relevant information has been gathered. The practitioner is performing query work without query tools.
This is the problem that natural-language access to structured data solves. When the underlying lens parameters live in a normalized database, the question becomes how to translate clinical language into structured queries against that database — and how to do so reliably enough for clinical use.
NL2SQL and the Translation Layer
Natural-language-to-SQL (NL2SQL) systems take a question in plain language and translate it into a structured database query. The technique has matured rapidly in the past three years, driven by advances in large language models and their ability to handle the syntactic and semantic complexity of database query languages.
The clinical application is direct. A practitioner asks which multifocal soft contact lens designs are available for a presbyopic patient with mild astigmatism in a daily disposable modality. An NL2SQL layer parses that question into a structured query — selecting from the lens table, filtering on multifocal optic, cylinder accommodation, and replacement schedule — and returns the matching results.
The translation is not trivial. Clinical language is full of implicit context. "Mild astigmatism" means different things in different lens categories, "presbyopic" carries assumptions about add power ranges that vary by patient population, and "daily disposable" is a modality designation that has expanded in recent years to include lens designs that older fitting guides may not have categorized consistently. A useful NL2SQL system has to encode that context — typically through schema awareness, few-shot examples, and clinical domain prompting that constrains the model's interpretation.
The system also has to handle queries that current database structures cannot fully answer. Some clinical questions involve parameters that are not directly stored, or that depend on calculations across multiple stored values. This is where NL2SQL alone reaches its limits, and where retrieval-augmented generation extends the architecture.
RAG for Clinical Context
Retrieval-augmented generation pairs a retrieval layer with a generative model, allowing the system to ground its outputs in source material rather than relying purely on parametric knowledge. In clinical applications, this is the architectural pattern that mitigates hallucination — the model generates responses based on retrieved data rather than fabricating plausible-sounding outputs from training data alone.
For contact lens decision support, RAG operates across multiple data sources. Lens parameter data is one corpus. Manufacturer fitting guidance is another. Clinical literature on lens performance, indications, and contraindications is a third. When a practitioner asks a question that spans these sources — for example, what hybrid lens designs are appropriate for a patient with moderate keratoconus who has failed corneal GP wear and reports lens awareness throughout the day — the system retrieves relevant content from each corpus and uses it to ground a coherent response.
The advantage over pure NL2SQL is that RAG can reason across structured and unstructured data simultaneously. Lens parameters live in structured form; clinical guidance often lives in unstructured prose; the practitioner's question often requires both. A well-designed RAG pipeline returns answers that integrate the lens database with the clinical literature, with citations to the underlying sources so the practitioner can verify the reasoning.
The implementation choices matter. The retrieval layer needs to be tuned for clinical accuracy rather than general semantic similarity — surface-level text matching can return lens products that share keywords without sharing clinical relevance. The generative layer needs to be constrained against producing recommendations that exceed what the retrieved data supports. And the citation layer needs to be transparent enough that practitioners can audit any output back to its source.
These are solved problems in the broader RAG literature, but they require careful adaptation to the contact lens domain. The work involves clinical input on what counts as relevant retrieval, validation against expert practitioner judgment, and iterative refinement of the retrieval and generation prompts as edge cases surface.
Computation as a First-Class Layer
A subtle but important point: not every clinical question can be answered through retrieval alone. Some require computation.
Contact lens fitting involves a substantial body of mathematical relationships. Sagittal depth calculations relate base curve and diameter to corneal vault. Tear lens power calculations relate lens base curve to corneal curvature in the optical correction. Toric lens calculations involve the relationship between corneal cylinder, refractive cylinder, and the resulting lens parameters. Orthokeratology parameter calculations involve target refractive change, corneal eccentricity, and treatment zone diameter. Each of these is a mathematical relationship that a practitioner traditionally works through by hand, by formula reference, or by manufacturer-provided calculator.
A complete decision support system needs to handle these calculations alongside its retrieval layer. The architectural choice we have made is to use SymPy — a Python library for symbolic mathematics — as the computational backbone. SymPy treats mathematical expressions as objects that can be manipulated symbolically rather than just numerically, which has practical advantages in clinical computation. Equations can be solved for any variable rather than requiring different formulations for different inputs. Units can be tracked through calculations to catch dimensional errors. Intermediate steps can be exposed for clinical review rather than hidden inside black-box arithmetic.
The integration with the retrieval layer is where the architecture earns its complexity. A practitioner's natural-language question may require both retrieval (finding the relevant lenses) and computation (applying the appropriate formula to specific parameters). The system has to recognize which type of operation each part of the question requires, dispatch to the appropriate layer, and integrate the results into a single coherent response.
This is the kind of orchestration that distinguishes a serious decision support system from a chatbot wrapped around a database. The computation has to be auditable, the retrieval has to be relevant, and the integration has to preserve clinical reasoning rather than obscuring it.
Encoding the Decision Tree
The second major application layer is the encoding of clinical decision frameworks. The progression from soft toric to multifocal to corneal GP to hybrid to scleral to orthokeratology is well understood by experienced specialty practitioners. It has rarely been written down in a way that less experienced clinicians or software can use directly.
The reasons are partly cultural. Clinical decision-making in specialty contact lens practice has traditionally been transmitted through mentorship, conference education, and case-based learning. Each experienced practitioner builds a mental model of which lens types fit which clinical situations, which indications and contraindications drive type selection, and which failure modes signal that a different approach is needed. That mental model works for the practitioner who carries it, but it does not transfer well — and it does not exist in a form that AI systems can reason over.
Encoding the decision tree formalizes that mental model. Each lens type gets an explicit representation of its indications (what clinical conditions it addresses), contraindications (what conditions rule it out), candidacy criteria (what patient or eye characteristics support its selection), and failure modes (what outcomes signal that the approach is not working). Each transition between lens types — soft toric to corneal GP, for example, when soft lens vision is inadequate — gets explicit triggering conditions. The result is a structured representation of clinical reasoning that can be queried, taught, and refined as new outcome data accumulates.
The technical implementation pairs the encoded framework with the retrieval and computation layers. A practitioner describing a clinical case — patient demographics, refraction, corneal characteristics, prior lens history — can receive recommendations that follow the encoded decision tree, with the relevant available lenses surfaced from the retrieval layer and the relevant fitting parameters computed by the symbolic mathematics layer. The system does not replace the practitioner's judgment, but it makes that judgment supported by the same kind of structured reasoning that has historically required years of accumulated clinical experience.
The framework is also a teaching artifact. A clinician early in specialty practice can interrogate the encoded decision logic, see which factors drive each branch of the decision tree, and develop the kind of structured intuition that experienced fitters carry. The encoding turns expertise into a shared resource rather than a private one.
The Architecture as a Whole
The pieces fit together in a specific way. A practitioner's question enters the system and gets routed by an orchestration layer that determines whether the question requires retrieval, computation, decision-framework reasoning, or some combination. The NL2SQL component handles structured queries against the lens database. The RAG pipeline handles questions that require integrating lens data with clinical literature. The SymPy-based computation layer handles mathematical relationships. The encoded decision framework provides the clinical reasoning scaffold that ties retrieved data and computed values to specific recommendations.
What the practitioner sees is a coherent response — answers to clinical questions, supported by the underlying data, with the reasoning auditable back to its sources. What is happening underneath is a multi-layer architecture that has taken several years of engineering and clinical input to build.
The choice to expose the architecture this directly is deliberate. Decision support systems that hide their reasoning earn less clinical trust than systems that surface it. A practitioner who can audit how a recommendation was generated — which lenses were retrieved, which formulas were applied, which decision-framework branches were followed — can integrate that recommendation into their own clinical reasoning rather than simply accepting or rejecting it. That kind of transparency matters more in clinical applications than in most other AI domains.
What Comes Next
The architecture described in this article is not a finished product. Each layer continues to develop. The retrieval and generation components benefit from advances in large language model research and from accumulating clinical input on edge cases. The computation layer expands as additional fitting relationships are formalized into the symbolic system. The decision framework refines as outcome data feeds back into the encoded reasoning.
The applications that become possible on top of this architecture extend well beyond initial decision support. Outcome tracking that closes the loop between recommendations and results. Comparative effectiveness research that uses the structured data substrate as its foundation. Educational tools that turn the encoded clinical reasoning into a teaching resource for the next generation of specialty practitioners. Each of these is a natural extension of the same underlying architecture.
What the practitioner can now ask is genuinely different from what was possible five years ago. The data is structured, the queries are natural-language, the calculations are auditable, and the clinical reasoning is encoded rather than implicit. The result is decision support that operates at the speed of clinical thought rather than the speed of fitting guide cross-reference.
That shift is the practical answer to the question this article opened with — what gets built on top of structured contact lens data. The answer is a decision support system that augments the clinician's reasoning without replacing it, that handles the work software does well so the practitioner can focus on the work only the practitioner can do.