A medical billing company we worked with in 2025 had a problem that sounds small and costs hours every day: patient documents arrived as Egress secure emails. Every one meant the same routine. Spot the email, copy the access code, open the secure message in a browser, log in, download each attachment, then read the documents and retype the patient details into the billing workflow. It was medical billing document automation waiting to happen, with one large obstacle in the way.
Egress is a staff-facing encryption tool. It is designed for a person to click a link and read a message, not for software to collect it. There is no simple developer door to walk through. Our own guide to whether AI can read and act on encrypted emails says exactly that.
So the client asked a fair question: can the whole routine be automated anyway, from inbox to structured patient record? We built a minimum viable product (MVP) in one to two weeks to find out. The answer was yes, with conditions that matter. This case study covers both.
| Metric | Result |
|---|---|
| Build time | One to two weeks |
| Manual stages automated | 3: inbox, Egress secure portal, document extraction |
| Document formats handled | PDF, Word, Excel, CSV, PowerPoint, text and Markdown, plus images |
| AI used | Google Gemini for images and scans, OpenAI GPT-4o-mini for field extraction |
| Duplicate protection | Every file fingerprinted, so nothing is processed twice |
| Data used | Test and sample documents only, no real patient data |
| Outcome | Proof of concept: the route works, and we know what production needs |
Why Secure Email Is the Bottleneck in Medical Billing Automation
Most writing about medical billing automation starts at the claim: coding, scrubbing, submission, denials. Our own claims and billing automation guide covers that ground. But for many billing teams, the slowest step comes before any of it. The documents a claim depends on arrive locked inside secure email.
That is a good thing for patients. Clinical letters, referrals and supporting documents should be encrypted in transit, and tools like Egress make that easy for the sender. In the UK, Egress is the official encryption provider for NHSmail traffic to external addresses, which we cover in our guide to encrypted email for UK medical practices.
The cost lands on the receiver. Every secure message is a small manual ritual, and a billing team can receive dozens of them a day. None of that time goes into billing. It goes into opening things.
The Brief: Inbox to Patient Record, Without a Person in the Middle
The client wanted one connected flow:
- Notice new emails in their Microsoft Outlook mailbox.
- Open any Egress secure messages among them and collect the attachments.
- Read every attachment, whatever the format, including scans and images.
- Pull out the patient and medical details the billing team needs, consolidated into one record per patient per document.
- Store everything somewhere the team could search and query.
Because it was an MVP, the goal was not a polished product. It was to prove, quickly and cheaply, whether the hard part (step two) could be done at all, before anyone spent money on the rest.
What We Built: Three Components, One Pipeline
The MVP had three parts. Each one replaced a manual stage, and each could be tested on its own.
New emails were fetched from Outlook through Microsoft Graph and attachments were saved. Egress secure emails were opened by a browser robot that entered the access code and downloaded the attachments. Every file then went through the document pipeline, which skipped duplicates, extracted text, read images with Gemini, extracted medical fields with GPT-4o-mini, combined them into one record per patient per document, and stored the results.
1. The inbox reader
The first component connects to the client's Outlook mailbox through Microsoft Graph, Microsoft's official way for software to read a mailbox with permission. It signs in through Microsoft's own login, checks for recent emails, and saves any attachments.
This was the easy part, and that is the point. Outlook has a documented, supported door for software. When a tool offers one, automation is predictable. In our experience, when a business's key tools have an API like this, integration succeeds well over 90% of the time, and it was quick here too.
2. The secure email robot
Egress was the hard part. With no developer door for this workflow, the only way in was the window: the same web reader a staff member uses.
So we built a browser robot using Playwright, an open-source tool for automating a real web browser. It takes the access code from the email, opens the Egress secure message, logs in where needed, reads the message and downloads every attachment. It does exactly what a person does, step by step, just without the person.
This is the part the MVP existed to prove. And it worked.
3. The document pipeline
Once the files were out, the third component turned them into usable data:
- Reading every format. PDFs, Word documents, spreadsheets, CSV files, PowerPoint, plain text and Markdown, plus common image formats.
- Reading images and scans with AI. Google's Gemini vision model read images inside documents and standalone scans, with instructions written specifically for medical documents.
- Extracting structured fields. OpenAI's GPT-4o-mini pulled out the medical details from the text, then a consolidation step merged fragments into one clean record per patient per document, instead of scattered partial results.
- Never processing a file twice. Each file gets a digital fingerprint (a hash), so a document that arrives twice is recognised and skipped.
- Storing the results in a Supabase database, with the original text also indexed for search.
- A simple screen for the team to upload files manually and manage the storage tables, built with Gradio.
The Three Ways Into a Secure Email Tool, Compared
The real lesson of this MVP is not about our code. It is about a decision every practice and billing company with a secure email tool will face once they want automation. There are three ways to get the content out, and each has a different cost.
| Route | How it works | Staff click needed? | Breaks when the vendor changes its pages? | Ongoing upkeep |
|---|---|---|---|---|
| Staff opens it | A person clicks, reads and forwards | Yes | No | None, but it costs staff time every day |
| Vendor API or SDK | Software decrypts the message directly, if the vendor offers this | No | No | Low |
| Browser automation | A robot uses the same web reader a person does | No | Yes | Higher: needs monitoring and occasional fixes |
The vendor route is the clean one, but only if the vendor offers it for your account. Developer-focused encryption products such as Virtru are built for exactly this. Staff-facing tools generally are not, and switching or adding a product is a bigger decision than an MVP.
Browser automation is how we got this MVP working with the client's existing Egress setup, with no change on the senders' side. It is a window, not a door. It works, and sometimes it is the only option, but it is more fragile by nature. If Egress moves a button or renames a field, the robot can lose its way until someone updates it.
If the encryption vendor offers an API or SDK for your account, use it. If not, decide whether the volume justifies automation. If it does, browser automation works with the existing account but needs monitoring because it breaks when the vendor changes its pages. If volume is low, keep the manual open step as a deliberate human checkpoint.
What Did Not Go Perfectly, and What It Taught Us
A case study that only lists wins is an advert. Here is the honest version.
Through the same web reader a person uses. It breaks when Egress changes its pages, so production needs monitoring.
On test documents. Real billing files need field-level accuracy checks before anyone trusts them.
The least valuable part. The billing team needed fields, not search.
The browser route needs looking after. It did its job in the MVP. But a system that depends on someone else's web pages needs an alert the moment those pages change, and someone ready to fix it. That is a running cost, and it belongs in any production budget from day one.
Search was the least valuable thing we built. Alongside the structured records, the MVP indexed every document so the team could search by meaning. That follows a pattern we now warn clients about: a database, an AI model connection, documents loaded into a search index and a screen on top. That combination is easy to build and easy to demo. But a billing team does not need to chat with its documents. It needs the right fields, correct, in the right place. The value of this MVP was in the two parts that are hard to fake: getting the documents out of Egress, and turning them into per-patient records. If we built it again, the search layer would come last, if at all.
Extraction needs measuring, not trusting. AI models do not give exactly the same answer twice, even with identical input. On test documents the extraction looked good, but "looked good" is not a standard for billing. Production needs every field checked against documents the team has already processed by hand, a confidence level for each field, and a human review queue for anything uncertain.
Every document is untrusted input. A system that reads documents from outside senders can be tricked by hidden text: instructions in white-on-white type or tiny fonts that a person never sees but an AI reads. In a billing context, the AI must only ever extract data, never take instructions from the content it reads.
Secrets belong in a vault, not alongside the code. An MVP is built for speed, with credentials in a local configuration file. Production needs a dedicated service account, secrets kept in a proper secrets manager, and regular key rotation.
What Production Would Need
The MVP proved the route. Here is what we would add before real patient data goes anywhere near it.
- 01Private or approved AI models
Models on infrastructure the client controls, or a cloud service under a signed data agreement.
- 02A dedicated service account
Its own Egress login and mailbox, credentials in a secrets manager, cleared with the account owner.
- 03Accuracy checks per field
Measured against documents the billing team has already processed by hand.
- 04A human review queue
Low-confidence fields go to a person before they reach billing.
- 05Monitoring on the browser step
An alert the moment the Egress page changes and the robot can no longer find its way.
Private or approved AI models. The MVP sent test documents to OpenAI and Google. Real patient documents should only go to an AI service under a signed data agreement covering your jurisdiction, or, better for many billing companies, to models running on infrastructure you control. When the model runs on your own server, there is no AI vendor in the data's path at all. The compliance question becomes simply where that server sits: in the UK or EU for GDPR, or under your own control in the US for HIPAA. We cover that trade-off in cloud AI vs local AI for medical practices and showed it in practice in our private OpenMed deployment.
A dedicated Egress account, cleared with the owner. The robot should log in as its own service user, never as a staff member, with the account owner's agreement and in line with the vendor's terms.
A safe test environment. Mock emails and sample documents that mirror the real ones, so changes are proven before they touch live mail.
Field-level accuracy targets agreed with the billing team before launch, so "working" has a number attached.
Human Hours vs Automation: Opening Secure Emails by Hand
The fair comparison is not "automation versus nothing." It is automation against the billing administrator who opens every secure message today. The MVP ran on test data, so we have no measured volumes from this client. Here is the comparison built from stated assumptions instead, so you can swap in your own.
The assumptions.
- By hand, per secure message: about 3 minutes to spot it, copy the access code, log in and download the attachments, and about 5 minutes to read the documents and key the patient details into the billing workflow. 8 minutes in total.
- After automation, per message: about 1 minute of human time, reviewing the fields the system flags as uncertain. That assumes the production version with a review queue, not the MVP.
- Volume: we show 10, 25 and 50 secure messages a working day, over 250 working days.
- Value of an hour: $24.16, the US median wage for medical records specialists from the Bureau of Labor Statistics (May 2024, $50,250 a year divided by 2,080 hours). UK readers can substitute their own rate; the hours do not change.
| Secure messages a day | By hand, per year | Cost by hand | After automation, per year | Cost after automation |
|---|---|---|---|---|
| 10 | ~333 hours | ~$8,050 | ~42 hours | ~$1,010 |
| 25 | ~833 hours | ~$20,130 | ~104 hours | ~$2,520 |
| 50 | ~1,667 hours | ~$40,260 | ~208 hours | ~$5,030 |
At 25 messages a day, that is about 730 hours a year handed back, close to half of one full-time administrator's working year, spent opening and retyping rather than billing.
The other side of the ledger. A proof of concept like this fits our fixed-scope pilot from $5,000. The production version costs more, and the browser step needs monitoring and occasional fixes whenever Egress changes its pages. At low volumes (a handful of secure emails a day), the manual route can honestly be cheaper. The case strengthens quickly as volume rises.
What the numbers leave out. Speed and accuracy. Documents processed the day they arrive mean claims go out sooner, and every retyped field is a chance for a typing error that can cause a rejected claim. Neither is priced here, and both often matter more than the wages. Run your own figures through our hire versus automate calculator.
Is This Kind of Automation Right for You?
This approach fits if:
- Your team receives secure emails every day and spends real time opening them.
- The documents feed a structured process like billing, coding or intake.
- Your secure email vendor has no developer route for your account, or switching vendors is not an option.
- You can accept a component that needs monitoring, in exchange for removing the manual step.
It is not the right first step if you receive a handful of secure emails a week, or your vendor already offers an API or SDK you can use. In that case, use the door. Our guide to AI document processing covers where extraction is reliable when the documents are already within reach, and AI email triage for medical practices covers the inbox side.
The Competitor Pulse Check
| Factor | How we approached it | A typical approach |
|---|---|---|
| Starting point | Prove the hardest step first, in one to two weeks | Build the whole platform, discover the blocker in week seven |
| No API available | Browser automation, with its fragility stated upfront | Declare it impossible, or hide the fragility |
| Patient data in the MVP | Test and sample documents only | Real data sent to public AI services to make the demo look real |
| What counts as the product | Correct fields per patient | A chat-with-your-documents demo |
| Path to production | Private or approved models, field accuracy checks, human review | The MVP renamed as version one |
What Medical Billing Document Automation Costs
A focused proof of concept like this one fits our fixed-scope pilot, from $5,000, because it has one clear question to answer: can the hard step be automated? Taking it to production, with private models, accuracy checks, a review queue and monitoring, is a larger build, priced before you commit. Our pricing page sets out the tiers, and our AI automation development service explains how a pilot is scoped. For healthcare-specific builds, see our healthcare AI development service.
Frequently Asked Questions
Can you automate Egress secure emails?
Yes, but usually not through a developer API, because Egress Protect is a staff-facing tool designed for a person to click and read. In this MVP we used browser automation to open secure messages through the same web reader a person uses, enter the access code and download the attachments. It works with an existing account, but it needs monitoring because it can break when the vendor changes its pages.
What is medical billing document automation?
It is software that collects the documents a billing process depends on, such as clinical letters and supporting paperwork, reads them, and pulls out the patient and medical details into structured records, so staff stop retyping them. The hardest part is often getting the documents out of secure email in the first place.
Can AI extract data from scanned medical documents?
Yes. In this MVP, Google's Gemini vision model read images and scans with instructions written for medical documents, and OpenAI's GPT-4o-mini extracted structured fields from the text. For billing use, every field should be measured against documents already processed by hand, with uncertain fields sent to a person for review.
Is it safe to send patient documents to ChatGPT or Gemini?
Only under a signed data agreement that covers your jurisdiction, such as a business associate agreement in the US or a data processing agreement under UK or EU GDPR, and only for services the agreement actually covers. Many billing companies are better served by models running on infrastructure they control. This MVP used test and sample documents only.
How long does it take to build a secure email automation MVP?
This one took one to two weeks, covering the Outlook inbox reader, the Egress browser robot and the document pipeline. Taking it to production takes longer, because private models, accuracy testing, a review queue and monitoring all need building and proving.
Why use browser automation instead of an API?
Because sometimes there is no API for your account. Browser automation lets software use a system the way a person does, through its web pages. It is a legitimate option when no developer route exists, but it is more fragile and needs more maintenance than an API, so it should be monitored and agreed with the account owner.
Want This for Your Billing Team?
If your team spends part of every day opening secure emails and retyping what is inside them, we can tell you in one call which route fits your setup, and whether it is worth automating at all. Book a free strategy call and bring a sample of the documents you receive, with patient details removed.