Work we’re proud of.
Three case studies from our healthcare work: a real-time data platform built on Google Cloud, a patient intake CRM with instant insurance verification, and an AI pipeline that reads intake documents so staff don’t have to. Client details are anonymized to protect confidentiality, but the problems, the engineering, and the results are real. Sound like a problem you have? Book a free consultation.
A real-time clinical data platform, built from zero
The problem: a home healthcare company’s most important data was scattered across systems that had never spoken to each other. Financials lived in QuickBooks. Clinical records were split across two EMRs, Epic and AdvancedMD. And the most time-sensitive data of all — readings from the devices in patients’ homes: dialysis machines, weight scales, blood pressure cuffs — was effectively locked inside those devices. A reading that should have changed a care decision could go unseen for days. The company had no cloud infrastructure of its own and no unified picture of any single patient.
What we built
- The company’s entire Google Cloud infrastructure, stood up from scratch and defined as code, with security, networking, and access control designed for PHI from day one
- An end-to-end patient data model that unifies financial, clinical, and device data into one record per patient
- Live, streaming pipelines for device telemetry alongside automated ingestion from QuickBooks and both EMRs, so every source lands in one warehouse, continuously
- Real-time reports and analytics for the people downstream: physicians see vitals and trends per patient, care coordinators get worklists and out-of-range alerts
How we did it. Device readings stream through Pub/Sub and Dataflow into BigQuery the moment they’re taken, while EMR and financial data flow in through automated connectors on tight schedules. On top of the warehouse sits a tested, documented data model that resolves each patient to a single identity across billing, clinical, and device systems, so a doctor looking at a dashboard sees one coherent story, not three conflicting ones. Everything — projects, IAM, networking, pipelines — is managed with Terraform, so the whole platform is reproducible and auditable.
Challenges we solved along the way
- Unreliable home connectivity. Devices in patients’ homes drop offline and send late or duplicate readings. We made ingestion idempotent and built late-arrival handling, so the data heals itself instead of double-counting or losing readings.
- One patient, three identities. The same person appeared differently in Epic, AdvancedMD, and QuickBooks. We built patient-identity resolution into the model so every downstream report is truly per-patient.
- PHI everywhere. Nearly every table touched protected health information. Encryption, least-privilege access, and audit logging were designed in from the first commit, not retrofitted.
Stack Google Cloud (Pub/Sub, Dataflow, BigQuery, Cloud Run) · Terraform · HL7/FHIR & API integrations for Epic and AdvancedMD · QuickBooks API · tested, documented data models · live dashboards.
The outcome: doctors and care coordinators now see device readings minutes after they happen instead of days later, and the whole company — clinical and financial — runs on one live source of truth that didn’t exist before we started.
An intake CRM that verifies insurance while the patient is still on the phone
The problem: patient intake ran on phone calls, paper, and memory. Demographics and insurance details were captured by hand and verified later — sometimes days later — through payer portals and hold music. When coverage problems surfaced, they surfaced at the worst possible time: after the visit, as a denied claim. Scheduling lived apart from intake, and leadership had no live view of how many patients were in the pipeline or where they were getting stuck.
What we built
- A custom scheduling app and CRM purpose-built for patient intake: demographics, insurance, referrals, and care needs captured once, in one place, with PHI and PII handled properly
- Real-time insurance verification through Availity using the X12 270/271 eligibility transaction — coverage confirmed in seconds, while the patient is still on the line
- Integrated scheduling, so a verified patient goes straight onto the right provider’s calendar in the same workflow
- Live dashboards over the intake funnel, schedules, and utilization that update as intake happens, not at the end of the week
How we did it. The moment insurance details are captured, the system fires an X12 270 eligibility request through Availity and translates the 271 response — a format built for clearinghouses, not humans — into a plain-language answer on screen: active or not, plan details, copays, and flags that need attention. Staff never leave the intake screen, and nothing gets scheduled on unverifiable coverage. Underneath, the application enforces role-based access to PHI, encrypts sensitive fields, and writes an audit trail for every change.
Challenges we solved along the way
- Payers don’t agree on what a 271 looks like. Every insurer fills the same transaction differently. We built a normalization layer that turns messy, payer-specific responses into one consistent coverage answer staff can trust.
- Real-time can’t mean fragile. When a payer or the clearinghouse responds slowly, intake keeps moving — the check completes in the background and flags the record rather than freezing the call.
- PHI-safe by design. Building a CRM that holds insurance, demographic, and health information meant treating access control and auditability as product features, not afterthoughts.
Stack Custom web application (CRM + scheduling) · Availity clearinghouse integration · X12 270/271 real-time eligibility · role-based access control & field-level encryption · audit logging · live analytics dashboards.
The outcome: insurance is verified in seconds during the first phone call instead of days later, coverage problems get caught before the visit instead of at billing, and the intake team works from one live queue with leadership watching the pipeline in real time.
AI document intake that reads, matches, and files — so staff don’t retype
The problem: every new patient arrived with a stack of documents — insurance cards photographed on phones, faxed lab results, referrals, and pages of doctor notes pulled from the EMR. Staff read each one, retyped the details into the database, and filed it against what they hoped was the right patient. It was slow, it pulled skilled people into data entry, and a single mistyped member ID could turn into a denied claim weeks later. The narrative doctor notes were the worst of it: long, dense, and too time-consuming to properly read at intake.
What we built
- An AI document pipeline on Google Vertex AI that classifies each incoming document, then extracts the structured fields that matter: member IDs and plan details from insurance cards, values from lab reports
- Automatic summarization of doctor notes from the EMR, turning pages of narrative into a concise clinical summary attached to the record
- Patient matching that correctly identifies who each document belongs to in the database — across misspellings, nicknames, and partial information — before anything is filed
- Automatic record updates with a human in the loop: high-confidence extractions apply directly; anything uncertain lands in a review-and-approve queue instead of guessing
How we did it. Documents flow through a staged pipeline: classify the document type, run OCR and field extraction tuned to each type, validate the results against business rules, then match the document to a patient using name, date of birth, and member ID with confidence scoring. Only a confident match updates the record; a borderline one is routed to a person with the evidence laid out side by side. Summaries are grounded strictly in the source document, and the system never silently overwrites verified data — every automated change is logged and reversible.
Challenges we solved along the way
- Real-world image quality. Insurance cards arrive blurry, cropped, and photographed at angles. Preprocessing plus confidence thresholds meant the system knows when it read something well — and asks a human when it didn’t.
- The wrong patient is worse than no answer. In healthcare, misfiled data is a safety issue. We tuned matching to be deliberately conservative: uncertain matches always stop for review rather than guessing.
- Making AI summaries trustworthy. Clinical staff won’t use summaries they can’t verify. Ours cite and stay grounded in the source note, so a reader can always check the summary against the original.
Stack Google Vertex AI (document processing, OCR & LLM summarization) · confidence-scored patient matching · human-in-the-loop review queue · EMR integration · full audit trail of every automated change.
The outcome: intake documents are read, matched, and filed in minutes with no retyping, the right data lands on the right patient record, and clinicians open a concise summary instead of pages of notes — with people reviewing the judgment calls instead of doing the typing.