Arbor Research has been busy over the past year linking the clinical health and quality registries and data sources we steward to dynamic, interactive dashboards, built with AI assistance from the start. The concept began with a single client. It now extends to production development for three others, and each engagement has produced iterative lessons about developing AI-assisted tools against complex clinical health data.

The change for our customers is a practical one. Standardized reporting still matters, and it is not going away, but a static report answers only the question it was designed to answer. Anything past that used to mean a request, a queue, and a wait. The dashboards we have built refresh with the registry itself and let users filter by site, cohort, and time period to see their own performance in context. That shortens the distance between having a question and having an answer, which is usually where the value in a registry has been sitting all along.

We have since completed an additional proof of concept that points a large language model directly at registry data. A clinician or program administrator can ask a question in plain language and get an answer grounded in their own records, chart included. What the tool declines to do is just as important as what it does. It computes answers from a defined data snapshot rather than improvising, it tells the user plainly when a question cannot be answered from the data available, and it does not support patient-level lookup by name or medical record number. A tool that admits the limits of its evidence is a tool a clinical program can actually rely on.

Along the way we have worked through the obstacles that determine whether something like this is responsible to deploy. The first was infrastructure. We treated the problem of getting a model next to the data as a matter of network design and authorization, so the model runs inside the same protected cloud environment that already holds the registry rather than in a separate, disconnected AI service. The second was governance. We operate within a walled-garden enterprise environment where our content is never used to train external models, and we work from abstracted or de-identified data rather than PHI. The third was accuracy. Output is validated the way we validate any analytic result, through independent programming and code review, before it reaches the people who will act on it.

The payoff is that our customers can increasingly explore their own data with confidence that the results are accurate and the data is safe. Analysts spend less time regenerating variations of the same report and more time on the questions that genuinely require a statistician. We are continuing to extend this pattern across the registries and data sources we support, and we welcome conversations with organizations working through the same set of problems.