How We Stood Up a County Preventive Health Incentive Program on Power Platform With Zero PII Storage

The situation

A county public health department had funding, willing healthcare providers, and a clear public health goal: get more residents into annual preventive checkups. What it did not have was a way to run the program.

The department could offer gift cards and provider discounts as incentives. It could sign agreements with local clinics. It could publicize the offer. None of that mattered without a system that could enroll residents, route them to a participating provider, verify that a checkup actually happened, and issue the incentive at the right moment, at the right person, without losing track of anyone in between.

The funding was real. The providers were ready. The program had no operational backbone.

The department came to ExeQut with a constraint that shaped every architectural decision that followed: the platform must not store personally identifiable information. Resident privacy was non-negotiable, and the program could not absorb the regulatory weight of becoming a HIPAA Privacy Rule-scoped data environment in its own right.

The challenge

Several problems had to be solved in parallel:

1. Enrollment without friction. Residents needed a way to sign up that did not require installing an app, creating an account, or remembering a password. Anything heavier than a link would suppress participation, especially in the populations the program most wanted to reach.
2. Privacy by architecture, not by policy. "We promise not to look" was not acceptable. The system itself had to be incapable of holding PII, with sensitive data living only inside the HIPAA-compliant environments of the partner providers.
3. Cross-organization coordination. County program staff, multiple healthcare providers, and the residents themselves all had to operate inside one coherent workflow without ever sharing resident identity across organizational boundaries.
4. Verifiable checkup completion. The county could not issue incentives on the honor system. The platform needed a defensible signal that a qualifying checkup had actually taken place, sourced from the provider, not the resident.
5. Sustainability after handoff. Once the program was live, the county had to be able to maintain and extend it without standing up a custom development team. Anything that required specialized engineering talent to keep running was a non-starter.

The approach

The operating model

ExeQut ran the build as a single coordinated workstream with the county's program owners embedded in design decisions from day one. Provider partners were brought in early enough to shape the verification handoff rather than retrofit it. Governance stayed light: a working session cadence with the county, asynchronous reviews with providers, and a single source of truth for the flow logic so program staff could see exactly what the system did at each step.

The goal was not to deliver a system to the county. It was to deliver a system the county already understood by the time it went live.

The technical architecture call

The defining architectural decision was made in the first week: the platform would not collect, transmit, or store any personally identifiable information. Everything else followed from that.

The architecture decision was simple. If the platform never collects PII, the platform never has to protect it.

The intake flow began in Microsoft Forms, chosen specifically because it removes every barrier between a resident and signup. No app store. No account. No login. A link, a few fields, a submit. Power Automate flows then orchestrated the program lifecycle: signup capture, eligibility logic, provider routing, verification handoff, and incentive issuance. Operational records that did not constitute PII were maintained in Dataverse and SharePoint, and Azure Functions were used selectively where a flow needed logic beyond what the low-code surface could express cleanly. Power BI delivered role-appropriate dashboards so county staff and partner providers could each see program activity from their side of the boundary, without ever seeing the other side's resident detail.

Sensitive data stayed where it already lived: inside the providers' existing HIPAA-compliant environments. The platform's job was to coordinate, not to custody.

Key infrastructure decisions

Two decisions did most of the work in keeping the program defensible.

The first was the no-PII boundary itself. By designing the data model so that resident identity never crossed into the county-operated platform, the program's HIPAA Privacy Rule scope on the Power Platform environment shrank dramatically, and the breach blast radius shrank with it. Power Platform supports HIPAA workloads under a Business Associate Agreement, but the more durable risk reduction is not having to rely on those controls in the first place. The data that is never collected is the data that cannot be breached.

The second was the deliberate choice to keep the build entirely no-code. Custom-coded equivalents of this kind of workflow typically cost meaningfully more to build and noticeably more to maintain. Just as importantly, custom code would have required the county to retain or contract specialized developer talent in perpetuity. A Power Platform build hands the keys back to the program owners.

No-code does not mean low-stakes. It means the county can keep extending the program after we leave.

Deployment and release approach

The program rolled out as a coordinated launch across the county rather than a long pilot, because the operational pieces, intake, routing, verification, and incentive issuance, only prove themselves end to end. ExeQut staged the flows in a non-production environment, walked the county and partner providers through the full lifecycle with synthetic cases, and cut over once each role had observed its own view of the workflow behaving as intended. Post-launch support focused on tuning the flow logic as real volume came through, not on rebuilding pieces of the platform.

The outcome

The county now operates a live preventive health incentive program with a coherent end-to-end lifecycle: residents enroll through a Microsoft Forms link, get routed to a participating provider, complete a qualifying checkup, and receive their incentive, all coordinated through a workflow that holds no PII at any point.

What changed because of the build:

• 50,000 submissions came through the platform in the first 3 months of operation. The frictionless link-based intake produced participation volume the program could plan against.
• Residents enroll without friction. No app, no account, no login. A link is the entire user experience, which is what a public health program needs when the populations it most wants to reach are the ones most easily deterred by signup overhead.
• Privacy exposure is structurally reduced. Because the platform stores no PII, the county is not operating a new HIPAA Privacy Rule-scoped data environment, and the breach surface that would otherwise come with one does not exist.
• County and provider staff work inside one coordinated view. Each role sees what it needs to see and nothing it should not. Cross-organization handoffs are explicit and auditable rather than improvised over email.
• The program is self-sustaining. Because the build is no-code, county program staff can adjust eligibility logic, routing rules, and reporting without standing up a development team or re-engaging specialized engineering talent.
• The public health thesis is intact. Behavioral incentive programs in preventive health have consistently produced meaningful lifts in checkup and screening attendance in the peer-reviewed literature, and the program is structured to capture that effect without the operational drag that usually attends it.

What we took from it

A few lessons from this engagement generalize beyond public health, and they are the ones a federal or county program manager is most likely to find useful.

1. Architect privacy into the data model, not into the policy. Promises about handling PII responsibly are necessary but not sufficient. Designing a system that is structurally incapable of holding PII is what actually shrinks regulatory scope and breach exposure. Decide where sensitive data will live before you decide what the platform will do.
2. Treat enrollment friction as a program risk, not a UX preference. Every additional step between an eligible resident and a completed signup compounds. For programs that depend on broad participation, the lowest-friction intake surface available is usually the right answer, even if it looks unimpressive on a slide.
3. Pick the build approach that the client can still operate after handoff. A custom-coded solution that the program office cannot maintain is a future dependency, not a deliverable. No-code platforms are often the right call not because they are cheaper to build but because they are cheaper to keep running.
4. Design the cross-organization workflow first, then the technology. Programs that span agencies, providers, and partners fail at the boundaries between them, not inside any one organization. The handoffs are the system. Get those right and the platform choices get easier.
5. Use governance proportional to the build. A program of this scope did not need heavy ceremony. It needed program staff in the room when architecture decisions were made, providers involved before integration was scoped, and a single visible source of truth for the flow logic. Keep the overhead in line with the work.