Article September 25, 2026

by Jimmy Zinizopoulos, Dynamics 365 Customer Engagement Architect

From four systems to one foundation: a healthcare Power Platform story

A behind-the-scenes look at how Project Courage consolidated disconnected workflows into a Power Platform foundation designed for secure, traceable behavioral health operations.

Service

Microsoft Digital Transformation

Industry

Healthcare

Behavioral health organizations don't choose system sprawl, they inherit it, one reasonable decision at a time. This is what it took to trade four disconnected tools for one foundation that can prove what happened, not just record it.

A requirement arrives with a deadline. A form has to be captured, a signature has to be collected, a report has to be submitted, or a handoff has to happen between clinical and administrative teams. The team solves the immediate problem with the tool available that week.

Then another requirement arrives. Then another. Four years later, there are four places where patient information lives, four ways to answer a basic operational question, and four different versions of “the process” depending on who you ask.

That is the reality behind many healthcare modernization projects. It accumulates through practical decisions made under pressure. In a regulated organization, the hard part of consolidation is rarely moving the data. The hard part is proving what happened to it.

This idea sits at the center of our Community Summit North America session, From four systems to one foundation: A healthcare Power Platform story. The session is based on Project Courage, a behavioral health organization that moved from disconnected workflows to a fully digital platform built with Microsoft Power Platform. Read about the outcomes of moving Project Courage.

How four systems happen

Clinical documentation may begin on paper because the forms are specialized, the intake process is sensitive, and the team already knows how to work that way. A separate tool may be introduced for signatures because consent, acknowledgment, and approval need to happen quickly and reliably. Spreadsheets may become the operational layer because leadership needs visibility before a formal reporting system exists. Email may become the handoff mechanism because clinicians, administrators, billing teams, and leadership all need to coordinate around the same patient journey. Each piece makes sense in isolation.

The problem appears when the organization tries to manage the full lifecycle across all of them. One team knows where the latest assessment is stored. Another knows whether the form was signed. Someone else knows whether the patient’s status changed. Reporting depends on manual updates. Audit preparation depends on institutional memory.

In a regulated healthcare environment, that accumulation matters because information is never just information. It carries obligations around privacy, access, retention, reporting, and accountability.

The hidden cost is reconciliation. Without a shared client identity, teams have to reconstruct information across paper, spreadsheets, email, EHR, lab, billing, and referral systems. This makes it harder to confirm who signed what, track a client’s status, keep reports current, and answer leadership’s most important question: Can we see a trusted and current picture of every client we serve?

Clinical records lived in the EHR, toxicology results lived in lab software, billing data lived elsewhere, and referral information lived in a Word document. Each system answered a different question, but none could answer the question that leadership cared most about: Can we see a trusted and current picture of every client we serve?

Why a fifth system rarely fixes it

The obvious answer is often to buy a specialized behavioral health platform. In many cases, that is a reasonable conversation. Specialized tools can be strong at the clinical core. They may provide predefined forms, workflows, terminology, or reporting structures that match a specific provider model.

The challenge is that regulated operations rarely live only inside the clinical core. The difficult requirements often sit at the edges. How does a signed document move into the right record? How does leadership see operational performance without asking staff to maintain a second reporting layer? How does the organization demonstrate audit readiness without creating a parallel compliance process?

A fifth system can improve one part of the operation while leaving the surrounding work untouched. The result can be yet another place where information lives.

The platform argument becomes important at exactly this point. The value of a platform is not that every process becomes generic. Healthcare workflows are too specific for that. The value is that specialized business logic, automation, reporting, document generation, security, and governance can be designed around a shared foundation.

For Project Courage, that foundation was built across eight agile sprints, as our case study describes. No two organizations need the same architecture. What they need is to treat the surrounding obligations as part of the design from the start, not bolted on after.

The requirement that changes the design

In a regulated organization, workflows are designed to perform tasks and provide evidence that they were completed correctly. That single requirement changes the design.

It changes where the audit trail lives, how permissions are modeled, and how documents are generated, signed, stored, and retrieved. It changes It also changes reporting, because the dashboard is only as trustworthy as the data lifecycle behind it.

Every one of those decisions, where data lives, who can access it, how it's tracked, is a governance decision. In Power Platform terms, that means governance is not only about who can create apps or flows. It's what determines whether the system can support privacy, accountability, and operational control at the same time.

Power platform security also has to be designed around real working conditions. A clinician, an administrator, a supervisor, and an executive may all need access to patientrelated information, but they do not need the same access. The system has to reflect those boundaries clearly. Access has to support the work without exposing more than necessary.

This is why Microsoft Dataverse matters in these conversations. In a regulated solution, the value is not only having a database. It is having a structured foundation where data relationships, security, business logic, and reporting are designed together.

None of this is theoretical. Where does the source of truth live? How does the system prove that a step occurred? What happens if a user has access to one part of a record but not another? How does the organization avoid building a beautiful app that becomes impossible to audit later?

I'll walk through these questions in my Community Summit North America session in Nashville this October.

The clinical spine

At Project Courage, one of the most important architectural decisions was defining a clinical backbone that could support the entire treatment lifecycle. Rather than building isolated applications for assessments, treatment planning, progress documentation, and discharge activities, the team established a shared Dataverse model centered on four concepts: lead generation and intake, client treatment episodes, treatment documentation, and financial administration. That structure created a consistent lineage for client information from the first interaction through treatment completion, so every document, assessment, consent, progress note, and clinical outcome could be associated with a single treatment journey instead of existing as a disconnected artifact.

Building the model was only part of the solution. The platform also had to enforce consistency automatically, and several reusable patterns emerged during implementation: configuration-driven plug-ins that replicated parent values into child records to simplify document generation, automated creation of auxiliary records that eliminated repetitive manual data entry, and risk scoring mechanisms that turned clinical responses into standardized indicators used throughout intake. These patterns reduced administrative effort while keeping clinical documentation accurate and audit-ready.

What the foundation made possible

In healthcare environments, documents are not simply outputs. They are evidence, and every treatment plan, consent form, assessment, and supervisory review must be traceable, attributable, and retrievable. Document automation was designed as a lifecycle rather than a feature: generate from structured clinical data, produce a PDF from the system of record, capture client or supervisor signatures, and archive the final document in a governed repository. The goal was not simply faster production, but documents that could withstand scrutiny months or years later.

Where the tradeoffs get uncomfortable

There is an unflattering truth in regulated solution design: heavy customization is sometimes how you satisfy an auditor, and it is also how you make the platform more expensive to change two years later.

A clean, standard process is easier to maintain. A highly specific workflow may be easier to defend in an audit. A plugin may give more control and consistency for a critical step, at the cost of speed to change later. A flexible user interface may feel better to the team, until accessibility requirements constrain it earlier than expected.

Accessibility is especially important in healthcare. It is a legal and operational requirement, not a polish item added at the end. If teams wait until user acceptance testing to think about accessibility, they have usually waited too long.

This is where solution design becomes judgment rather than configuration. The hard decisions are rarely solved by choosing one tool and applying it everywhere. They are solved by understanding the workflow, the risk, the user experience, the compliance requirement, and the long-term cost of change. That is the part of the work I enjoy most.

Join us in Nashville