Claude for Healthcare: HIPAA-Ready Deployment Patterns

Table of Contents

1. Why Claude for Healthcare Matters
2. Understanding HIPAA Compliance for AI
3. Claude’s HIPAA-Ready Infrastructure
4. Business Associate Agreements and Legal Foundations
5. Secure PHI Handling and Data Routing
6. Audit Trails and Compliance Logging
7. Deployment Architectures for Healthcare
8. Healthcare-Specific Integrations and Connectors
9. Real-World Implementation Patterns
10. Common Pitfalls and How to Avoid Them
11. Next Steps and Getting Started

---

Why Claude for Healthcare Matters

Healthcare organisations across Australia and globally face mounting pressure to modernise their technology stack while maintaining ironclad regulatory compliance. Patient data is sacred—breaches destroy trust, trigger fines, and invite regulatory action. Yet the operational burden of managing clinical documentation, prior authorisations, discharge summaries, and coding is immense.

Claude represents a genuine shift in what’s possible. Unlike generic large language models, Anthropic has specifically built HIPAA-ready infrastructure that allows healthcare organisations to process Protected Health Information (PHI) without stripping data or compromising clinical utility. This means you can deploy Claude to summarise patient notes, assist with diagnostic coding, validate treatment plans, and automate administrative workflows—all while maintaining full audit trails and data residency compliance.

The economics are compelling too. Healthcare organisations we work with at PADISO report 40–60% reduction in time spent on manual documentation review, faster prior authorisation turnarounds, and improved coding accuracy. More importantly, they sleep better knowing their AI deployment is audit-ready from day one.

This guide walks you through the complete picture: how Claude’s infrastructure works, how to structure a Business Associate Agreement (BAA), how to route and protect PHI in production, and how to build deployment patterns that pass compliance audits without friction.

---

Understanding HIPAA Compliance for AI

What HIPAA Actually Requires

The Health Insurance Portability and Accountability Act (HIPAA) is not a single rule—it’s a framework. The Privacy Rule, Security Rule, and Breach Notification Rule together create a compliance obligation that applies to covered entities (hospitals, clinics, health plans) and business associates (vendors, cloud providers, AI platforms).

When you bring an AI system into a healthcare environment, that system becomes part of your compliance ecosystem. If Claude processes PHI, Anthropic becomes a business associate. If your internal systems route PHI to Claude, you become responsible for ensuring that routing is secure, logged, and compliant.

The core HIPAA requirements for AI systems are:

• Access controls: Only authorised users can trigger PHI processing
• Encryption in transit and at rest: Data moving to and from Claude must be encrypted
• Audit logging: Every interaction with PHI must be logged and auditable
• Data minimisation: Only necessary PHI should be sent to the model
• Breach notification: If data is exposed, you must notify affected individuals within 60 days
• Business Associate Agreement: Your vendor (Anthropic) must sign a BAA committing to HIPAA compliance

Claude’s infrastructure is designed to support all of these. But the responsibility for correct deployment sits with you. A BAA is not a magic compliance button—it’s a contractual commitment that both parties will implement the technical and administrative safeguards HIPAA requires.

Why Generic AI Models Fall Short

OpenAI’s standard API, Google’s standard Gemini API, and other public LLM endpoints have a critical limitation: they may retain or use input data for model improvement. This is explicitly incompatible with HIPAA. You cannot send PHI to a system that might log it, train on it, or expose it to other customers.

Anthropic’s HIPAA-ready Enterprise plans solve this by committing to zero data retention for inference. Input prompts and outputs are not logged for model training. The data flows through Claude’s infrastructure, produces a result, and is discarded—unless you explicitly ask for audit logging to your own systems.

This is not a minor distinction. It’s the foundation that makes compliant healthcare AI possible.

---

Claude’s HIPAA-Ready Infrastructure

How Claude Processes PHI Safely

Anthropic has extended Claude into healthcare with HIPAA-ready infrastructure that includes multiple deployment options, each with different security and compliance characteristics.

The HIPAA-ready Enterprise plan operates under these guarantees:

• No data retention: Prompts and responses are not stored for model training or improvement
• Encryption in transit: All communication with Claude uses TLS 1.2 or higher
• SOC 2 Type II compliance: Anthropic’s infrastructure is independently audited for security and availability
• BAA coverage: Anthropic signs a Business Associate Agreement committing to HIPAA compliance
• Audit logging: You can configure logging of all API calls to your own systems for compliance records

This architecture allows Claude to process clinical notes, patient demographics, medication lists, lab results, and other PHI without the data ever being used to improve the model or exposed to other users.

Deployment Options

You have several ways to deploy Claude for healthcare:

Direct API (HIPAA-ready Enterprise): You call Claude’s API directly from your healthcare application. This is the fastest path to production for organisations with strong internal security infrastructure. Anthropic handles encryption, availability, and compliance. You handle user access control, data minimisation, and audit logging on your side.

AWS Bedrock with BAA: Deploy Claude through Amazon Bedrock, which offers HIPAA-compliant infrastructure with AWS’s Business Associate Agreement. This is ideal if you’re already running healthcare workloads on AWS and want to keep everything within AWS’s compliance boundary.

Google Cloud with BAA: Similar to AWS, Google Cloud offers HIPAA-compliant Bedrock-equivalent services with Claude available. Choose this if your healthcare data already lives in Google Cloud.

Azure OpenAI with BAA: If you’re in the Microsoft ecosystem, Azure offers HIPAA-compliant Claude deployment (via partnerships with Anthropic).

Each deployment option has different latency, cost, and compliance characteristics. We’ll cover how to choose in the architecture section below.

Healthcare-Specific Capabilities

Claude for Healthcare includes connectors to critical healthcare data sources: ICD-10 coding databases, CMS Coverage Database, NPI Registry, and PubMed. These connectors allow Claude to ground its responses in real, up-to-date clinical reference data without you having to embed entire medical databases in your prompts.

For example, when Claude assists with diagnostic coding, it can look up ICD-10 codes in real time. When validating a treatment plan, it can check CMS coverage rules. This grounding dramatically improves accuracy and reduces hallucination—a critical requirement in healthcare.

---

Business Associate Agreements and Legal Foundations

What a BAA Actually Covers

A Business Associate Agreement is a legal contract between a covered entity (or business associate) and a vendor that processes PHI. The BAA is not separate from HIPAA—it’s how HIPAA extends compliance obligations to third parties.

Anthropics’s BAA commits to:

• Implementing and maintaining physical, technical, and administrative safeguards for PHI
• Limiting use and disclosure of PHI to only what’s necessary to provide the service
• Not using PHI for marketing, fundraising, or any purpose other than the contracted service
• Notifying you immediately if there’s a suspected breach
• Allowing you to audit Anthropic’s compliance practices
• Returning or destroying PHI when the contract ends
• Ensuring any subcontractors (e.g., AWS if you deploy via Bedrock) also have BAAs in place

The BAA does not guarantee that breaches will never happen. It commits both parties to reasonable safeguards and establishes liability if either party fails to uphold their obligations.

Negotiating and Executing a BAA

Anthropics publishes a standard BAA template. For most healthcare organisations, this template is acceptable without modification. However, larger health systems, hospital networks, and regulated entities sometimes want to negotiate specific terms:

• Audit rights: How often can you audit Anthropic’s compliance? (Standard: annual, with notice)
• Breach notification timeline: How quickly must Anthropic notify you? (Standard: without unreasonable delay, typically 24–48 hours)
• Data location: Can you require that PHI stays within a specific geographic region? (Standard: Anthropic can commit to US-only or region-specific processing)
• Encryption key management: Do you want to provide your own encryption keys? (Standard: Anthropic encrypts; you can add additional encryption on your side)
• Termination and data destruction: What happens to PHI when the contract ends? (Standard: Anthropic destroys or returns it within 30 days)

If you’re a mid-market or enterprise healthcare organisation in Australia or globally, we recommend having your legal team review the BAA before signing. The negotiation is usually straightforward—Anthropic’s terms are reasonable and HIPAA-aligned.

Once a BAA is in place, you’re not done. The BAA is the legal foundation, but compliance requires implementation. This is where audit trails, data routing, and access controls come in.

---

Secure PHI Handling and Data Routing

Designing a Data Flow That Protects PHI

The most common mistake in healthcare AI deployment is treating the AI system as if it’s inside your security boundary. It’s not. Claude runs on Anthropic’s infrastructure. Data flows from your systems to Anthropic’s systems and back. Every step of this flow must be protected.

Here’s a secure data flow pattern:

Step 1: User Authentication and Authorisation A clinician or administrator logs into your healthcare application using multi-factor authentication. The application checks that the user is authorised to view the specific patient’s record and to use the AI feature. This check happens in your system, not in Claude.

Step 2: Data Extraction and Minimisation Your application extracts only the PHI necessary for the task. If the task is “summarise this patient’s medication list,” you extract the medication list—not the entire EHR record. If the task is “check ICD-10 codes for this diagnosis,” you send the diagnosis and relevant clinical context, not the patient’s name, MRN, or DOB.

Data minimisation is both a HIPAA requirement and a practical security principle. The less PHI you send, the smaller the breach surface.

Step 3: Encryption in Transit Your application sends the minimised PHI to Claude via HTTPS with TLS 1.2 or higher. This is handled automatically by Claude’s API—you don’t need to do anything special. But verify in your code that you’re using HTTPS, not HTTP.

Step 4: Claude Processing Claude processes the request and returns a result. The result may contain PHI (e.g., “Patient’s medications include metformin 500mg BID”) or it may contain de-identified output (e.g., “This diagnosis typically requires X treatment”). Either way, Claude does not log or retain the data.

Step 5: Response Handling and Logging Your application receives the response and logs it to your own audit trail. This is critical: you need a record of what PHI was sent, what Claude returned, when it happened, and who requested it. This log is your evidence of compliance during audits.

Step 6: Display and Storage Your application displays the response to the authorised user and stores it in your EHR or documentation system, subject to your own retention policies.

Handling Different Types of PHI

Not all PHI is equally sensitive. HIPAA distinguishes between identified PHI and de-identified data. Understanding this distinction helps you design more efficient deployments.

Identified PHI includes patient name, MRN, date of birth, address, phone, email, social security number, and medical record numbers. This is the most sensitive category. If you’re sending identified PHI to Claude, you must have a strong business reason, a BAA in place, and robust audit logging.

Limited Dataset is PHI with certain identifiers removed (e.g., name and MRN stripped but age and diagnosis retained). This is less sensitive than full PHI but still requires protection.

De-identified Data has all identifiers removed or generalised (e.g., “patient aged 50–60 with Type 2 diabetes”). De-identified data is not subject to HIPAA, so you can send it to any AI system without a BAA. However, de-identification must be done correctly—removing just the name isn’t enough if other data points can re-identify the patient.

In practice, most healthcare AI deployments send identified or limited-dataset PHI to Claude. The task often requires it: diagnosing a patient’s condition requires knowing their demographics, symptoms, and medical history. The key is to:

1. Send only what’s necessary
2. Encrypt it in transit
3. Log it on your side
4. Have a BAA in place
5. Train your staff on data minimisation

Data Residency and Geographic Routing

If your healthcare organisation operates in Australia or another jurisdiction with data residency requirements, you need to ensure that PHI doesn’t leave that jurisdiction without explicit consent.

Claude’s standard deployment routes requests through Anthropic’s infrastructure, which may span multiple regions. If you need to guarantee that PHI stays within Australia, you have two options:

Option 1: AWS Bedrock (Australia Region) Deploy Claude through AWS Bedrock in the Sydney region (ap-southeast-2). AWS has a Business Associate Agreement and commits to processing data within the specified region. This is the most straightforward path for Australian healthcare organisations.

Option 2: Negotiate Data Residency with Anthropic For large healthcare organisations or health systems, Anthropic may be willing to negotiate data residency commitments as part of the BAA. This typically requires an enterprise contract and is not available through the standard self-serve API.

If you’re unsure whether your deployment meets data residency requirements, consult with your privacy officer and legal team. Data residency is a complex area with different requirements across states and countries.

---

Audit Trails and Compliance Logging

Why Audit Trails Matter

During a HIPAA audit, regulators will ask: “Show us every time this system accessed patient data. Who accessed it? When? What was the result? Was it authorised?”

If you can’t answer these questions with a complete, timestamped log, you’re in trouble. Audit trails are not optional—they’re a core HIPAA requirement.

Audit trails serve three purposes:

1. Compliance evidence: They prove to regulators that you’re monitoring access to PHI
2. Breach detection: They help you identify unusual access patterns that might indicate a compromise
3. Accountability: They create a record that deters unauthorised access

What to Log

When Claude processes PHI, you should log:

• Timestamp: Exact date and time (in UTC for consistency)
• User ID: Who requested the action
• User role: What’s their job title or role in the organisation
• Patient identifier: Which patient’s data was accessed (MRN or a de-identified patient ID)
• PHI accessed: What specific data was sent (medication list, lab results, etc.)
• Action performed: What did Claude do? (Summarise, code, validate, etc.)
• Result: What did Claude return
• Access reason: Why was this access necessary (clinical decision support, documentation, etc.)
• IP address: Where did the request originate
• API response code: Was the request successful (200) or did it fail (400, 500)?

Logging all of this might seem burdensome, but modern logging systems make it straightforward. Use structured logging (JSON format) and send logs to a centralised logging service.

Implementing Audit Logging

Here’s a practical pattern:

When a user requests an AI action:
1. Check user authentication and authorisation
2. Extract minimised PHI from your EHR
3. Create a log entry with all fields above
4. Send PHI to Claude API
5. Receive response from Claude
6. Log the response
7. Return result to user
8. Send log entry to your audit logging system

Your audit logging system should:

• Be separate from your main application (so if the app is compromised, logs aren’t automatically deleted)
• Use write-once storage (logs can be read but not modified after creation)
• Be retained for at least 6 years (HIPAA standard)
• Be encrypted at rest
• Be accessible only to compliance and security staff

If you’re using AWS, CloudTrail and CloudWatch Logs are suitable. On Google Cloud, Cloud Logging works. On Azure, Azure Monitor. If you’re running on-premises, use a dedicated logging server with restricted access.

Monitoring and Alerting

Logging is only useful if you monitor it. Set up alerts for:

• Unusual access patterns: The same user accessing 100 patient records in 10 minutes
• Failed authentications: Multiple login attempts from the same IP
• Off-hours access: PHI accessed at 3 AM when the clinic is closed
• Bulk exports: Large amounts of PHI extracted in a single request
• Access from unexpected locations: A user in Sydney accessing systems from an IP in another country

These alerts won’t catch every breach, but they’ll catch the obvious ones. Combined with regular audit reviews (weekly or monthly), they form a strong detection layer.

---

Deployment Architectures for Healthcare

Architecture 1: Direct API with In-House Security

Best for: Health systems with strong internal security teams, organisations processing high volumes of PHI, organisations with specific data residency requirements.

How it works:

• Your healthcare application runs on your own infrastructure (on-premises or private cloud)
• When a clinician requests AI assistance, your application calls Claude’s API directly
• PHI is encrypted in transit using TLS 1.2+
• Your application logs all interactions to your own audit system
• Responses are displayed to the clinician and stored in your EHR

Pros:

• Full control over data flow and logging
• Lowest latency (direct connection to Claude)
• Easiest to meet data residency requirements (you control routing)
• Scales well for high-volume deployments

Cons:

• Requires strong in-house security expertise
• You’re responsible for all authentication, authorisation, and encryption
• Requires BAA negotiation and management
• More complex to implement than managed solutions

Example implementation:

Healthcare App → Authenticate User → Check Permissions → Extract PHI → 
Encrypt → Call Claude API → Log Interaction → Decrypt Response → 
Display to User → Store in EHR

Architecture 2: AWS Bedrock with Managed Compliance

Best for: Organisations already using AWS, organisations wanting AWS’s compliance management, organisations in regions where AWS has Bedrock availability.

How it works:

• Your healthcare application runs on AWS (EC2, Lambda, or other compute)
• Your application calls Claude through AWS Bedrock API
• AWS handles encryption, availability, and compliance
• AWS has a BAA covering Bedrock
• You still implement application-level access control and logging

Pros:

• AWS manages infrastructure compliance (SOC 2, FedRAMP, etc.)
• Simplified BAA (single agreement with AWS covers Bedrock)
• Bedrock handles scaling and availability
• Easy integration with other AWS healthcare services (HealthLake, etc.)
• AWS CloudTrail logs all API calls automatically

Cons:

• Slightly higher latency than direct API (request goes through AWS)
• AWS Bedrock pricing (per-token) may be higher than direct API for large volumes
• You’re dependent on AWS’s region availability
• Still requires application-level logging and access control

Example implementation:

Healthcare App (on AWS) → IAM Authentication → Extract PHI → 
Call Bedrock Claude API → CloudTrail Logging → Receive Response → 
Log to CloudWatch → Display to User → Store in HealthLake or EHR

Architecture 3: Hybrid with Data Sanitisation

Best for: Organisations wanting to use Claude but with additional privacy assurance, organisations processing especially sensitive data, organisations with strict de-identification requirements.

How it works:

• Before sending PHI to Claude, your application de-identifies or minimises it
• Identifiers (names, MRNs, dates of birth) are removed or generalised
• Only clinical context (symptoms, diagnoses, medications, lab values) is sent to Claude
• Claude returns a result based on de-identified data
• Your application re-links the result to the original patient record

Pros:

• Reduces PHI exposure (Claude never sees patient identifiers)
• Simplifies compliance (de-identified data isn’t subject to HIPAA)
• Reduces breach risk (even if Claude’s infrastructure is compromised, identifiers aren’t exposed)
• Works with any Claude deployment (no BAA required for de-identified data)

Cons:

• Requires careful de-identification logic (risk of re-identification)
• May reduce clinical utility (some tasks require knowing patient identifiers)
• Adds latency (de-identification and re-linking steps)
• Requires expertise in privacy-preserving techniques

Example implementation:

Healthcare App → Extract PHI → De-identify (remove names, MRNs, DOBs) → 
Call Claude API → Log De-identified Request → Receive Response → 
Re-link to Original Patient → Log Final Result → Display to User

Choosing the Right Architecture

Use this decision tree:

1. Do you have strong in-house security and compliance teams? → Use Architecture 1 (Direct API)
2. Are you already running on AWS? → Use Architecture 2 (Bedrock)
3. Do you need maximum privacy assurance? → Use Architecture 3 (Hybrid with de-identification)
4. Are you a small clinic with limited resources? → Use Architecture 2 or 3 (managed solutions)

Most healthcare organisations we work with at PADISO start with Architecture 2 (Bedrock) because it balances compliance simplicity with operational control. As they scale or develop more sophisticated use cases, some move to Architecture 1.

---

Healthcare-Specific Integrations and Connectors

ICD-10 Coding Assistance

One of the most time-consuming tasks in healthcare administration is coding diagnoses and procedures correctly for billing and statistical purposes. Incorrect coding leads to claim denials, compliance issues, and lost revenue.

Claude can assist with ICD-10 coding by:

• Reading clinical documentation
• Identifying diagnoses and procedures
• Looking up appropriate ICD-10 codes
• Suggesting codes with confidence levels
• Flagging ambiguous or missing documentation

Claude’s healthcare connectors include access to ICD-10 databases, so it can validate codes in real time without you having to embed the entire ICD-10 catalogue in your prompts.

Example use case: A discharge summary mentions “patient presented with fever and cough, diagnosed with community-acquired pneumonia, treated with azithromycin.” Claude reads this, identifies the relevant ICD-10 codes (J18.9 for pneumonia, Z79.4 for long-term antibiotic use), and suggests them to the coder for review. The coder can accept or modify the suggestions before submitting the claim.

CMS Coverage and Prior Authorisation

Before approving a treatment, insurance companies (and Medicare/Medicaid) often require prior authorisation. This involves checking whether the treatment is covered, whether it meets medical necessity criteria, and whether cheaper alternatives exist.

Claude can assist by:

• Checking CMS Coverage Database for treatment coverage rules
• Identifying prior authorisation requirements
• Suggesting alternative treatments that may be covered
• Drafting prior authorisation requests

This can reduce prior authorisation turnaround time from days to hours, improving patient care and reducing administrative burden.

Example use case: A rheumatologist wants to prescribe a biologic therapy for a patient with rheumatoid arthritis. Claude checks CMS coverage rules, identifies that prior authorisation is required and that the patient must have failed at least one DMARD first. Claude checks the patient’s medication history, confirms they’ve tried methotrexate, and suggests the prior authorisation be submitted with that evidence.

NPI Registry and Provider Validation

Healthcare claims require correct provider identifiers (NPI numbers). Incorrect or outdated NPIs cause claim denials.

Claude can validate provider information against the NPI Registry, ensuring that claims are submitted with correct identifiers and reducing claim denials.

PubMed and Clinical Evidence

When making clinical decisions, providers need access to current evidence. Claude can search PubMed for recent research on a diagnosis or treatment and summarise findings.

Example use case: A GP is treating a patient with atypical pneumonia and wants to know the latest evidence on antibiotic choices. Claude searches PubMed, finds recent guidelines, and summarises treatment recommendations with citations.

FHIR Agent Skills

FHIR (Fast Healthcare Interoperability Resources) is the standard data format for healthcare interoperability. Claude’s FHIR agent skills allow it to read and write FHIR-formatted data, making it easy to integrate Claude with modern healthcare systems and EHRs.

This is especially valuable if you’re modernising your EHR infrastructure or building new integrations. Instead of writing custom code to parse FHIR data, Claude can understand it natively.

---

Real-World Implementation Patterns

Pattern 1: Clinical Documentation Summarisation

Problem: Clinicians spend 25% of their time documenting patient encounters. Much of this time is spent copying information from one note to another, summarising previous visits, and updating problem lists.

Solution: Deploy Claude to automatically summarise clinical notes.

Implementation:

1. When a clinician completes a patient encounter, they submit the raw notes to Claude
2. Claude reads the notes and extracts:

• Chief complaint - History of present illness - Physical exam findings - Assessment and plan - Medications prescribed

1. Claude formats this as a structured clinical note
2. The clinician reviews and edits the note before finalising it
3. The note is stored in the EHR

Outcome: Clinicians report 30–40% reduction in documentation time. The notes are more consistent and comprehensive because Claude catches details clinicians might miss.

Compliance considerations:

• Claude processes patient identifiers and clinical PHI
• BAA required
• Audit logging of all notes processed
• Clinician must review and approve before finalising (Claude is an assistant, not an autonomous system)

Pattern 2: Diagnostic Code Validation

Problem: Coders manually assign ICD-10 codes to diagnoses. This is tedious, error-prone, and slow. Incorrect codes cause claim denials and compliance issues.

Solution: Deploy Claude to suggest ICD-10 codes based on clinical documentation.

Implementation:

1. Coder uploads or pastes clinical documentation into the coding application
2. Claude reads the documentation and identifies diagnoses
3. Claude looks up relevant ICD-10 codes and suggests them with explanations
4. Coder reviews suggestions, accepts or modifies them, and submits the codes
5. Codes are submitted to the billing system

Outcome: Coders report 50% reduction in time per chart. Coding accuracy improves because Claude catches diagnoses the coder might miss and validates codes against the ICD-10 standard.

Compliance considerations:

• Claude processes de-identified clinical data (diagnoses only, no patient identifiers)
• No BAA required if data is properly de-identified
• Audit logging of all coding suggestions (optional but recommended)
• Coder remains responsible for final coding decision

Pattern 3: Prior Authorisation Automation

Problem: Prior authorisation requests are manual, slow, and often incomplete. Insurance companies reject requests due to missing information, delaying treatment.

Solution: Deploy Claude to draft and validate prior authorisation requests.

Implementation:

1. Provider enters treatment request (medication, procedure, etc.) and patient information
2. Claude checks CMS or insurance coverage rules
3. Claude identifies prior authorisation requirements and required supporting documentation
4. Claude drafts a prior authorisation request with all required information
5. Provider reviews and submits the request to the insurance company
6. Insurance company approves or requests additional information

Outcome: Prior authorisation turnaround time drops from 3–5 days to a few hours. Approval rates improve because requests are complete and well-documented.

Compliance considerations:

• Claude processes patient identifiers and clinical PHI
• BAA required
• Audit logging of all prior authorisation requests
• Provider remains responsible for accuracy and completeness of the request

Pattern 4: Medication Interaction Checking

Problem: Prescribers must manually check for drug interactions before prescribing. This is time-consuming and error-prone, especially for patients on multiple medications.

Solution: Deploy Claude to check for medication interactions.

Implementation:

1. Prescriber enters a new medication and patient’s current medication list
2. Claude checks for interactions against a drug interaction database
3. Claude returns a report of significant interactions with severity levels
4. Prescriber reviews interactions and decides whether to proceed, adjust dose, or choose a different medication
5. Prescription is submitted to the pharmacy

Outcome: Interaction checking is faster and more comprehensive. Prescribers catch interactions they might have missed, improving patient safety.

Compliance considerations:

• Claude processes patient medication list (limited PHI)
• BAA required
• Audit logging of all interaction checks
• Prescriber remains responsible for clinical decision

---

Common Pitfalls and How to Avoid Them

Pitfall 1: Forgetting That a BAA Is Not Compliance

The mistake: Signing a BAA with Anthropic and assuming you’re compliant.

Why it fails: A BAA is a legal agreement, not a technical implementation. You still need to implement access controls, encryption, audit logging, and staff training on your side.

How to avoid it: After signing a BAA, conduct a compliance gap analysis. Identify what technical and administrative controls you need to implement. Use a framework like HITRUST or HIPAA Security Rule to guide your assessment.

Pitfall 2: Sending More PHI Than Necessary

The mistake: Sending entire patient records to Claude instead of just the relevant data.

Why it fails: Every piece of PHI you send increases breach risk. If Claude’s infrastructure is compromised, more data is exposed. It also increases costs (you’re paying for tokens you don’t need).

How to avoid it: Implement data minimisation at the application level. Before calling Claude, extract only the PHI necessary for the task. If the task is “check for drug interactions,” send the medication list—not the patient’s entire medical history.

Pitfall 3: Neglecting Audit Logging

The mistake: Implementing Claude for healthcare but not logging interactions.

Why it fails: During a HIPAA audit, you’ll be asked to prove that PHI access was authorised and appropriate. Without logs, you can’t prove anything. You’ll fail the audit.

How to avoid it: Implement audit logging from day one. Use structured logging (JSON) and send logs to a centralised logging system. Test that logs are being written correctly before deploying to production.

Pitfall 4: Assuming Claude Is an Autonomous Decision-Maker

The mistake: Deploying Claude to make clinical or billing decisions without human review.

Why it fails: Claude is a language model, not a clinical decision support system. It can make mistakes, hallucinate, or misinterpret clinical data. If a patient is harmed because Claude made a wrong suggestion, you’re liable.

How to avoid it: Always position Claude as an assistant that augments human decision-making, not replaces it. Require a human (clinician, coder, or administrator) to review and approve every decision before it’s finalised. Document this in your policies and procedures.

Pitfall 5: Deploying Without Staff Training

The mistake: Rolling out Claude to clinicians and coders without training them on how to use it safely and effectively.

Why it fails: Staff may send unnecessary PHI, misinterpret Claude’s output, or use it for tasks it’s not suitable for. This increases risk and reduces the value of the deployment.

How to avoid it: Develop a training program that covers:

• How Claude works and what it’s good and bad at
• HIPAA compliance requirements
• Data minimisation principles
• How to use Claude for specific tasks (coding, documentation, etc.)
• What to do if Claude makes a mistake or returns unexpected output

Provide hands-on training before deployment and ongoing refresher training annually.

Pitfall 6: Ignoring Data Residency Requirements

The mistake: Deploying Claude through a region or cloud provider that doesn’t meet your data residency requirements.

Why it fails: Some jurisdictions (Australia, EU, etc.) require that healthcare data stay within specific geographic boundaries. Violating this is a compliance violation and can result in fines.

How to avoid it: Before deploying Claude, check your data residency requirements with your privacy officer and legal team. If you need data to stay in Australia, deploy through AWS Bedrock in the Sydney region or negotiate a data residency commitment with Anthropic.

Pitfall 7: Failing to Monitor for Breaches

The mistake: Implementing Claude but not monitoring for unusual access patterns or potential breaches.

Why it fails: Breaches happen. If you don’t monitor for them, you won’t know about them until a regulator or patient tells you. By then, you’ve missed the window to notify affected individuals and contain the breach.

How to avoid it: Set up monitoring and alerting for unusual access patterns (bulk exports, off-hours access, access from unexpected locations). Review logs weekly or monthly. Conduct quarterly security audits.

---

Next Steps and Getting Started

Phase 1: Assessment and Planning (Weeks 1–2)

Before deploying Claude for healthcare, understand your current state:

1. Map your current workflows: Where would Claude add value? Which tasks are most time-consuming or error-prone?
2. Assess your compliance readiness: Do you have audit logging? Access controls? Staff training programs? Identify gaps.
3. Identify data residency and compliance requirements: What regulations apply to your organisation? What data residency requirements do you have?
4. Evaluate deployment options: Direct API, AWS Bedrock, or hybrid? Which fits your infrastructure and compliance needs?
5. Estimate costs: How many API calls will you make? What’s the expected cost per month?

Phase 2: BAA Negotiation and Legal Setup (Weeks 3–4)

Once you’ve decided to proceed:

1. Engage legal counsel: Have your legal team review Anthropic’s BAA template and negotiate any required changes.
2. Execute the BAA: Sign the agreement with Anthropic (or AWS if deploying through Bedrock).
3. Document your deployment architecture: Create diagrams showing how data flows from your systems to Claude and back.
4. Develop policies and procedures: Document how staff should use Claude, what PHI can be sent, how to handle errors, etc.

Phase 3: Technical Implementation (Weeks 5–8)

Now build the technical infrastructure:

1. Set up audit logging: Implement structured logging and send logs to a centralised system.
2. Implement access controls: Ensure only authorised staff can use Claude features.
3. Build data minimisation logic: Extract only necessary PHI before sending to Claude.
4. Set up encryption: Ensure all data in transit is encrypted (TLS 1.2+).
5. Implement monitoring and alerting: Set up alerts for unusual access patterns.
6. Test end-to-end: Run through the complete workflow with test data.

Phase 4: Staff Training and Pilot (Weeks 9–10)

Before full rollout:

1. Develop training materials: Create guides, videos, and FAQs for staff.
2. Conduct training sessions: Train all staff who will use Claude.
3. Run a pilot program: Deploy Claude to a small group of users (e.g., one clinic or coding team).
4. Collect feedback: Ask users what’s working and what’s not.
5. Refine based on feedback: Make adjustments before full rollout.

Phase 5: Full Rollout and Monitoring (Weeks 11+)

Once the pilot is successful:

1. Roll out to all users: Deploy Claude across your organisation.
2. Monitor continuously: Watch for unusual access patterns, errors, or performance issues.
3. Review logs regularly: Conduct weekly or monthly log reviews to ensure compliance.
4. Conduct quarterly audits: Perform security and compliance audits.
5. Iterate and improve: Based on usage patterns and feedback, optimise your deployment.

Getting Help

If you’re a healthcare organisation in Australia or globally looking to deploy Claude safely and compliantly, PADISO can help. We specialise in AI automation for healthcare, from strategy and architecture design to implementation and compliance audits.

Our approach is:

• Outcome-focused: We measure success by time saved, accuracy improved, and compliance achieved—not by features shipped.
• Compliance-first: We design deployments that pass audits from day one, not retrofitted compliance later.
• Hands-on: We work alongside your team, building institutional knowledge and capability, not just handing off code.

We’ve helped health systems implement AI automation for customer service in patient-facing roles, AI automation for financial services in revenue cycle management, and custom AI systems for clinical decision support.

If you want to discuss your specific use case, we offer free consultations. Contact us to get started.

Key Takeaways

1. Claude is HIPAA-ready, but deployment requires careful planning: A BAA is necessary but not sufficient. You must implement access controls, encryption, audit logging, and staff training.

2. Data minimisation is both a compliance requirement and a practical security principle: Send only the PHI necessary for the task. This reduces breach risk and lowers costs.

3. Audit logging is non-negotiable: You must log every interaction with PHI so you can prove compliance during audits.

4. Choose the right deployment architecture for your needs: Direct API for maximum control, AWS Bedrock for managed compliance, or hybrid de-identification for maximum privacy.

5. Claude is an assistant, not an autonomous decision-maker: Always require human review and approval before finalising clinical or billing decisions.

6. Start with a pilot, not a full rollout: Test with a small group, collect feedback, and refine before deploying organisation-wide.

7. Compliance is ongoing, not one-time: Conduct regular audits, monitor for breaches, and iterate based on learnings.

Deploying Claude for healthcare is feasible and valuable when done correctly. The organisations achieving the best outcomes are those that treat compliance as a feature, not a burden—and that involve their teams in the design from the start.

---

Conclusion

Claude represents a genuine opportunity for healthcare organisations to improve efficiency, reduce administrative burden, and enhance clinical decision-making—while maintaining full HIPAA compliance. The technical infrastructure is sound. The legal framework (BAA) is clear. The healthcare-specific capabilities (ICD-10, CMS, NPI, FHIR) are purpose-built.

What matters now is execution. The organisations that will lead in AI-powered healthcare are those that invest in compliance from day one, involve their teams in design, and measure success by outcomes—not by features shipped.

If you’re ready to explore Claude for your healthcare organisation, start with the assessment phase outlined above. Understand your current state, identify gaps, and build a roadmap. Then engage a partner (like PADISO) who understands both healthcare and AI to help you navigate the technical and compliance complexities.

The future of healthcare is AI-augmented. The organisations that get it right will deliver better care, faster, with less administrative burden. The organisations that cut corners on compliance will face audits, fines, and loss of trust. The choice is yours.

---

Additional Resources

For more information on healthcare AI and compliance, explore these PADISO resources:

• AI Automation for Healthcare: Diagnostic Tools and Patient Care — Discover implementation strategies and best practices
• AI Automation Agency Sydney — Learn how to partner with an AI agency for healthcare transformation
• Security Audit: SOC 2, ISO 27001 & GDPR Compliance — Achieve compliance with expert support
• Case Studies — See real healthcare organisations achieving results with AI

For external resources on Claude and HIPAA compliance, refer to Anthropic’s official healthcare announcement, Claude’s HIPAA-ready Enterprise plans documentation, and HHS guidance on AI and HIPAA.