Overwatch: The Real-Time Data Layer Jackson Health Already Owned

I worked on this system. Not a case study I read about after the fact, not a vendor pitch deck I picked apart looking for the real story underneath. I helped build it, under the manager who years later sent me the talk that prompted this piece.

The problem

The system is called Overwatch. It was built in-house at Jackson Health System, one of the largest public health systems in the country: six hospitals, two trauma centers, the Miami Transplant Institute, a hundred years of institutional history behind it.

The talk is by George Rosello, Associate Director of Enterprise Application Integration at Jackson, presenting “Real-Time Alerting and Solution Platform” at a 2019 HIMSS/InterSystems event. It’s public. Jackson chose to publish these numbers themselves.

Rosello opens with the line that reframes the whole talk: “somehow we don’t trust ourselves to use the data we created.”

That’s the problem. Not a technology gap. A trust gap. Jackson, like most large health systems, already had an integration engine running (InterSystems HealthShare Health Connect) with nearly every clinical and operational data feed in the building flowing through it. The default response to a new operational problem wasn’t to ask what that data could already tell you. It was to buy an application, or hire outside consultants.

The analysis

Buying an app or hiring consultants both start from the same wrong assumption: that the data needed to solve the problem doesn’t exist yet and has to be brought in. At Jackson it existed already. It was sitting in HealthShare, flowing between the EMR, scheduling, and case management systems. A purchased application would have paid, again, to re-integrate data that was integrated already. A consulting engagement would have built the logic once, billed for it, and walked out the door with the institutional knowledge of how it worked.

Jackson took neither path. A team sitting on top of the integration engine it already ran didn’t have to pay to wire into every clinical and operational feed in the building; that work was done and running. Each new use case was new logic on a pipe that existed already. That’s how Overwatch shipped three unrelated use cases, a subsidy problem, a no-show problem, and a patient safety pilot, off the same platform, each one built in weeks.

The solution

Overwatch was Jackson’s answer to that instinct. Not a new application. No new user interface, no new workflow for staff to learn. It sat on top of the integration engine that was already in place, watched the data flowing through it in real time, and triggered alerts and actions into the applications people were using. Built 100% in-house.

The signature effect Rosello called out explicitly: nobody in the organization had to change how they worked. No new FTEs, no new job function, no retraining. The data was there already. Overwatch just made it act.

The outcome

Three use cases came out of it, and they get more serious as you go.

The subsidy problem

Jackson, like most safety-net systems, absorbs the cost when patients without funded care options use the emergency department as their primary care. Built in January 2018, live in four weeks: Overwatch watched for high-utilizer patients hitting the ED and alerted case managers by text and email the moment it happened, with the service line and location attached, so a case manager could physically intercept the patient during that visit.

It started small: three case managers, a working caseload of about 100 patients, with the platform also tracking post-enrollment adherence, kept appointments, relapse back to the ED, program milestones. In 2018, that reduced net subsidy by more than $2 million. Jackson was projecting to break $6 million in 2019 once case-manager staffing scaled up. That’s not a pilot number. That’s a system paying for itself many times over on data it already had, routed differently.

The no-show problem

Launched April 2018, built in six weeks: Overwatch replaced Jackson’s paper mailer appointment-reminder system with dynamic text and email reminders. It reused data that was already sitting in the EMR scheduling system, so schedulers didn’t change a single thing about how they booked appointments.

The reminders did more than the mailers ever could: an auto-generated photo of the correct parking garage for that specific appointment’s building (Jackson’s campus spans dozens of buildings), localized into the patient’s preferred language. Cost per day for the whole reminder system dropped to $3.10, several times cheaper than the paper process it replaced. No-show rates improved by up to 16% in some areas, a metric that had been flat despite earlier attempts to move it. Jackson was named a 2018 “Digital Edge 50” award recipient, credited to this platform and these two pilots together.

Two use cases, both defensible purely as cost plays. If Overwatch had stopped there, it would already be a strong case for building instead of buying.

It didn’t stop there.

The pilot that had no ROI number yet

At the time of the talk, Jackson was piloting a patient conversation channel built on the same platform: an SMS welcome and check-in message to newly admitted patients in certain units, and a post-discharge SMS survey. Rosello is upfront that there was no return-on-investment figure for this one. Too new, still in pilot.

But he tells the story anyway, because a discharged ED patient answered that post-discharge survey and reported that their symptoms were getting worse. The conversation that followed caught that the patient had turned septic. They were brought back in for life-saving treatment.

That’s the use case I’d put last on purpose. Not because the dollar figures aren’t real, they are. But because the third one shows what the first two were actually proving all along: once you have one owned, real-time layer sitting on top of data you generate, you don’t have to know in advance what it’s going to be worth. You build the pipe once. What flows through it keeps finding value you didn’t budget for. Jackson hadn’t finished pricing this pilot out, and it had already caught something that would have killed someone.

Lessons

Here’s what I want to be precise about, because it’s easy to file this whole story under “AI success story” and it isn’t one. Overwatch ran on real-time rules and modeling. 2018 and 2019. No generative AI, no LLM anywhere in the loop. It didn’t need one. The pattern that made it work wasn’t a smarter model, it was ownership: one team, inside the organization, sitting on top of an integration point that was in place, building logic that acted on data the org had a right to use. If anything, the tooling available now should make that same pattern cheaper and faster to stand up, not the other way around.

And the pattern isn’t healthcare-specific. It’s the same argument I make elsewhere on this blog about field service organizations sitting on fragmented, siloed data across dispatch, inventory, and technician systems: the fix usually isn’t another app on top of the pile, and it isn’t handing the problem to an outside firm. It’s one owned real-time layer built on data an organization generates. Jackson proved that at hospital-system scale, with numbers they were willing to publish under their own name, years before anyone was pitching AI as the reason to try it.

I didn’t read about this pattern somewhere and decide it was compelling. I helped build one.