Healthcare organizations are not short of data. They are short of decision capacity. That capacity is the ability to turn important questions into answers people trust, understand what those answers mean for the work, act while the information is still useful, and improve based on what happens next. The gap is not caused by a lack of effort. It comes from operating in systems where reliable answers require too much time, cost, and coordination.
A modern data and AI platform can materially shorten that cycle by bringing data engineering, governance, business semantics, analytics, and AI into a common environment. Databricks shows how those capabilities can be assembled as a Data Intelligence Platform. But no platform can do the human work around it: agreeing on meaning, assigning ownership, setting the evidence threshold, testing the answers, and deciding where automation must stop. The opportunity is not to remove analysts from the process. It is to give them back the time to exercise judgment.
I have sat in the meeting where the dashboard is still glowing on the screen and someone asks the question that changes the room. Why did the margin soften? Why is the length of stay moving in the wrong direction? Why are referrals leaving the network even though access appears to be improving?
The dashboard did its job. It made the signal visible. It was not built to carry the conversation any further. The question leaves the room and enters a queue.
An analyst starts tracing the number through encounter tables, attribution rules, and definitions no one outside their own department would recognize. Finance wants a number it can defend. Operations wants an answer now, because staffing and patients won’t wait for the next reporting cycle. No one in that chain is failing. The operating model is failing them.
By the time the analysis is finished, the organization may be studying a different version of the problem than the one it started with. A several-month cycle is not an industry benchmark. It is a recognizable failure mode. Some questions deserve to take weeks because the stakes are high. The goal is not instant analytics. It is removing delay that does not improve accuracy, safety, trust, or judgment.
This deserves a better name than “analytics backlog.” It is a decision-latency problem.
The Decision-Latency Problem
Decision latency is the time it takes to go from noticing a meaningful change to acting on it with confidence. It is the distance between question and action, not just between data and report. Most healthcare leaders already have dashboards and performance indicators. What they lack is a reliable way to get from seeing a signal to understanding it, deciding what to do, acting, and confirming whether it worked.
An AHRQ Patient Safety Network perspective describes a learning health system as one that systematically uses internal data and experience together with external evidence to continuously learn, share knowledge, and improve the quality and safety of care. It also identifies siloed information and inconsistent implementation of best practices as barriers to systemwide learning. Those barriers increase decision latency because teams must locate, reconcile, and validate evidence before acting. The deeper issue is not fragmented data alone. It is the absence of a reliable operating process for learning from it.
The organizations that outperform over the next decade will not necessarily have the largest data estates or the most advanced AI. Their advantage will come from a disciplined ability to recognize change, understand it, act on the evidence, and learn from the result.
A Tale of Two Mondays
Picture an ordinary Monday in a health system, the kind that happens far more often than any crisis does. A metric moves in the wrong direction. There is no cyberattack behind it, no regulatory investigation, no once-in-a-generation event, just the routine work of running a health system, which is how most healthcare leadership time is actually spent.
Monday Morning in the Traditional Model
At 8:00 a.m., a health system COO is reviewing the weekly operating dashboard. Average inpatient length of stay has increased by 0.6 days over the previous six weeks, enough to affect bed availability, staffing pressure, patient flow, and financial performance. A simple question follows: Why?
No one in the room knows. The dashboard identified the issue. It did not explain it. An analytics request is submitted.
During the first week, analysts determine which encounter data should be used, validate the calculation, review exclusion criteria, and reconcile definitions across departments. During the second week, finance asks whether observation encounters should be excluded. Case management wants discharge delays isolated. Operations requests physician-level detail. Each request is reasonable. But the original question keeps expanding. New meetings get scheduled. More validation follows.
Five weeks later, leaders receive a trusted analysis indicating that the increase is concentrated in two service lines and that post-acute placement delays appear to be a major contributing factor. The insight is valuable. But the organization is now studying conditions that existed more than a month ago. Most of its energy went into answering the question. Very little remained for solving the problem.
Monday Morning in a Decision-Intelligence Model
At 8:00 a.m., the same metric increases and the same executive asks the same question. This time, the metric is already defined in a governed Unity Catalog metric view. Certified data products support patient flow, discharge planning, capacity management, and operational performance. Ownership is defined, lineage is visible for supported workloads, and the core logic has already been validated.
The question does not enter a reporting queue. It enters a learning workflow.
With the governed foundation already in place, leaders can investigate whether two service lines account for most of the increase and explore whether skilled nursing facility placement delays and authorization turnaround times are contributing factors. Analysts remain involved, but their role changes. Instead of reconstructing established metrics, they validate the data, query logic, and explanatory evidence for this specific decision. The platform can accelerate investigation; it does not eliminate the need to distinguish correlation from cause.
By Wednesday, leaders define and launch targeted interventions. The following week, they begin measuring early indicators of impact. The analytics work did not disappear. The avoidable delay did.
The organization moved from signal to question, analysis, decision, action, and learning. That is the practical promise of decision intelligence.
Dashboards Still Have a Job, Just Not the Whole Job
Dashboards are an effective way to operationalize predefined analytics for regular use. They remain useful for recurring surveillance, shared operating cadence, and familiar questions about census, capacity, quality, cost, and performance against plan. The strongest version of this argument is not that healthcare should stop building dashboards, but that dashboards should serve as the stable signal layer within a broader decision workflow.
People are not asking for fewer dashboards because dashboards have no value. They are asking for relief from the moment when a dashboard raises an important question and the only available response is, “We will put in a request.” What is changing is the boundary of the dashboard. A leader should be able to move from a visible metric into governed conversational analysis that exposes the assumptions behind it, the populations and workflows driving it, and the next question no one anticipated when the dashboard was designed.
The future is not dashboard versus AI. It is a layered experience: dashboards for stable signals, conversational analysis for exploration, governed notebooks and applications for deeper work, and validated models for prediction or scenario evaluation. Each layer has a job. Trying to make one tool do all of those jobs creates more complexity, not clarity.
Decision Intelligence Is an Operating Model
Decision intelligence is the operating model for reducing decision latency. It connects trusted data, governed business meaning, analytical and AI capabilities, human expertise, and a defined decision workflow. That description is less magical than much of the market language around AI, but it is far more useful to a healthcare leader who has to own the result.
The distinction matters. A language model can produce a fluent explanation of a chart. But fluency is not the same as understanding how the organization defines an encounter, attributes a referral, calculates contribution margin, or excludes an avoidable day. Without that context, AI can produce a fast answer that is technically plausible and operationally wrong.
A mature decision-intelligence capability helps a leader move through four progressively harder questions:
- What happened? Establish the signal with a governed metric.
- Why did it happen? Explore drivers, segments, relationships, and data quality.
- What could happen next? Use forecasting or scenario methods with explicit assumptions.
- What will we do, who owns it, and how will we know it worked? Connect the analysis to an accountable operational workflow.
Most organizations are reasonably capable at the first question. The clinical, operational, and financial advantage emerges from answering the next three without abandoning trust.
How Databricks Helps Solve the Decision-Latency Problem
Building that trust starts with agreement on what the data means and who has authority to approve each definition. Healthcare metrics are rarely simple. Cost per encounter depends on allocation choices. Referral leakage depends on attribution and timing. Length of stay can be calculated differently for clinical, operational, and financial purposes. The goal is not to erase those legitimate distinctions, but to make each approved definition explicit, governed, discoverable, and fit for its intended decision.
On Databricks, that agreement can be implemented through Unity Catalog semantics, with metric views providing governed, reusable definitions of measures and dimensions across SQL editors, notebooks, AI/BI dashboards, Genie Agents, alerts, and supported external BI tools. Metric views are Unity Catalog securable objects governed through standard privileges. Unity Catalog captures lineage automatically for supported Databricks queries and workloads, while certification signals and agent metadata help people and AI identify authoritative assets and interpret metrics consistently. The organization must still assign accountability: finance for financial definitions, clinical and quality leaders for clinical measures, and operations for the workflows it owns. Data teams implement and steward the technical layer without becoming the default owner of every business decision.
AI/BI dashboards still give leaders the stable view they rely on for regular operating reviews. Genie Agents add a conversational analytical interface, allowing a leader to move from a dashboard signal into follow-up questions using curated data, metric views, business instructions, trusted assets, and example query logic. Depending on the question, Genie can return a natural-language response, a result table, a visualization, and the generated SQL query. Agent authors can review responses, inspect generated SQL, test realistic questions, and use benchmarks and user feedback to improve accuracy over time. Genie should not silently redefine a metric, substitute an unverified interpretation for approved logic, or turn an analytical pattern into a clinical recommendation without appropriate human review and validation.
This is where the broader Databricks platform strategy matters. The advantage is not a conversational feature operating beside the data estate; it is the combination of data engineering, analytics, AI, semantic context, and governance on a common platform foundation. Unity Catalog provides governance and lineage capabilities, Unity Catalog semantics captures governed business meaning, AI/BI provides dashboard and conversational analytical experiences, and the organization’s domain experts supply the context, ownership, and validation that make the answers trustworthy.
Instead of rebuilding logic every time a question comes up, the organization reuses a governed foundation. People and AI work from the same approved definitions, data products, and business context, while preserving the ability to use different certified measures when different decisions legitimately require them.
Learning Speed Is the Real Advantage
Healthcare’s next advantage will not come from producing more analytics alone. It will come from learning speed: the ability to shorten the distance between question and action without weakening accuracy, safety, governance, or judgment. That is the practical promise of decision intelligence.
This operating model is not merely theoretical. 3Cloud has partnered with health systems to build governed, Databricks-native data and analytics capabilities intended to reduce the effort required to recreate definitions and assemble evidence, giving leaders and analysts more time to validate findings, make decisions, and measure outcomes.
Organizations working through these decisions can connect with 3Cloud’s Health and Life Sciences team to identify a starting domain, define metric ownership and evidence standards, assess the current Databricks foundation, and design a governed path from dashboard signals to measurable operational action.
| About the Author
|
Jeff Barnes is a healthcare data and AI leader with more than 20 years of experience translating complex clinical, operational, and financial challenges into scalable analytics and technology capabilities. As Senior Director of Business Advisory Services for Health and Life Sciences at 3Cloud, he focuses on trusted data foundations, responsible AI, healthcare analytics, and the operating models required to turn technology investment into measurable outcomes. |
The Databricks platform capability statements in this article draw on the product documentation listed below. The learning-health-system discussion draws on the cited AHRQ Patient Safety Network perspective. The healthcare operating-model recommendations, illustrative scenarios and timelines, and statements about 3Cloud, a Cognizant company’s experience reflect the author’s professional judgment; they should not be read as Databricks product guarantees, clinical guidance, independently validated benchmarks, or documented client outcomes.
References
- AHRQ PSNet. “Learning Health Systems for Patient Safety” (2025). https://psnet.ahrq.gov/perspective/learning-health-systems-patient-safety
- “AI/BI concepts.” https://docs.databricks.com/aws/en/ai-bi/concepts
- “Unity Catalog semantics and metric views.” https://docs.databricks.com/aws/en/uc-semantics/
- “What is Unity Catalog?” https://docs.databricks.com/aws/en/data-governance/unity-catalog/
- “What is Databricks?” https://docs.databricks.com/aws/en/introduction/
- “Test and monitor a Genie Agent.” https://docs.databricks.com/aws/en/genie-agents/monitor
- “Unity Catalog metric views.” https://docs.databricks.com/aws/en/uc-semantics/metric-views/
- “Agent metadata in metric views.” https://docs.databricks.com/aws/en/uc-semantics/agent-metadata
- “Genie Agents concepts.” https://docs.databricks.com/aws/en/genie-agents/concepts
- “Create and manage a Genie Agent.” https://docs.databricks.com/aws/en/genie-agents/set-up
- “Lineage in Unity Catalog.” https://docs.databricks.com/aws/en/data-governance/unity-catalog/data-lineage
