Workflow software

Turn a repeated healthcare workflow into software your team will actually use

We build internal tools, workflow products and integrations for providers, billing firms and health-tech founders. When a feature moves toward diagnosis or treatment, we say so early, because that work needs a quality system and regulatory specialists.

Book a discovery call

Short answer

What is healthcare product development with AI?

It is the process of turning a repeated healthcare workflow, such as referral intake or denial follow-up, into a working software tool. It covers discovery with the people who do the work, a narrow first release, evaluation of any AI features, secure integrations and a clear line between administrative software and regulated medical device software.

The problem

Problems this service solves

A spreadsheet runs a revenue process

Referral tracking, denial worklists and authorization status often live in shared sheets with no audit trail. When the person who built the logic leaves, the logic leaves too.

Off-the-shelf tools fit the demo, not the workflow

Generic software does not know that a referral without a date of birth goes to a specific queue. Staff end up retyping between systems.

The first AI feature has no test

Teams add a summarizer or classifier, try three examples and ship it. Nobody knows how often it omits a detail or what happens when it is wrong.

The regulatory line shows up late

A feature that starts as scheduling help can drift into recommending a treatment. Discovering that after launch means rework or a product that cannot be sold as designed.

A founder has an idea and no build path

A first version that operators can try is stronger evidence than a prototype. It also needs honest guidance on what it may claim.

Context

Why this is harder in healthcare, and where it opens up

What makes it hard

A prior authorization packet for an MRI asks for different documents than one for a knee replacement, and the software has to handle both.
Inputs arrive as faxes, PDFs, portal messages and phone notes, so extraction needs a review queue for unmatched or low-confidence items.
Interoperability is uneven. FHIR, the standard for exchanging health data through APIs, does not promise complete or correctly matched records.
Hosting and contracts carry legal weight: Texas SB 1188 requires covered electronic health records (EHRs) to be maintained in the US or a US territory from 1 January 2026, and a vendor handling protected health information (PHI) for a covered entity can be a business associate.
Regulatory status turns on intended use and claims, not on whether a product is called a scribe, an assistant or an admin tool.

Where the opportunity is

A narrow tool that removes one retyping step is more likely to be used from day one, which earns trust for the next release.
Structured reasons, outcomes and timestamps give you reporting generic tools lack, such as days in accounts receivable by payer.
One major EHR vendor has said builder tools for health systems will be more widely available in 2027, so a good scope first checks what you already license.
For founders, a pilot used by a real operator answers the questions buyers raise about security, evaluation and workflow fit.

How it works

The mechanics, in order

01
Capture
Documents and messages enter from fax, email, portal or forms. The original file is stored unchanged with its source and time, so any later question can be traced.
02
Interpret
Plain rules handle required fields and routing tables. AI reads messy text, classifies documents and drafts summaries, which is established for bounded tasks. Software that acts across systems on its own is still emerging, so it is not where we start.
03
Check
Confidence thresholds, identity matching and validation rules decide what proceeds. Anything unmatched, ambiguous or urgent goes to a person.
04
Review
A user sees extracted fields beside the source, approves or corrects them, and sees why an item was flagged. Every correction is logged.
05
Act and record
Approved work writes to the system of record through scoped permissions, and a dashboard shows volume, exceptions and cycle time.

Human + AI

What AI does, and what people own

AI speeds up building and testing, but inside the product it is also the part most likely to be wrong in unexpected ways. People define the problem, set the boundary and review the outputs.

AI handles

Draft user stories, interface options and test cases from discovery notes for the team to correct
Generate synthetic documents and edge cases to probe an extraction feature
Assist developers with routine code, which engineers review and test like any other code
Run evaluation sets and summarize error patterns by category
Inside the product, read messy text, classify documents and draft outputs for a user to approve

People decide and review

Operators and clinicians define the workflow, the exceptions and what a good output looks like
A named product owner decides what ships and what stays out of scope
Regulatory and clinical safety specialists decide whether a function is a medical device
Security and privacy leads approve hosting, access controls and agreements
End users review and sign off AI outputs, and their corrections feed the next evaluation

What we build

What is included

Discovery and scoping

Workflow mapping with the people who do the work, a first-release definition and an explicit out-of-scope list.

Internal tools and dashboards

Worklists, status trackers, queues and reporting built around your process and data.

Document and data workflows

Intake of faxes, PDFs and forms with extraction, patient matching and review queues.

AI feature design and evaluation

Prompts, retrieval, guardrails, test sets and acceptance thresholds agreed before launch.

Interoperability and APIs

FHIR and vendor APIs with scoped permissions and audit logs, coordinated with integration work.

Security, hosting and handover

Access control, logging, hosting location, business associate agreement (BAA) or data processing terms, runbooks and a named owner.

Use cases

Examples from healthcare operations

Illustrations of how this work looks in practice. They describe workflows, not client results.

Referral intake workbench

Reads incoming requisitions and referral letters, extracts patient and test details, suggests a match and routes unmatched items to a person. The source image stays beside every extracted field, which suits labs and imaging providers.

Labs & Diagnostics

Denial worklist with appeal drafting

Groups denials by reason, pulls the relevant policy and chart extract and drafts an appeal for a coder to edit. Every letter sent has a named approver, as billing companies need for client audits.

Medical Billing & RCM

Prior authorization packet assembler

Gathers the notes, imaging reports and forms a payer asks for, flags missing items and tracks status. The authorization coordinator submits the request; the tool never does.

Medical Clinics

Visit documentation checker

Flags incomplete visit notes and missing signatures for the care coordinator before the day closes.

Home & Senior Care

Customer inquiry router

Sorts messages into order status, product questions and possible complaints. Anything that could be a complaint goes straight to the quality team with no AI drafting, a boundary device manufacturers should keep.

MedTech & Devices

Growth link

From internal tool to commercial asset

Software built around a real workflow makes your operation more consistent and produces data on conversion and cycle times. In some cases it becomes a product you sell. Either way, it should be planned alongside your go-to-market strategy, not after it.

Remove hand-offs that delay referrals and inquiries
Capture reasons and timestamps for reporting on referral conversion and days in accounts receivable
Package an internal workflow into a customer offer only after the boundary and security review are complete
Give sales a demo built on a real customer workflow instead of mock data

Our approach

How an engagement runs

Phase 1

Discovery with the people who do the work

We follow real documents through the process with the billing manager, referral coordinator or clinic lead, including the workarounds.

Phase 2

Boundary and risk review

We write down intended use, claims, data, hosting and who reviews each output, and bring in regulatory specialists if a function nears diagnosis or treatment.

Phase 3

Prototype and evaluate

We build a test set from de-identified or synthetic examples and count error types separately. One supplier reported patient matching for between 75% and 85% of incoming faxes, so the unmatched remainder needs a designed review queue.

Phase 4

Supervised pilot

Real users run the tool against measures set in advance. A pilot can graduate, change or stop, and stopping is a valid result.

Phase 5

Handover

Documentation, monitoring, change control and a named owner pass to your team.

Outcomes

What usually improves

A tool people use

Narrow scope and operator input are intended to raise adoption of the first release.

Fewer retyping steps

Staff stop copying data between systems and handle exceptions instead.

Measured AI quality

You know which errors occur, how often, and which are caught in review.

A clearer regulatory position

Intended use and claims are written down before launch, not after.

What this depends on

Outcomes depend on the baseline process, document quality, integration access and whether users help shape the tool. We cannot promise time saved or revenue gained, and a pilot may show that a workflow is better fixed than automated.

Industries

Where it fits best

01Digital HealthFounders get a first version that operators can try, plus a plain read on where NHS DTAC assessment, the DCB0129 safety standard and the FDA lines sit before claims are written.02Hospitals & SystemsHospitals already have EHR vendor tools and a governance committee. We build the gaps between systems, such as a referral tracker.03TelehealthAsync intake and follow-up tools suit virtual care, but a symptom or treatment recommendation inside an app is not automatically exempt from device oversight.04Mental HealthScheduling, intake and note-drafting helpers only. Illinois and Nevada limit AI that delivers therapy, so tools do not converse therapeutically with clients.05MSOs & GroupsShared patient access and reporting tools across sites, with site differences configured rather than copied.06PharmaciesRefill-request and transfer intake tools route any clinical question to a pharmacist, who verifies before anything is sent.

Limits

What to watch out for

FDA's clinical decision support guidance (final 6 January 2026, reissued 29 January 2026) is a function-by-function test, not a blanket AI exemption. Patient- or caregiver-facing functions can still be devices.
FDA's AI-enabled device lifecycle guidance was issued in draft on 7 January 2025 and is still not for implementation. FDA's predetermined change control plan (PCCP) guidance (final, 18 August 2025) is nonbinding, and the 19 August 2026 generative-AI discussion paper is not policy.
In the UK, MHRA and NHS England clarified on 29 July 2026 that clinician-reviewed transcription, summaries or code suggestions can fall outside device regulation, while diagnosis, treatment or automated clinical action falls inside. DCB0129 applies to manufacturers and DCB0160 to deploying organizations.
The proposed HIPAA Security Rule overhaul (NPRM, 6 January 2025) is not final, so we build to current requirements. We do not build regulated medical devices, which need a quality management system. Check with qualified counsel before any diagnostic or treatment claim.

Questions

Frequently asked questions

What do you build and what do you not build?

We build internal tools, workflow products, document pipelines and integrations. We do not build software that diagnoses, treats or takes automated clinical action. That is device territory and needs a quality system and regulatory specialists.

Is a scribe or admin assistant a medical device?

It depends on intended use, not the label. The UK clarification of 29 July 2026 says clinician-reviewed transcription and summaries can fall outside device regulation, while tools intended for diagnosis, treatment or automated clinical action fall inside.

How do you test an AI feature before launch?

We assemble a test set from de-identified or synthetic examples, define the error types that matter and set acceptance thresholds in advance. Omissions and invented details are counted separately, then re-measured after every change.

Should we build or buy?

Check first what your EHR and practice management vendors already offer. We build where the workflow crosses systems or is specific to you, and we compare options in AI strategy work.

Can you help us get FDA clearance or MHRA approval?

No. Submissions belong to regulatory specialists. We can document how the software works and help you learn early whether a feature is likely to be in scope.

Does the software have to be hosted in the US?

For covered electronic health records in Texas, SB 1188 requires physical maintenance in the US or a US territory from 1 January 2026, including cloud-held records. We decide hosting location at the start, with the BAA or data processing terms.

Show us the spreadsheet that runs your process

Bring the workflow, the documents it touches and its owner. We will tell you what we would build first and which parts need a regulatory conversation before design starts.