DEV Community: Christopher Gainus

Migrating a Healthcare BI Platform Without Breaking Clinical Reporting

Christopher Gainus — Sun, 09 Aug 2026 13:29:30 +0000

Every morning at a Medicare Advantage primary care organization, clinical leaders open dashboards. They check appointment fill rates, no-show trends, AWV completion progress, care gap closures, and panel coverage metrics. Those numbers drive the daily huddle. They decide which patients get called, which providers need support, and which clinics are behind.

If those dashboards go down, even for a day, operations feels it immediately. Scheduling decisions get made on gut feel. Care gap outreach loses its targeting. The quality team flies blind.

So when I decided to replace our legacy BI platform with a custom analytics platform, the constraint was not technical. It was operational. I had to migrate the entire reporting stack across five clinics, roughly 30 providers, and over a hundred daily users without a single day of reporting gaps.

We completed the sunset with zero reporting gaps. Here is how.

The Core Principle: Dual Run, Not Switch-Over

The biggest mistake in BI migrations is the switch-over approach. You build the new platform, test it, pick a cutover date, and turn off the old one. In healthcare, that approach fails because you always discover something you missed after cutover. A dashboard that nobody mentioned but someone uses every Tuesday. A metric calculation that worked differently in the old platform. A filter that the clinical team depends on but never documented.

I used dual run instead. Both platforms ran in parallel for the entire migration period. Every report that existed in the legacy platform had to exist in the new platform, produce the same numbers, and pass user validation before the legacy version was even eligible for sunset.

This costs more in the short term. You are maintaining two platforms, two data pipelines, and answering questions from two sets of dashboards. But it eliminates the risk of discovering a missing report after you have already turned off the old system. In healthcare, that insurance is worth the cost.

Starting with the Metric Layer

The reason most BI migrations produce different numbers is that the metric definitions live in the reporting layer. Each dashboard calculates the metric slightly differently. When you rebuild the dashboard in the new platform, you have to reverse-engineer the calculation, and you get it wrong.

I solved this by moving metric definitions into a governed semantic layer before the migration. Instead of calculating "AWV completion rate" inside a Tableau workbook, the metric is defined once in a dbt semantic layer. The BI platform, whichever one it is, reads from that semantic layer. The calculation lives in one place.

This means the migration was not about rebuilding calculations. It was about pointing the new platform at the same governed metric definitions. If the old platform and the new platform both read from the same semantic layer, they produce the same numbers. That is the whole game.

The semantic layer has over 500 models. It includes governed metric registries, automated data contracts, and column-level definitions. When a KPI changes, the contracts, seeds, and metric views all update together. This prevents the silent breakage that happens when someone changes a definition in one place but not in the downstream reports.

Migration in Priority Order, Not All at Once

I did not try to migrate everything simultaneously. I categorized every report by criticality and migrated in waves.

Wave 1: Operational spine. The reports that clinical operations depends on every morning. Appointment fill rates, no-show rates, cadence metrics, next-visit projections, AWV completion. These went first because they had the highest validation priority and the most users depending on them.

Wave 2: Quality and care gap reporting. HEDIS measures, care gap closures, quality metric performance. These are important but have different cadence. They are reviewed weekly or monthly, not daily. The slightly lower urgency gave more validation time.

Wave 3: Specialty and program dashboards. Heart program monitoring, referral management, transitional care management. These are domain-specific and have smaller user bases, which means fewer validation cycles but also lower risk if timing slips.

Wave 4: Ad hoc and legacy reports. Reports that one person uses, or that have been superseded by better versions in the new platform. Many of these were retired rather than migrated.

Each wave followed the same process: build in the new platform, validate against the old platform number-for-number, get user sign-off, then mark the old version for sunset.

Embedded AI Dashboards

One of the reasons for the migration was to move beyond static reporting into interactive, AI-assisted analytics. The new platform includes embedded AI/BI dashboards that let users ask questions in natural language and get answers grounded in the same governed metric layer.

This is where the semantic layer pays off a second time. AI dashboards are only as good as the metric definitions they query. If the AI can ask "what is our AWV completion rate for the south clinic this month?" and get an answer grounded in the governed definition, the result is trustworthy. If it is calculating on the fly from raw tables, it will hallucinate.

By front-loading the semantic layer migration, I gave the AI dashboards a solid foundation. The AI features were a benefit of the new platform, but they worked because the metric governance was already in place.

The Sunset: Proving Zero Gap

The sunset itself was the final validation. I did not turn off the legacy platform until every user confirmed they were working exclusively in the new platform and every report had been validated.

I tracked sunset eligibility per report. Each report had a status: building, validating, validated, sunset-ready, sunset. No report moved to sunset-ready until the user who owned it confirmed the numbers matched and the new version met their needs.

The legacy platform was turned off only after every report was either sunset-ready, migrated, or intentionally retired. And even then, I kept the legacy data available for read-only historical comparison for a transition period, because someone always asks "what did this number look like last year in the old system?"

What I Would Do Differently

The migration worked, but there are things I would adjust:

Document the undocumented reports earlier. Every organization has shadow reports that nobody officially owns but somebody uses. I found several of these late in the process. An earlier inventory would have caught them sooner.

Involve the clinical users in validation sooner. The IT team can validate that the numbers match, but only the clinical users can validate that the report is actually usable in their workflow. Number-matching is necessary but not sufficient.

Budget more time for the semantic layer. It was the highest-value work in the migration, but it was also the most time-consuming. If you are planning a BI migration, start the semantic layer work before you think you need it.

The Takeaway

BI migrations in healthcare fail when they are treated as technology swaps. They succeed when they are treated as metric governance projects with a technology component. The new platform is the visible deliverable, but the semantic layer is what makes it work.

Build the governed metric layer first. Dual-run both platforms. Migrate in priority waves. Validate with the users who actually depend on the reports. And do not turn off the old system until you can prove there are zero gaps.

In healthcare, clinical operations does not have time for you to figure out the reporting after cutover. Get it right before you make the switch. The dual-run approach costs more upfront. It saves you from the one thing you cannot afford: a clinical team making decisions on missing or wrong data.

Catching Vendor Access Risk Before It Becomes a HIPAA Finding: SIEM Detection for Healthcare Tenants

Christopher Gainus — Sun, 09 Aug 2026 13:29:24 +0000

I got an alert on a Saturday. A Cloud Solution Provider technician based in Canada had assigned Owner-level permissions at the subscription scope to a foreign-tenant group in our Azure environment. The activity itself was legitimate break-fix work. The access pattern was not.

Standing Owner-at-subscription access for a vendor principal violates the HIPAA Security Rule's minimum-necessary standard. It also creates an attribution problem: when a shared foreign-group principal performs an action in your tenant, you cannot tie that action to a specific individual without the vendor's cooperation. If their tenant is compromised, the attacker has the same standing access as their technicians.

This is not a hypothetical risk. It is the daily reality of running a healthcare cloud environment with vendor partnerships. CSP partners, managed service providers, and SaaS vendors all need some level of access to your tenant. The question is not whether to allow it. The question is how to detect when that access exceeds what is necessary and how to tighten it before an auditor finds it for you.

I built a detection pattern in Elastic SIEM that does this. Here is what it looks like.

The Problem with Vendor Access

Most healthcare organizations have at least one CSP partner managing licensing, billing, or infrastructure in their Microsoft tenant. The traditional access model is DAP, Delegated Access Privileges, which grants the partner tenant broad administrative access. The partner's technicians authenticate through their own tenant and operate under a shared group principal in your environment.

This creates three specific problems:

Over-privileged access. A technician who needs to reset a license does not need Owner-level access to the entire subscription. But DAP gives standing access at whatever scope was initially configured, and that scope tends to be broad because nobody wants to file a ticket every time a vendor needs to do something.

Attribution gaps. When actions are performed through a foreign-group principal, your audit trail stops at the group level. You can see that "ForeignGroup" assigned a role, but you cannot see which human being in the partner organization performed the action. HIPAA Security Rule 164.312(a)(2)(i) requires unique user identification. A shared group principal does not satisfy that.

Blast radius. If the partner's tenant is compromised, the attacker inherits whatever standing access the partner has in your environment. Broad DAP access means a compromise of a vendor tenant becomes a compromise of your production resources.

The Detection Pattern

The first thing I did was build a detection rule in Elastic SIEM scoped specifically to foreign-group and B2B guest write operations in the production resource group. This is tighter than the generic Azure RBAC rule that Microsoft ships. The generic rule fires on any role assignment change, which creates noise from legitimate administrative activity. My rule fires only when a foreign-tenant principal performs a write operation in the resource group that holds PHI-bearing workloads.

The rule triggers on three signals:

Role assignment changes by CSP technicians. When a partner technician assigns an administrative role, especially at subscription scope, the alert fires. The severity is based on the role assigned. Owner at subscription scope is high. Contributor at resource-group scope is medium. Reader is informational.

Service principal creation by partner technicians. CSP partners sometimes create service principals to automate their work. A service principal with broad Graph API permissions is a persistent access path that survives outside the partner's interactive session. Every new SP gets flagged for review.

Cross-tenant access from new geographies. If a partner technician signs in from an IP range that does not match their usual location, the alert fires. This catches both compromised credentials and unauthorized outsourcing of work to contractors the vendor has not disclosed.

What Happens When the Alert Fires

When the detection rule triggers, the alert lands in Elastic with the full context: which principal, what action, what scope, what IP, what timestamp. From there, the workflow is:

Triage. Is this expected partner activity? Most of the time, yes. A technician is doing legitimate work. But the alert documents it, which is the point. In a HIPAA audit, you need to show that you are monitoring vendor access and that you have a process for reviewing it.

Scope assessment. If the access is broader than necessary, it gets tightened. I migrate the partner from standing DAP access to GDAP, Granular Delegated Admin Privileges, with least-privilege roles scoped to the smallest resource group possible, with a maximum duration and an approval workflow.

Permission audit. I enumerate every role assignment and every resource held by the foreign-group principal. Anything that is not justified gets removed. For service principals, I document the Graph API permission set and revoke anything that is not essential.

Conditional Access enforcement. I require MFA and named-location conditions for all CSP-partner sign-ins. No exceptions. If the vendor cannot meet those requirements, they do not get interactive access.

The Cross-Tenant Audit Pipeline

Detection is only useful if the logs are flowing. One of the first things I verify after deploying a new detection rule is that the relevant log source is reaching Elastic.

For vendor access monitoring, that means Entra ID cross-tenant access activity logs. These logs capture when a B2B guest or foreign-group principal performs an action in your tenant. I run a sample query after deployment to confirm that partner events are showing up. If the pipe is broken, the detection rule is useless and I need to fix the ingestion before the rule means anything.

Why This Matters Beyond One Alert

That Saturday alert was not a security incident. It was a configuration drift. A partner technician needed to do work, used the access they had, and created a standing permission that exceeded what they needed. That happens constantly in cloud environments. It is not malicious. It is just how people work when the path of least resistance is a broad permission scope.

The detection pattern catches that drift in real time instead of discovering it during an audit or after a breach. It creates a documented review trail for every vendor action in the production environment. And it gives you the ammunition to push vendors toward least-privilege models because you can show them exactly what access they are using and what they are not.

The Takeaway

If you run a healthcare cloud environment with vendor partnerships, you need vendor access detection in your SIEM. The generic rules that cloud providers ship are not specific enough. You need rules scoped to your production resource groups, tuned to the access patterns of your specific partners, and backed by a log pipeline that you have verified is actually working.

The HIPAA Security Rule does not care whether your vendor is the one who over-privileged themselves. It cares whether you knew about it and what you did to fix it. Build the detection. Verify the pipeline. Document the review. That is how you turn a vendor access risk into a routine operational practice instead of an audit finding.

AI Voice Agents for Patient Outreach: Closing Care Gaps at Scale Without Burning Out Your Staff

Christopher Gainus — Sun, 09 Aug 2026 13:28:42 +0000

A Medicare Advantage primary care organization with five clinics and roughly 30 providers has a permanent problem. There are always patients who are overdue for their annual wellness visit, patients who have fallen off their expected visit cadence, and patients with no next appointment on the books. At any given time, that list can run into the thousands.

The traditional approach is to hand a spreadsheet to the patient experience team and say "start calling." That burns people out. It is also impossible to keep up with. You end up prioritizing by gut feel, calling the same patients repeatedly, and missing the ones who actually need outreach most urgently.

I built a different system. It classifies every patient who needs outreach by urgency, routes them to either an AI voice agent or a human scheduler based on complexity, and tracks outcomes so we can measure what actually works. Here is how the triage layer works.

The Patient-Level Episode Engine

The first problem is that a patient can appear on multiple lists at the same time. They might be overdue for an AWV, off their visit cadence, and have an open referral. If you treat those as separate outreach tasks, you end up calling the same patient three times in a week about three different things. That is a terrible patient experience and a waste of staff time.

So I built a scheduling engine that collapses those categories into patient-level episodes. Instead of looking at individual care gaps, it looks at the whole patient. What is their current status? When was their last visit? What is their expected cadence? Do they have a next appointment?

The engine classifies every patient episode into one of three urgency tiers:

STAT. The patient needs outreach immediately. This might be a patient with a time-sensitive clinical need, a care gap that is about to close for the measurement period, or someone who has been unreachable for an extended time and is at risk of disengaging entirely.

Urgent. The patient needs outreach soon but not today. This is typically a patient who is off their expected cadence and needs to be brought back in within the current cycle.

Routine. The patient needs a standard outreach touch. Annual wellness visit reminders, cadence check-ins, general engagement.

The classification runs in Salesforce. The data comes from the analytics platform, which computes visit cadence, AWV completion, referral status, and attribution from the data lakehouse. Salesforce is the action layer. The analytics platform is the intelligence layer.

Routing to AI or Human

Once a patient episode is classified, the system routes it to the right channel. This is where the AI voice agent comes in.

I use a multi-agent AI voice platform for outbound calling. The voice agent handles the routine and many urgent episodes. It calls the patient, confirms their identity, offers to schedule an appointment, and books it directly into the EHR scheduling system. If the patient has questions that go beyond scheduling, the call can be transferred to a human.

The human scheduling team handles the STAT episodes and any complex cases. A patient who has been non-engaged for months, someone with a complicated referral situation, a patient who has previously refused scheduling. Those get a human call because they require judgment, empathy, and the ability to adapt the conversation in real time.

This split is the key. The AI voice agent is not replacing the human team. It is clearing the routine volume so the humans can focus on the cases that actually need human attention. Before this system, the scheduling team was spending most of its day on routine reminder calls. Now those are automated, and the humans handle the work that requires a person.

The Communication Rules

Patient outreach in healthcare is not a free-for-all. There are rules, and getting them wrong creates compliance risk.

One communication per patient per week. The outreach engine enforces this. If a patient has been contacted about one initiative this week, they do not get a second contact about a different initiative until next week. This respects the patient's time and keeps us compliant.

Priority framework. When multiple initiatives compete for the same patient, the priority framework decides which one goes first. High-acuity clinical needs take top priority. Annual wellness visits with a 60-day warning window come next. Then off-cadence outreach. Then routine engagement.

Consent and preference. Every outreach respects the patient's communication preferences and consent status. The system checks consent before any contact attempt. If a patient has opted out of a channel, the system does not use it. Period.

Channel escalation. The system tries the patient's preferred channel first. If that fails, it escalates to the next channel in the hierarchy. Portal message to SMS to email to phone call. The goal is to reach the patient, but to do it on their terms.

Self-Scheduling as a Recovery Path

One of the highest-impact additions was automated self-scheduling recovery. When a patient cancels an appointment and does not reschedule in the same interaction, the system automatically sends a self-scheduling link through their preferred communication channel. The link directs them to a scheduling workflow that limits options based on scheduling rules, shows only eligible providers and appointment types, and respects cadence-based scheduling logic.

This sounds simple, but it addresses a real operational problem. Before this, a cancellation triggered a manual outreach workflow. A staff member would notice the cancellation, add the patient to a call list, attempt outreach, and hope to reach them. That process took days and lost appointments. The automated recovery path delivers the scheduling opportunity instantly, at the point of cancellation, when the patient is most likely to act on it.

Measuring What Works

The system tracks every contact attempt and outcome. Communication sent, delivery status, link engagement, appointment scheduled, appointment completed. It breaks outcomes down by channel, by clinic, by appointment type, and by initiative.

It also tracks the comparison between AI and human scheduling. This is not about proving one is better than the other. It is about understanding which channel works for which type of patient and which type of episode. Some patients respond better to a human voice. Some prefer the efficiency of an AI agent that can book a slot in 90 seconds without putting them on hold. The data tells us where each channel adds the most value, and we adjust routing accordingly.

The Takeaway

Patient outreach at scale is fundamentally a triage and routing problem. You need to know who needs outreach, how urgently, and through what channel. Then you need to execute consistently and measure the outcomes.

AI voice agents are not a replacement for your patient experience team. They are a force multiplier. They handle the volume that would otherwise overwhelm your staff, and they do it with a consistency that humans physically cannot maintain over thousands of calls. But the triage layer, the classification, the routing rules, the compliance guardrails, those are where the real engineering work happens. The voice agent is just the last mile.

If you are thinking about AI patient outreach, start with the triage engine. Get the classification right. Define your communication rules. Build the consent and preference checks. Then plug in the voice agent. The agent is the easy part. The architecture around it is what determines whether it actually works.

Autonomous Code Review in Healthcare: How AI Agents Ship PRs Without Breaking Production

Christopher Gainus — Sun, 09 Aug 2026 13:28:39 +0000

I run AI agents that write code for a healthcare data platform. They pick up tasks from the backlog, write the code, add tests, open a pull request, respond to automated code review findings, and push fixes until the PR is clean. Then they stop and wait for me to merge.

That last sentence is the important one. The agents never merge their own work. No autonomous merge to the main branch. Ever.

If you work in healthcare technology, you know why that matters. We operate under HIPAA, our data pipelines feed clinical dashboards, and a bad deploy can break the metrics that providers rely on during morning huddles. So the idea of an AI agent pushing code straight to production sounds insane. But the idea of an AI agent doing the repetitive 80% of development work and then handing off to a human for the final call? That is practical. And it is what I actually do.

The Architecture

I have an autonomous agent running on Hermes Agent. It works off a task queue. When it picks up a task, it follows the same workflow a human developer would:

Pull latest from the default branch
Create an agent/* branch
Write the code, keep the diff small and single-purpose
Add or update tests
Validate in a non-prod environment only
Open the PR with a description that links the Jira issue, explains the change, and calls out the risk

Every one of those steps matters. The branch naming convention (agent/*) is how I filter agent PRs from human PRs in the pipeline. The small-diff rule keeps reviews fast. The non-prod validation rule is non-negotiable because we are in a regulated environment.

The Quality Gate

This is where it gets interesting. I use CircleCI for continuous integration, and I added CodeAnt as an AI-assisted quality gate. CodeAnt reviews every PR automatically, whether it came from a human or an agent.

The agent's job is to resolve every Critical and High finding from CodeAnt before it reports back to me. If CodeAnt flags a Medium or Low that is reasonable and does not expand scope, the agent fixes that too. The agent pushes fixes iteratively until the PR is clean.

This creates a tight loop: the agent writes code, CodeAnt reviews it, the agent fixes what CodeAnt found, CodeAnt reviews again. Most of the time, by the time I look at the PR, the obvious problems are gone. I am reviewing the architecture decision, not catching missing null checks.

I also run a contract ledger that validates specific changes. If someone removes a dbt model, renames a column, or changes a data contract, the ledger catches it and the CI gate fails. This matters because in healthcare data engineering, a renamed column can silently break a downstream clinical dashboard that nobody notices for three weeks. The contract ledger prevents that class of problem for both human and agent PRs.

Why Human-in-the-Loop Is Not a Limitation

People hear "human must approve merges" and think the system is not really autonomous. That is the wrong framing. The autonomy is in the execution. The human checkpoint is in the judgment.

Think about what a human developer actually does in a healthcare shop. They spend time understanding the compliance context, checking whether a change touches PHI, making sure the data contracts are intact, and deciding whether the approach is right. The coding itself, the test writing, the linting, the back-and-forth on review comments, that is the time-consuming mechanical work. That is what the agent owns.

The human owns the decision. The agent owns the delivery.

This split also means I can give the agent work that would otherwise sit in the backlog for weeks because nobody has bandwidth. Test coverage improvements. Schema documentation. Incremental refactors. Bug fixes that are important but never urgent enough to prioritize. The agent clears that queue, and I review the output in minutes instead of spending hours writing the code myself.

The Hard Gates

I defined hard rules for the agent that are non-negotiable. These are not soft preferences. They are the boundary of its autonomy:

Never modify production databases or schemas. Read-only against prod.
Never expose PHI in code, tests, logs, commit messages, or PR descriptions.
Never commit secrets.
Never rewrite shared history or force-push to protected branches.
Never grant or widen access permissions on its own.

Everything else, the agent owns. The gates are the boundary, not a checklist that pauses every action. The agent makes reasonable decisions within those boundaries and only escalates when something hits a gate or genuinely needs my input.

What This Actually Looks Like in Practice

On a typical day, I come in and there are one or two PRs waiting from the agent. I read the PR description, check that the tests pass, scan the diff for anything that touches PHI or data contracts, and either merge or leave a comment. The whole review takes five to fifteen minutes per PR.

If CodeAnt still has unresolved findings, the PR is not ready and I do not look at it. The agent knows to resolve those first. If the change is too big or the approach is wrong, I close the PR and explain why. The agent picks up the next task.

The result is that the engineering team ships more work without growing headcount. The agent handles the mechanical delivery. I handle the judgment calls. And nothing reaches production without a human making a deliberate decision to put it there.

That is the model. Not autonomous merges. Autonomous delivery with human gates. In healthcare, that distinction is the whole game.

Salesforce Health Cloud Implementation: Real Costs and Timelines (2026)

Christopher Gainus — Thu, 06 Aug 2026 16:55:14 +0000

Salesforce Health Cloud costs between $250 and $500 per user per month in licensing alone. Add implementation, integration, and customization, and a 50-clinician deployment runs $200,000 to $600,000 over the first 18 months.

I have scaled Health Cloud from 5 users to 250 in a Medicare Advantage primary care organization. Here's what drives the cost, where the money goes, and how to avoid the mistakes that inflate it.

What you're paying for

Salesforce licenses: Health Cloud is an add-on to Sales Cloud or Service Cloud. You need the base license plus the Health Cloud add-on. Budget $250-$500/user/month depending on your Salesforce edition and negotiation.

Implementation labor: This is where costs vary wildly. A straightforward Health Cloud deployment with standard objects and minimal integration runs $75,000-$150,000. A complex deployment with custom care coordination workflows, EHR integration, and Agentforce automation runs $250,000-$500,000.

Integration work: Health Cloud doesn't replace your EHR. It sits alongside it. You need integration via FHIR R4 APIs, HL7 feeds, or middleware (MuleSoft is the Salesforce-preferred path, at additional cost). Integration is typically 30-40% of total implementation cost.

Data migration and cleanup: Moving patient data from legacy systems into Health Cloud requires deduplication, field mapping, and validation. Budget $25,000-$75,000 depending on data quality.

Ongoing administration: Salesforce needs a dedicated administrator. Whether that's a full-time employee ($90,000-$130,000/year) or a fractional arrangement depends on your org size.

What drives cost up

Custom objects instead of standard ones. Health Cloud ships with a data model designed for healthcare: patient profiles, care plans, care teams, assessments, clinical alerts. Organizations that build custom objects instead of using the standard model add 40-60% to their implementation cost and create upgrade headaches for years.

Underestimating data quality. If your legacy system has duplicate patient records, incomplete insurance data, or inconsistent naming, those problems surface during migration. I've seen data cleanup consume 25% of a project budget because nobody scoped it.

Layering Agentforce before the basics work. Salesforce's AI agent product is powerful but it's a layer on top of a functioning Health Cloud deployment. If your care coordination workflows aren't clean, Agentforce will surface the messiness, not fix it. Get the foundation working first.

Fixed-bid contracts on undefined scope. If a systems integrator gives you a fixed price before understanding your org, they've priced in risk they don't understand. You'll either pay for their overestimation or eat their underestimation. A paid discovery phase ($10,000-$25,000) prevents both outcomes.

What a realistic timeline looks like

I tell clients to expect 4-9 months from kickoff to go-live for a mid-size deployment:

Weeks 1-4: Discovery, requirements, data model validation
Weeks 5-12: Configuration, custom development, integration development
Weeks 13-20: Integration testing, user acceptance testing, data migration
Weeks 21-36: Training, pilot, staged rollout

Anyone promising go-live in under 4 months is either skipping discovery, skipping testing, or deploying out-of-the-box Health Cloud with zero customization. The last option is fine if that's what you need. The first two are not.

How to control cost

Use the standard data model. Salesforce designed Health Cloud's schema for healthcare workflows. Customize fields and page layouts, not the underlying structure. This keeps your implementation faster and your upgrade path clean.

Run a paid discovery phase. Spend $15,000-$25,000 to understand your integration surface, data quality, and workflow requirements before committing to a number. This sounds like added cost. It saves 2-3x its price in scope changes during implementation.

Prioritize integrations. Not every integration needs to be live on day one. Phase your EHR integration, your analytics integration, and your patient portal. Get the clinical workflow working, then layer on the adjacent systems.

Hire a Salesforce architect, not just a developer. Architecture decisions made in the first three weeks of a project determine whether your implementation costs $150,000 or $400,000. An architect costs more per hour and saves more per project.

US implementation cost benchmarks

Based on rates I see in the market for US-based Salesforce Health Cloud architects and consultants:

US architect: $200-$300/hour
US senior consultant: $150-$200/hour
Offshore developer (through a US firm): $100-$150/hour
Offshore developer (direct): $50-$90/hour

The rate differential between US and offshore is real, but healthcare implementations require someone who understands HIPAA, clinical workflows, and compliance. Offshore development can work for well-specified configuration tasks. It should not own your architecture decisions.

If you're evaluating Health Cloud or in the middle of a deployment that's off track, that's the work I do. PumaTech handles Salesforce Health Cloud consulting, implementation, and integration for healthcare organizations.

What Is a Fractional CTO? (And When You Actually Need One)

Christopher Gainus — Thu, 06 Aug 2026 16:48:12 +0000

I take on a small number of fractional CTO clients through PumaTech. If your organization needs hands-on technology leadership without a full-time hire, reach out.

Is AI HIPAA Compliant? A Practical Guide for Healthcare Organizations (2026)

Christopher Gainus — Thu, 06 Aug 2026 16:47:27 +0000

When a clinic administrator asks "is ChatGPT HIPAA compliant?", the honest answer is no by default. Not because the technology can't handle it. Because compliance depends on configuration, contracts, and what data you feed it.

I've spent the last three years building AI systems for a Medicare Advantage primary care organization. Here's what I've learned about which tools you can use with PHI, which ones require a BAA, and which ones will get you fined.

HIPAA compliance is not a property of software

HIPAA doesn't certify products. It regulates how covered entities handle protected health information. A tool is "HIPAA compliant" when:

You have a signed Business Associate Agreement (BAA) with the vendor
The vendor agrees to safeguard PHI per HIPAA Security Rule requirements
You configure the tool to not retain or train on your data

A product can have every security certification in the industry and still produce a HIPAA violation if your staff paste patient names into it without a BAA in place.

Which AI tools have signed BAAs (as of 2026)

I'll be specific here because vague answers are what get clinics in trouble.

Microsoft Azure OpenAI: Yes. Microsoft offers a BAA through their Online Services Terms. Azure OpenAI does not train on your data by default. This is the most common path I see for healthcare organizations that want GPT-4 class models.

Google Cloud Vertex AI (Gemini): Yes. Google Cloud offers a BAA and will sign one for Vertex AI. Gemini data is not used for training when accessed through Vertex AI.

Anthropic Claude (via AWS Bedrock): Yes. AWS offers a BAA for Bedrock. Claude models accessed through Bedrock are covered. Claude accessed through the consumer website is not.

OpenAI ChatGPT: Not by default. The consumer ChatGPT product does not have a BAA. OpenAI does not offer a BAA for ChatGPT as of mid-2026. If you need GPT-4 for healthcare work, use Azure OpenAI instead.

Otter.ai: No BAA available. People search for this constantly (110 searches/month for "is Otter AI HIPAA compliant"). The answer is no. Do not use Otter for meetings where PHI is discussed.

Fireflies.ai: No BAA available. Same situation.

Plaud.ai: No BAA available.

Fathom: No BAA available as of mid-2026.

Granola: No BAA available.

The pattern: note-taking and transcription AI tools almost universally lack BAAs. This is a gap in the market, and it's why clinics keep asking.

How to deploy AI with PHI safely

The architecture I use in production:

Option 1: Azure OpenAI with a BAA. Route API calls through a backend proxy that strips identifiers before sending prompts. Configure Azure to disable data retention and training. Monitor usage logs for PHI leakage.

Option 2: Private LLM deployment. Run an open-weights model (Llama, Mistral) on infrastructure you control. No data leaves your network. No BAA needed because no third party processes the data. The tradeoff is higher operational cost and you need someone who can manage the infrastructure.

Option 3: LiteLLM routing to HIPAA-covered endpoints. Use LiteLLM as an API gateway that routes requests to Azure OpenAI or AWS Bedrock (both BAA-covered). LiteLLM handles the routing, rate limiting, and fallback. Your application talks to one endpoint. The data stays within BAA-covered infrastructure.

What actually gets clinics fined

It's almost never the AI tool. It's the workflow.

A clinician pastes a patient's medication list into ChatGPT to check for interactions. That's a PHI disclosure to a vendor without a BAA. The tool didn't fail. The process did.

I've seen this happen at organizations with otherwise strong compliance programs. The fix is not better AI. It's blocking access to non-BAA AI tools on work devices, providing a sanctioned alternative (Azure OpenAI proxy), and training staff on what they can and cannot type into an AI prompt.

Questions I get asked most

"Can I use Claude for clinical notes?"

Through the consumer website, no. Through AWS Bedrock with a BAA, yes. The model is the same. The compliance posture is entirely different.

"Is Gemini HIPAA compliant?"

Through Google Cloud Vertex AI with a BAA, yes. Through gemini.google.com, no. 20 people per month search this exact question. The distinction matters.

"Do we need an AI governance committee?"

Not a formal one on day one. But you need a named owner, a written policy on approved tools, and a vendor evaluation checklist that covers BAA terms, data retention, subprocessor disclosures, and breach notification windows.

Bottom line

The question isn't whether AI is HIPAA compliant. It's whether your deployment of it is. Microsoft, Google, and AWS all offer BAA-covered AI services that can handle PHI. The consumer tools you've heard of (ChatGPT, Otter, Fireflies) do not.

If you're a healthcare organization figuring out which AI tools you can actually use, that's the work I do. PumaTech builds and deploys HIPAA-compliant AI systems, data platforms, and Salesforce Health Cloud integrations for healthcare organizations.