Measuring a Hand Hygiene Campaign

An infection prevention campaign existed. The measurement did not.

Discipline

Data product design

Domains

Healthcare · AI and Automation

Timeframe

2025 to 2026

Status

Approved in discovery. Ingestion and reporting were handed to the data intelligence team.

What was this project?

Measuring a Hand Hygiene Campaign is a data product design for an infection prevention campaign at a large pediatric health system, covering inpatient, procedural, and defined ambulatory areas.

Hospital acquired infections had risen, and compliance with hand hygiene and appearance standards had fallen at the same time. Those two facts were the reason the campaign existed.

The campaign itself was well built. It named specific behaviours rather than aspirations: hair up, sleeves up, no nail polish or artificial nails, personal devices out of the patient zone, and hand hygiene before and after any device use that could not be avoided. Front line staff had asked for exactly this kind of clarity.

What problem did this solve?

An infection prevention campaign was rolled out across dozens of clinical areas with clear behaviour standards and no mechanism to measure whether any of those behaviours actually changed.

The campaign could say what good looked like. It could not say whether good was happening, where it was not happening, or whether infection rates moved afterward.

That is a specific and common failure, and it is worse than having no campaign. Without measurement, the only available evidence is whether infection rates happen to fall, which arrives months late, aggregates away the locations that need help, and cannot distinguish a campaign that worked from a season that was quieter.

The people affected were the ones with the least room to absorb it. Unit leaders were being asked to improve compliance without being told their own numbers.

What did I observe?

The campaign documentation specified the behaviours in precise detail and contained no baseline, no target, and no defined capture mechanism, which told me the gap was measurement design rather than campaign design.

What I found when I read the source material and the surrounding systems:

• The behavioural content was fully specified and the measurement framing was entirely absent. Nobody had decided what an observation was, who would record one, or what the denominator would be.
• A survey platform was already in use elsewhere in the organization, already had an API and token authentication, and could carry a structured observation form of roughly twenty fields. The capture tool did not need to be built or bought.
• The scope was very wide, spanning inpatient units, procedural areas, and a defined list of ambulatory clinics, with different staffing patterns in each. A single organization wide compliance number would have been true and useless.
• The infection metrics the campaign wanted to move were already defined and owned elsewhere, on established surveillance definitions. Redefining them inside this product would have created a second version of a number that already had an owner.

The other thing I noticed is that these observations record who was observed. That makes the sensitive data here employment data about staff, not protected health information about patients, and those two carry different obligations.

What was my role?

I framed the measurement problem, designed the data product, specified the ingestion and the model, and drew the line around what this product would deliberately not try to prove.

• Read the campaign material and identified that the behaviour standards were complete while the measurement framework was missing entirely.
• Defined the data product as a reference standard plus a lightweight measurement layer, rather than as a dashboard project.
• Specified the observation instrument at field level: the behaviours observed, the setting, the location, the role, the shift, and the date.
• Specified the API ingestion, the authentication method, the response format, and the record key, so the ingestion work could be scoped without a discovery cycle.
• Scoped out the things that did not belong in a first phase, including formal surveillance metric definitions, role based access models, advanced drilldowns, and service level agreements.
• Flagged that observations identify staff, which changes the access model, and raised it as a requirement rather than leaving it to be discovered during build.

I did not build the ingestion, the data model, or the reports, and I did not run the observations. The campaign itself was designed by infection prevention and nursing leadership, not by me. My contribution was making it measurable.

What was the proposed solution?

The proposed system is a structured observation form feeding a scheduled API ingestion into a curated compliance model, reported as two deliberately separate views: compliance by location, and infection rate trend for the same locations.

Compliance is captured as a structured observation rather than a self report. An observer records what was actually seen in a patient room or bay, against the specific behaviours the campaign named, with enough context to attribute the result to a location, a role, and a shift.

The ingestion is scheduled rather than real time. Nothing about this decision cycle needs sub minute latency, and a batch job that runs reliably is worth more than a stream that nobody monitors.

The reporting layer keeps compliance and infection outcomes side by side rather than joining them into a single claim. This is the most important design decision in the product and the easiest one to get wrong.

How was the system designed?

The architecture runs from a bedside observation through the survey platform's API into a scheduled warehouse ingestion, then into a curated model keyed by location, role, and shift that feeds two separate reporting views.

Location, role, and shift are the grain, and that choice is what makes the product useful. A hospital wide compliance percentage tells a unit leader nothing they can act on. The same measure cut by their own location and shift tells them where to be standing on Tuesday morning.

The two output views are drawn as siblings on purpose. Compliance observations and infection rates are placed next to each other so a reader can see both trends, and are not joined into a computed claim that the campaign caused the change.

Why was it designed this way?

The design refuses to claim that improved hand hygiene compliance caused a change in infection rates, because this measurement cannot support that claim and building it as though it could would have been the most damaging thing in the product.

On access: because an observation names the person observed, this dataset is about staff conduct. It needs an access model closer to an employment record than to an operational report, and it should be reported at the level of a location rather than of an individual unless there is a policy reason to do otherwise. I raised that as a requirement in the design rather than leaving it to be found during the build.

How would it be implemented?

The implementation plan is four phases that put a usable compliance baseline in front of unit leaders before any infection trend work begins, because the compliance number is the one they can act on.

1. Instrument and definitions. Build the observation form, agree what counts as one observation, and settle the denominator and the location list. Confirm the access model given that observations identify staff.
2. Ingestion. Stand up the scheduled API pull into the warehouse with completeness and duplicate checks, and confirm the record key behaves as expected across repeated pulls.
3. Compliance baseline. Publish compliance by location, role, and shift, and establish the baseline the campaign never had. This phase is the one that makes the campaign measurable, and it delivers value on its own.
4. Outcome view. Add the infection rate trend for the same locations as a separate view, referencing the existing surveillance definitions rather than restating them.

Formal metric definitions, automated extraction, role based access models, advanced drilldowns, and service level agreements were all explicitly scoped out of this phase. Naming what a first phase will not do is how a first phase stays a first phase.

What impact was expected?

Every figure below is a projection from the design rather than a measured result, and no compliance baseline existed at the time this was written, which is precisely the gap the product was meant to close.

I did not project a reduction in infection rates. Doing so would have contradicted the central design decision of the product, and it would not have been true.

What happened?

The measurement approach was approved in discovery and the ingestion and reporting work was handed to the data intelligence team.

What I contributed was the reframe. The campaign was not short of standards or commitment. It was short of a denominator, and that turned out to be a smaller and much more tractable problem than it first appeared.

I designed and specified it. I did not build it, and I have no measured compliance or infection outcome to report.