Healthcare
Take the paperwork off your care teams.
Agents, data platforms and migrations on Google Cloud for health systems and health plans. A person approves anything that leaves.
Agent workspace · Prior auth queue
An illustration of an agent we build
Queue
- Knee replacementApproved
- Spine MRIPreparing
- Hip replacementWaiting
- Cardiac echoWaiting
Knee replacement
ApprovedReads
- Payer policy
- EHR chart
- Outside faxes
The agent prepares
- Reads the policy
- Checks the chart
- Flags the gaps
Ready for review, with every fact linked to where it came from.
A person decides
UM nurse approves
Packet approved
- Google Cloud Partner
- Databricks Partner
100+
Projects delivered
45+
Enterprise clients
8
Industries served
98%
Client satisfaction
What we build
Start with the work that keeps nurses at a keyboard.
Pick a workflow and watch it run: what it reads, what the agent prepares, and the nurse or reviewer who decides.
Prior authorization packets
Utilization management nurses and surgical schedulers
Builds the packet the payer's policy asks for, and flags gaps while there is time to fix them.
Reads
- Payer policy
- EHR chart
- Outside faxes
The agent prepares · Gemini Enterprise
- Checks each policy criterion
- Links every fact to the chart
- Flags what is missing
Hands over · Prior auth packet
- Policy criteria · 6 of 6 met
- Chart evidence · 15 records cited
- Missing items · 1 surgeon addendum
A person decides · approved
UM nurse approves the packet
Then
Ready for the payer
Built on · Gemini Enterprise · Cloud Healthcare API · Agent Platform
Read every workflow as text
Prior authorization packets
Utilization management nurses and surgical schedulers
The agent reads the payer's policy and the chart, builds the packet the policy asks for, and flags what is missing while there is still time to fix it. Behavioral health and substance use records stay out of the packet unless the patient's consent and your policy allow them.
A person decides: A nurse approves every packet. The payer decides medical necessity.
We measure: Packets ready before the slate locks, nurse time per packet, and denials for missing documentation.
Built on: Gemini Enterprise, Cloud Healthcare API, Agent Platform
Denial appeal drafts
Denials and appeals specialists
For each denial, the agent reads the stated reason, finds the documentation the payer cited, and drafts the appeal with every statement linked to the chart page it came from.
A person decides: A specialist edits, signs and sends every appeal.
We measure: Appeals sent inside the payer's window, specialist time per appeal, and overturn rate.
Built on: Gemini Enterprise, Document AI, Cloud Healthcare API
Referral and fax intake
Referral coordinators and patient access teams
Outside faxes and referrals are read, matched to the right patient, and turned into structured tasks, with the original page one click away. When a fax disagrees with the chart, the agent shows both.
A person decides: A coordinator confirms the patient match before anything is filed.
We measure: Time from fax to scheduled visit, and documents filed to the wrong patient.
Built on: Document AI, Gemini Enterprise, Cloud Healthcare API
Patient message drafts
Nurses and staff who work the portal inbox
Routine portal messages get a draft reply built from the chart and your approved templates, and clinical questions go to the right pool with the context already pulled.
A person decides: A nurse or physician edits and sends every reply.
We measure: Time to reply, and messages each nurse closes per shift.
Built on: Gemini Enterprise, Agent Platform, Cloud Healthcare API
Request review summaries
Health plan utilization management nurses and medical directors
For each incoming request, the agent lays the clinical documentation against the medical policy and shows which criteria the records support, with the page each one came from.
A person decides: A clinician reviews every request, and only your clinical reviewers can deny one.
We measure: Requests decided inside the 72-hour and seven-day windows, and reviewer time per request.
Built on: Gemini Enterprise, Document AI, Cloud Healthcare API
The prior authorization APIs CMS requires
Health plan interoperability and IT teams
The FHIR APIs impacted payers must run by January 2027 for prior authorization, provider access and payer-to-payer exchange, built on the Cloud Healthcare API to the HL7 Da Vinci guides CMS recommends.
A person decides: Your compliance team signs off conformance before each API goes live.
We measure: Conformance test results, API uptime, and requests answered inside the required windows.
Built on: Cloud Healthcare API, Apigee, Cloud Run
A clinical data platform
Analytics, quality and population health teams
EHR, claims, lab and imaging data land in BigQuery through the Healthcare API, de-identified under the HIPAA method your privacy officer chooses, safe harbor or expert determination, before analysts see them, with one definition for each measure.
A person decides: Your data governance group approves each new use of identifiable data.
We measure: Time from question to report, and measures with one agreed definition.
Built on: Cloud Healthcare API, BigQuery, Looker
Clinical systems off aging hardware
Infrastructure and application teams
Analytics, departmental and EHR-adjacent systems move to Google Cloud in waves, each with a tested way back, without breaking the interfaces clinicians use during a shift.
A person decides: Your change board approves each wave and every cutover window.
We measure: Downtime during each wave, and the cost to run against the old estate.
Built on: Google Kubernetes Engine, Cloud SQL, VPC Service Controls
Where patient data goes
Follow a record through your project.
Pick a workflow and follow its data through your project.
Swipe sideways to see the whole drawing.
- Care teamQuestion
- Care agentsGemini Enterprise
- Clinical dataHealthcare API
- Audit logCloud Logging
A reference design we adapt to each provider's systems.
Proof
Work we have shipped.
Healthcare
Moved off a vendor data centre with zero downtime
A U.S. healthcare technology company delivering clinical analytics for providers and hospitals
8 weeks
to own and govern its own infrastructure
Healthcare · Migration · Google Cloud
Read the study
Public Sector
Client onboarding cut from six months to weeks
A government and non-profit health and human services case management platform
80 to 90%
of form onboarding effort automated
Public Sector · Document AI · Google Cloud
Read the study
What is changing
The rules on prior authorization changed this year, and again in January.
Each item links to its public source, so you can forward it to whoever owns the budget.
40
prior authorizations per physician, every week
13 h
of physician and staff time on them, every week
2025
80%+
of large healthcare breaches in 2025 started with hacking or IT incidents
Every new system that touches patient data needs its access designed in.
HIPAA Journal, healthcare data breach statistics (from HHS OCR reports)1 Jan 2026
72 h
for an urgent prior authorization decision, and seven days for a standard one
Payers must also give a specific reason for every denial.
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheetOct 2026
14 of 60
EHR certification criteria removed, AI model cards among them
More of the checking of AI features now falls to the hospital.
Healthcare Dive, ONC final rule cuts health IT certification criteria1 Jan 2027
1 Jan 2027
until impacted payers must run prior authorization APIs
Prior authorization, provider access and payer-to-payer FHIR APIs.
CMS electronic prior authorization overview
Read every item in full
2025
Most large breaches start with hacking.
Hacking and other IT incidents caused more than 80% of the large healthcare data breaches reported in 2025. Every new system that touches patient data has to arrive with its access and logging already designed.
1 Jan 2026
Payers have 72 hours or seven days to decide.
Medicare Advantage, Medicaid and CHIP plans must decide expedited prior authorization requests for items and services within 72 hours and standard ones within seven calendar days, and every impacted payer must give a specific reason for a denial. Drugs are excluded. An incomplete packet now costs both sides time they no longer have.
Oct 2026
EHR certification no longer requires AI model cards.
ONC's HTI-5 final rule removes 14 of 60 certification criteria, including the requirement for AI model cards. More of the checking of AI features now falls to the hospital that uses them.
1 Jan 2027
The prior authorization APIs go live.
Impacted payers must run FHIR APIs for prior authorization, provider access and payer-to-payer exchange. Hospitals and clinicians in MIPS can report an electronic prior authorization measure for bonus points in 2027, and must report it from 2028.
Example: surgical prior authorization
Watch one workflow run end to end.
Wrenfield Health, Ashmere Health Plan and every patient are made up, and the records are synthetic. The agent, its screens and its test results are real.
Read the narration
14 knee replacements are booked for Monday. Every one needs the insurer's approval, and the slate locks at noon today.
Here's the agent we built at CloudMagic, on Gemini Enterprise. I'm signed in as the utilization management nurse, so I'll ask which ones are ready.
That took 11 seconds. 12 are complete. One needs a surgeon's addendum, and one has a gap to close.
The addendum case is Ruth Ellingsen's. Let's open it.
Her outside therapy fax has the year typed wrong, so on paper her therapy happened a year too early. The agent reconciled it from the referral and the fax header, and kept the typed value next to it for the nurse to check.
14 of her records are protected behavioral health and substance use records. The store held them back, and the agent never received them.
Nothing goes to the insurer until a nurse says yes. I'll approve the packet. It's prepared for your team or an integration to submit, and nothing is sent from here.
So how does it get Ruth right? Behind Gemini Enterprise is the engineering most teams skip.
It starts in the chart store. Protected records are filtered out inside the query, so they never leave the store. The agent gets a count, and nothing else.
The insurer's policy is compiled into rules, clause by clause, and a person signs off each version. Every lookback window is checked in code.
Here's Ruth's therapy. Her surgeon's note says 12 weeks. Six visits are in our chart, and 12 are on an outside fax, with the year typed wrong. The referral and the fax header both point to 2026. We keep the typed value and log the correction.
Exceptions are rules too: the policy's kidney exception covers the anti-inflammatory trial, and her labs meet its weight exception.
Her note also claims things the records don't show, and says no joint pain, so it stages an addendum request for the surgeon.
It cites 15 records and checks every date. The packet waits for the surgeon's addendum before anyone submits it.
Now I'm the surgical scheduler, and Monday's list is short a case. Franklin Odum's X-ray is too old, so I'll ask it to override the window.
It won't. No tool here can waive a policy window, for any role, and it records who asked.
Before an agent like this goes live, we test it against a written answer key: 20 synthetic cases, the same Gemini model. The prompt-only version scored 19, 18, 18 and 18 over four runs. It marked Ruth's packet not ready every time, because it believed the typo. Across the 20 charts, it read 42 protected records in every run. Ours got all 20 in four runs, and read none.
Every hospital has the same raw material: insurer policies in PDFs, faxes from outside clinics, notes that copy forward, and records that must stay private. Bring us one workflow, and we'll build the agent on Gemini Enterprise.
The engineering underneath
Try to make it decide.
Pick a request. Watch what the agent does with it, and what lands in the audit log.
As Scheduler
As UM nurse
As CMIO
Prior authorization agent
Signed in as Scheduler
No tool here can approve care. The payer decides medical necessity, and a nurse approves the packet.
Audit log
- refused · approve_care · scheduler
A simulation of the controls in the prior authorization agent from the film above. The real agent, its screens and its test results are in the film.
- Runs inside your own Google Cloud project
- A person approves what the agent prepares
- Every action written to the audit log
- Scored against your past cases before launch
Read the requests and the engineering behind them as text
Scheduler: Approve this knee replacement
Refused. No tool here can approve care. The payer decides medical necessity, and a nurse approves the packet.
UM nurse: Show me her behavioral health notes
Filtered. Those records carry a protected label and are filtered out in the store's own query. Protected records received this run: 0.
UM nurse: Why is the X-ray too old?
Cited. The payer's policy sets an imaging window. The rule cites the clause it came from, in a version a clinician signed off.
Scheduler: Send the packet to the payer now
Waiting for a person. The packet waits in the outbox until a utilization management nurse approves it. Nothing leaves before that.
CMIO: Show the test results
Scored. It is scored against an answer key before go-live. In the film's test it got all 20 cases right in each of four runs.
Protected records filtered in the query
It prevents: Behavioral health and substance use records reaching a model that has no reason to read them. You check it: Each run reports how many protected records the agent received. The answer should be zero.
Payer policies turned into signed-off rules
It prevents: An agent reading a long payer policy differently from one case to the next. You check it: Every rule cites the policy clause it came from, and a clinician signs off each version.
Patient matching you can review
It prevents: An outside document filed to the wrong patient. You check it: Every match shows the identifiers it used and waits for a person when they disagree.
Tested against an answer key
It prevents: An agent that demos well and then misses the cases that matter. You check it: We replay past cases with known outcomes before go-live, and you see the score for every run.
How we start
We begin with one workflow and a fixed fee.
Most health systems start with one queue, such as prior authorization for one service line.
First
A call with an engineer
Bring one workflow and its systems.
Fixed fee
Discovery
A written plan, or a written no.
Day 0 to 30
Build and test
Starts once EHR and data access is approved.
Day 30
One workflow live
On Gemini Enterprise, at a fixed fee.
After
Run it, or hand it over
Your call. The next one reuses it.
We need from you
- A workflow owner
- A few hours a week from the team
- Read access in your project
- Last quarter's cases to test against
- A Google Cloud BAA
What can slow it down
- EHR access requests: filed in week one
- Privacy review: we bring the data flow
- Policy changes: rules are versioned
You keep
- The code, in your repo
- The test set and its scores
- Runbooks and the audit log
- Your Google Cloud project
Read each step in full
A call with an engineer
Tell us the workflow and the systems it touches. A senior engineer replies, usually within one business day, and says plainly if it is not a fit.
A fixed-fee discovery
We sit with the people who do the work, check what data the system can reach, and write down what we would build, how we would test it and what it costs. It ends with a written recommendation, and sometimes the recommendation is not to build.
One workflow live in thirty days
Once access to the systems involved is approved, we put one workflow live on Gemini Enterprise in thirty days, at a fixed fee, scored against your own past cases before anyone relies on it. Data platforms and migrations move in waves, each with a tested way back.
Run it with you, or hand it over
We stay to run and improve it, or your team takes it over with the code, the runbooks and the test set. Either way, the next workflow reuses everything underneath.
What can slow it down, and what we do about it
- EHR interface and access requests, which can queue for weeks. We file them in the first week.
- Privacy and data use reviews. We bring a written data flow your privacy officer can approve.
- Payer policies that change mid-build. Rules are versioned, so a change is an update and a re-test.
Frequently asked
The questions we hear first.
Yes. We build on Google Cloud services covered by Google's business associate agreement, inside your own project, and configure them to help you meet your HIPAA responsibilities. Compliance is shared, so we document every control for your compliance team. Most of a build runs on synthetic or de-identified data, and where our engineers need access to patient data, it is set up under a business associate agreement with you.
No. It assembles the documentation the insurer's policy asks for and flags what is missing. The insurer decides medical necessity, and a nurse approves every packet before anything leaves your hands.
We connect through the interfaces EHRs publish, mainly FHIR R4 APIs and HL7 v2 feeds, into the Cloud Healthcare API in your project. What we can read depends on what your EHR exposes and what your contract allows, so we confirm that in the first week, before anyone writes code.
Often, yes, and we work alongside it. EHR vendors ship features such as drafted portal replies. We build the workflows that cross systems your EHR does not see, such as payer policies, outside faxes and your own data platform, and use the EHR's own tools where they already fit.
Through the route each payer accepts: its portal, fax, an X12 278 request through your clearinghouse, or its FHIR prior authorization API as payers bring those online for January 2027. The agent prepares the packet, and your team or an integration submits it.
They stay in the store. Records carrying a protected label are filtered out inside the store's own query, so the agent never receives them unless the patient's consent and your policy allow it. Each run reports the count, so you can check.
Our teams work from the US, London and Ahmedabad. Access to your data is granted per person, through your identity provider, inside your own Google Cloud project, and every access is logged. If your policy limits where people who see patient data can sit, tell us on the first call and we will say plainly whether we can staff to it.
Before go-live we replay your own past cases, such as last quarter's prior authorizations, score every run against what really happened, and show you the scores. After go-live the same test set runs on every change, and a change that lowers the score does not ship.
You do. The code sits in your repository, everything runs in your own Google Cloud project, and the test set and runbooks are yours. Each step ends with something you keep, so you can stop after discovery with the written recommendation, or after the first workflow.
Yes. It runs on Gemini Enterprise in our own Google Cloud project, against a FHIR store loaded with synthetic patients for a made-up hospital system, Wrenfield Health. The hospital, the insurer and the patients are invented so we can show a whole workflow from start to finish, and no real patient data was used. The agent, its screens and its test results are real.
Tell us which workflow keeps your nurses at a keyboard.
A senior engineer replies, usually within one business day.