A practical, honest breakdown of what AI can and cannot do inside a medical practice, which use cases to start with, which to engineer carefully, which to avoid, and why off-the-shelf tools are not the answer.
ChatGPT, Gemini, and Copilot are consumer products. They are not designed for regulated industries, and putting patient data into their consumer tiers is a HIPAA violation.
There is no off-the-shelf AI product you can subscribe to and start feeding patient information. The free and consumer tiers of every major AI tool say in their terms that they are not HIPAA-compliant, do not sign business associate agreements, and may use your inputs to train their models.
That is a real problem, because AI can take a large share of the administrative burden off clinical staff. Unlocking it takes a purpose-built system, designed from the ground up to keep patient data inside compliant boundaries.
It does not mean building a language model from scratch. That would cost millions and take years. It means building a secure application layer on top of AI infrastructure that is already covered by a BAA.
GPT-6 Astra, Claude Opus 5.5, or Gemini 4 Argon. You don't build the engine. You license it from a provider who signs a BAA.
How data flows into the model, what the model may see, how outputs are reviewed, how access is controlled, and how every interaction is logged for audit.
Encryption at rest and in transit, role-based access, audit trails, retention policies, and breach notification procedures.
That is different from signing up for a SaaS product. It takes engineering, security review, and ongoing maintenance. It is also the only way to use AI meaningfully in a regulated medical environment without exposing the practice to legal and financial risk.
AI compliance in healthcare is not about the model. It is about the infrastructure around the model. The same OpenAI model family behind ChatGPT, GPT-6 Astra, is available through Azure OpenAI under Microsoft's BAA. The model is the same. The infrastructure and the legal agreements make the difference.
Beyond the obvious HIPAA problem, consumer AI tools fall short in healthcare for practical reasons:
The BAA is the legal instrument that makes third-party AI processing possible under HIPAA.
Under HIPAA, a business associate is any entity that creates, receives, maintains, or transmits protected health information on behalf of a covered entity, your practice. When you send patient data to an AI model hosted by Microsoft, Amazon, or Google, that cloud provider becomes your business associate. So does any company, nBrain included, that builds or operates the system and can reach the PHI.
A BAA is a contract between your practice and the vendor that specifies:
If an AI vendor will not sign a BAA, you cannot send it PHI. It doesn't matter how good its security is, how popular the product is, or what its marketing says about privacy. Without a signed BAA, sending patient data to that vendor is a HIPAA violation, with civil money penalties per violation and annual caps per violation category that run into the millions of dollars, adjusted for inflation every year.
The good news: every major cloud AI provider now offers BAAs on its enterprise and API tiers. The challenge is not finding a compliant provider. It is building the application correctly on top of one.
These providers offer BAAs and run infrastructure designed for regulated workloads. The models are the same frontier technology behind consumer tools, reached through compliant channels. We are model-agnostic and route each task to the right one.
The most mature option for healthcare AI. Azure has supported HIPAA workloads for years and is already used by major health systems. OpenAI's models run on Azure's infrastructure, so data doesn't touch OpenAI's consumer servers. Microsoft publishes extensive compliance documentation, including SOC 2 Type II reports and HITRUST CSF certification for Azure.
Azure AI services for speech-to-text, text analytics, and document processing sit under the same BAA.
AWS has the longest track record in healthcare cloud compliance. Bedrock gives access to several model families, including Anthropic's Claude, Meta's Llama, and Amazon's own models, inside AWS's HIPAA-eligible infrastructure.
The advantage is model choice: if one model is better at clinical documentation and another at administrative work, you can use both under the same BAA and compliance framework.
Google Cloud signs BAAs for its covered Cloud Platform services, including Vertex AI. It also offers healthcare-specific tools such as the Healthcare Natural Language API inside the same environment.
Google has published medical-tuned research models (Med-PaLM). Check what is generally available under the BAA before planning around one.
Anthropic offers BAAs for direct API access. Claude is known for strong instruction-following, careful writing, and a large context window, which suits long medical records, insurance documents, and clinical protocols in a single request.
Anthropic states that commercial API data is not used to train its models.
Running open models on infrastructure you control avoids a third-party model provider. Because the data never leaves your environment, there is no model vendor acting as a business associate. Your practice, or its IT partner, owns every security control, encryption, access management, and audit logging.
The tradeoff is real: substantial GPU hardware or cloud GPU instances, ongoing maintenance, and models that are generally less capable than the frontier commercial ones. For very sensitive specialties, or practices that want no external data exposure, it's a viable path, especially for simpler work like document categorization, template generation, and internal search.
The architecture shows why custom development is necessary and where each compliance requirement lives in the system.
01
Practice staffAuthenticated user02
Custom applicationAccess controls and audit log03
De-identification layerPHI stripped or tokenized04
AI model, under a BAAProcesses the request05
AI responseNo PHI kept in model memory06
Re-identification layerContext restored07
Review interfaceHuman verification08
Final outputLogged and attributedEvery component in this flow is a compliance decision. The custom application is where the engineering lives. It is the layer around the model that enforces each HIPAA requirement:
Clear value, straightforward compliance, low risk. These should be the starting point for any practice exploring AI.
Draft prior authorization letters, denial appeals, referral summaries, and other administrative correspondence. Staff provide the key clinical details; the AI produces properly formatted, complete documents.
Staff review every output before it's sent. The AI drafts; it doesn't decide. With de-identification, it may never see the patient's name.
30 to 60 minutes per provider per day on paperwork.
After an encounter, structure SOAP notes from dictated or typed input, clean free text into standard formats, and check documentation is complete. The clinician reviews and signs before the note enters the record.
The physician remains the author of the note. AI speeds up documentation; it doesn't replace clinical judgment. Think of a medical scribe that is faster, more consistent, and available around the clock.
1 to 2 hours per provider per day.
Ground the AI in your practice's protocols, formulary, drug interaction guidelines, referral procedures, and staff handbooks. Staff ask in plain language (“What is our protocol for a patient presenting with chest pain and a history of atrial fibrillation?”) and get an immediate, sourced answer instead of searching binders or SharePoint.
The knowledge base holds institutional knowledge, not patient data. No PHI in the question or the answer.
Review clinical documentation against CPT and ICD-10 codes to find likely under-coding, documentation gaps that lead to denials, and mismatches between diagnosis and procedure codes. It augments certified coders; it doesn't replace them.
The AI reviews documentation already in the system, inside the same access boundaries as your billing staff. A certified coder reviews every suggestion before submission.
Generate appointment reminder language, post-visit care instructions, pre-procedure preparation guides, and general health education content. A human approves everything before it reaches a patient.
Templates need no PHI. Staff personalize them through your existing patient portal or secure messaging.
Interactive training modules, compliance quizzes, and an always-on resource for questions about operations, EHR workflows, or clinical protocols. New staff ramp faster by asking an AI that knows your procedures.
Training content is institutional, drawn from your policies and manuals. No PHI exposure.
Achievable under HIPAA, but they need specific architecture decisions, extra security layers, and clear rules about human oversight. The compliance cost is higher and the engineering has to be precise.
Ambient listening can transcribe and summarize encounters in real time. Products like Nuance DAX and Abridge have proven the model. A custom build can get similar results with more control over data handling and lower per-encounter cost at scale.
Encounter audio is PHI. It must be captured, sent, processed, and (if kept) stored entirely inside HIPAA-eligible infrastructure:
Process audio as a real-time stream and don't keep raw recordings long-term. Once the clinician approves the note, discard the audio. That keeps the PHI footprint small and still delivers the clinical value. Medical speech models, such as AWS Transcribe Medical, improve accuracy on clinical terms.
A chatbot on your site or portal can handle scheduling, frequently asked questions, pre-visit instructions, and basic triage. The moment a patient types symptoms, medications, or anything identifying, the conversation is PHI.
You can't control what a patient types. A scheduling bot will still receive “I need to reschedule because my cancer treatment side effects are worse,” and that message is now PHI.
Handles only general, non-clinical questions: hours, directions, accepted insurance, general preparation. Clear disclaimers that it can't give medical advice or take health information. No BAA needed for the chatbot itself, but careful prompt design to redirect clinical questions.
Built on HIPAA-eligible infrastructure with encryption, access controls, audit logging, and patient authentication. A much larger build, but it enables symptom pre-screening, refill requests, and secure messaging. The platform must be under a BAA and tied into your patient authentication.
AI reads years of chart notes, labs, imaging reports, and consults to give the provider a concise clinical summary before the visit. For complex patients that can save 15 to 30 minutes of chart review per visit.
The AI ingests the most sensitive data you hold, complete records. It must travel only inside compliant infrastructure, and the model needs a context window large enough for long records, which is where Claude Opus 5.5 and the other long-context models help.
A de-identification pipeline. Before records reach the model, strip direct identifiers (name, date of birth, SSN, MRN) and replace them with tokens. The AI works on clinical content without knowing whose it is; the application re-associates the output with the right record. Even in a theoretical breach of the model provider, the data would be de-identified.
The highest-value applications read from and write back to your EHR: pulling history, inserting drafted notes, updating problem lists, triggering workflow actions.
EHR APIs carry PHI at every step. The integration needs secure, authenticated connections (typically FHIR R4 or the vendor's own APIs), and your EHR vendor has to support and approve it. Epic, athenahealth, eClinicalWorks, and Oracle Health all have APIs, but approval, testing, and credentialing can take weeks to months.
Start read-only. A system that pulls from the EHR to produce summaries or suggestions, with a human entering approved content back, removes the risk of AI errors being committed to the record automatically. Add write-back once confidence is established.
These carry significant legal, regulatory, or clinical risk. Some are inadvisable outright. Others may become possible but need regulatory frameworks that don't fully exist yet.
AI should never diagnose, prescribe, recommend treatment, or make clinical decisions without physician oversight and final approval.
This goes beyond HIPAA into FDA territory. Software intended to diagnose or treat may be regulated as Software as a Medical Device and need clearance or approval before clinical use. Liability is largely untested: if an AI recommendation harms a patient, it's unclear who is responsible.
AI can surface information, highlight patterns, and draft recommendations for a physician to review. A clinician is always the final authority, and that review is documented.
Fine-tuning on patient data can improve performance for your context, but:
Retrieval-augmented generation (RAG). Data stays in a secure database and relevant snippets are fed to the model at query time. The model references your data; it never learns from it. Easier to audit, easier to delete, no memorization.
These carry federal protections beyond standard HIPAA. Psychotherapy notes have specific carve-outs in the Privacy Rule, and substance use disorder treatment records fall under 42 CFR Part 2, with stricter consent rules.
AI processing of these categories needs patient-specific written consent that explicitly covers it: granular, revocable, and documented. Many practices find the consent burden alone makes it impractical.
Exclude these categories from the first implementation. Evaluate them separately with counsel and updated consent processes.
A message with a diagnosis, results, or treatment details sent by standard email, SMS, or unencrypted messaging is a HIPAA violation, however it was written.
AI can draft. Delivery goes through secure channels: an authenticated portal, encrypted email, or secure messaging. The AI never sends PHI to patients on its own, without human review and a compliant channel.
The most common and most preventable violation: staff pasting patient information into ChatGPT, Gemini, or another consumer tool to help with notes, letters, or coding. Each instance is a potential breach.
Give staff a compliant alternative that is easier and more useful than consumer tools, and a clear policy against unapproved AI for anything touching patient information. The best prevention is making the compliant option the most convenient one.
When a use case needs AI to process PHI, these patterns add protection beyond the BAA itself.
The most powerful tool available. Before data reaches the model, an automated pipeline strips the 18 HIPAA identifiers (name, address, dates, phone, email, SSN, MRN, and the rest) and replaces them with tokens. The AI processes clinical content without knowing whose it is. Afterward, the application maps the tokens back.
Input
Patient record“John Smith, DOB 3/15/1962”Engine
De-identificationNamed-entity recognition plus rulesOutput
Sanitized text“[PATIENT_1], DOB [DATE_1]”Model
AI modelProcesses tokens, not identitiesThe token map is stored separately inside your controlled infrastructure. Even if the model provider were breached, the exposed text would be de-identified and clinically meaningless without it.
Instead of training on your data, RAG keeps it in a secure, encrypted vector database and retrieves only the relevant snippets for each request. The model uses them as context and doesn't retain them.
For the most sensitive work, AI processing runs in a dedicated virtual private cloud with no internet egress. Data enters through one authenticated endpoint and results return the same way. Nothing leaves by any other path. It is the pattern used for high-security government workloads, adapted for healthcare.
The application enforces minimum necessary by design. Billing staff see financial and coding data. Nurses see clinical data for their care coordination role. Physicians see more, within their patient panel. The model receives only what the requesting user is authorized to see, never the whole record.
A compliant AI system for healthcare is not a weekend project. Here is an honest view of the investment.
A chatbot or automation for a non-regulated business might take 2 to 4 weeks. The same tool for a medical practice can take 6 to 12 weeks, because of the compliance infrastructure around it:
Practices carry unusually high labor costs for administrative work, which is why the economics hold up:
Builds start at $40,000, and a typical build takes about 3 months. Running costs, your cloud and model accounts, are billed direct to you at list price with no markup. Routing each task to the right model brings model usage cost down by about 65%.
The compliance infrastructure built for the first use case is the foundation for every one after it. The BAA, the encryption, the audit system, and the access controls don't need rebuilding. Each new capability costs less than the first, which is why one well-architected platform beats a patchwork of point solutions from several vendors.
Phase 1
Administrative automationPlus the internal knowledge basePhase 2
Clinical documentationPlus coding reviewPhase 3
EHR integrationPlus record summarizationPhase 4
Advanced capabilitiesPlus patient-facing toolsStand up the compliant infrastructure and execute the BAA with the cloud provider. Build the core application with authentication, audit logging, and encryption. Deploy the first use cases: administrative drafting, the internal knowledge base, and communication templates. Staff get value right away while the compliance foundation is validated.
Add documentation support: note structuring, dictation cleanup, SOAP notes. Add coding review against billing codes. These lift provider efficiency and practice revenue directly, and the Phase 1 foundation supports them with little extra work.
Begin EHR integration, read-only first. Add record summarization with de-identification. Add voice transcription if ambient documentation is a priority. More engineering, the highest value per encounter.
Patient-facing chatbots, EHR write-back, clinical decision support tools, and specialty capabilities, each built on the Phase 1 foundation and proven through Phases 2 and 3.
AI in healthcare is not a technology problem. It is a compliance and architecture problem. The models are ready and the cloud infrastructure is ready. What most practices are missing is the application layer that connects them to their workflows inside the rules that protect their patients. That application layer is what we build.
This guide is for educational purposes and is not legal advice. Consult healthcare legal counsel before implementing AI systems that process PHI. Model names and provider BAA coverage change; confirm current terms with each provider.
In a strategy session we map your workflows against this guide, pick the first low-risk use cases, and show you the architecture that keeps PHI inside your boundary.