Healthcare AI, built to a standard a compliance auditor would respect.
We help digital health teams and clinical operators ship AI systems that survive a HIPAA review, a security questionnaire, and a year in production.
Start with a discovery sprint →What we actually do
Most healthcare AI work falls apart at one of three places: a data flow that quietly sends PHI to a model that shouldn’t see it, an audit log the application can edit, or an integration with the EHR that double-books patients or drops sync. We build systems where none of those failures are possible by design, not by policy.
We focus on a narrow slice of healthcare AI work where we have shipped production systems and where the architectural decisions matter most:
Voice AI for patient interaction
Booking, rescheduling, cancellations, after-hours triage, and warm transfers. Built on HIPAA-eligible telephony and transcription with BAAs in place, and a PHI de-identification layer between the transcript and any LLM so the model never sees a patient identifier.
AI medical scribes
Provider-patient conversation to draft SOAP note in seconds, with structural safeguards against fabricated findings, ICD-10 codes validated locally before display, no audio storage, and provider approval required before any note reaches the EHR.
EHR integrations
Bi-directional FHIR R4 sync, proven with athenahealth, extensible to other FHIR-capable EHRs through an adapter pattern. Real-time push plus reconciliation sync, conflict detection, and full audit trail on every record touched.
HIPAA architecture review for teams mid-build
A focused two-week engagement for digital health teams who have an AI product in development and need a senior team to audit the data flow, identify compliance gaps, and produce a remediation plan they can hand to their engineers. Useful before a security review, before a BAA negotiation, or before a launch.
If your build doesn’t fit one of these, we will tell you on the first call. We have turned down more healthcare engagements than we have taken.
How we think about healthcare AI builds
A few principles that show up in every system we ship.
PHI never reaches an LLM that doesn’t need it
The default architecture for AI products is to send conversation text to a model and let it figure out what to do. In healthcare, that default is a violation waiting to be discovered. We design data flows so that patient identifiers are stripped before any text leaves controlled infrastructure, and re-associated server-side after. This is provable from the API logs.
Audit logs are enforced at the database, not the application
A logging table the application can write to is also a logging table the application can be tricked into modifying. We use append-only database permissions so the worst a compromised credential can do is add false entries, never remove real ones.
Vendor BAAs are required before any data flows
“HIPAA-compliant” with no signed BAA is not a thing. We will not integrate a vendor into a healthcare build without a BAA in writing naming the specific service.
Audio is not stored unless there is a clinical reason
Every byte of PHI stored is a byte that has to be defended in an audit and disclosed in a breach. The right question before storing anything is “do we actually need this?” In most AI scribe builds, the answer is no.
Scheduling concurrency is handled at the database layer
Double-booking is the most embarrassing failure mode for a clinical scheduling system and the most commonly skipped fix. Row-level database locks on the slot, tested on every deploy with concurrent booking scripts.
Clinical AI is provider-in-the-loop, always
Any AI-generated content that touches the EHR requires explicit provider approval. No auto-push, no background sync, no “approve all.” Every clinical note is a conscious decision.
Standards, frameworks, and controls
The platforms we build are designed against an insider threat model: any single compromised application credential cannot exfiltrate or modify the audit log, and no LLM provider receives identifiable patient data.
- HIPAA Security Rule: administrative, physical, and technical safeguards across 45 CFR §164.308, §164.310, §164.312
- HIPAA Privacy Rule: minimum necessary access enforced via RBAC at the API layer
- HITECH breach notification: audit trail sufficient to identify scope of any PHI exposure within the 60-day notification window
- FHIR R4 with SMART on FHIR authorization, proven with athenahealth, adapter pattern for other FHIR-capable EHRs
- PHI de-identification before any data reaches the LLM, re-identification handled server-side under the covered entity’s control
- BAAs executed with telephony, transcription, voice synthesis, hosting, and EHR integration vendors
- Encryption: TLS 1.2+ in transit, AES-256 at rest via field-level encryption on PHI columns
- Access control: TOTP-based MFA, short-lived JWT access tokens, RBAC enforced in middleware, session inactivity timeout
- Audit logging: append-only at the database permission level, covering every PHI access event with actor, timestamp, resource, action, IP, and result
- Multi-tenant isolation: PostgreSQL Row Level Security enforced at the database layer
- Data residency: US-region infrastructure only
BAA and security posture
For covered entities and business associates evaluating us as a sub-processor:
- We sign Business Associate Agreements before any PHI flows. No exceptions.
- All sub-processors in our healthcare stack (telephony, transcription, voice synthesis, hosting, EHR integration) operate under executed BAAs. We provide the BAA chain on request.
- Data residency is US-region only for healthcare engagements. No cross-border data flows.
- We maintain a written information security program covering access control, encryption, audit logging, incident response, vendor management, and employee security training.
- Security questionnaires (SIG, CAIQ, HECVAT) completed within 5–10 business days of receipt during active procurement.
If your security team needs to review our posture before a build conversation, contact ahmad@astechware.com and we will send the relevant documentation under NDA.
Case study
Voice booking and AI scribe platform for a US multi-location dental group
One platform handling voice booking, web booking, provider dashboard, AI medical scribe, and bi-directional athenahealth FHIR sync. Built so the LLM never sees a patient identifier, the audit log cannot be edited, and audio is never stored. Delivered in eight weeks across two phases.
Read the full case study →How we engage
We start every healthcare engagement with a paid one-week discovery sprint. You get a written deliverable you own whether or not you continue with us:
- A data flow map of your proposed or existing system, with every PHI touchpoint identified
- A compliance risk register covering HIPAA Security Rule, HITECH, and relevant state requirements
- An architecture recommendation with vendor selection, BAA requirements, and integration approach
- A phased build plan with milestones and pricing
Most teams find this is the cheapest way to know what they actually need before committing to a full build. It also gives both sides a low-risk way to see if we work well together before signing a larger engagement.