Microsoft Copilot for Healthcare: Clinical Documentation and EHR Integration

Healthcare organizations face a unique challenge when deploying Microsoft 365 Copilot: balancing AI-powered productivity gains with strict regulatory requirements for patient data protection. Clinical documentation represents up to 40% of physician time, yet introducing AI into clinical workflows requires navigating HIPAA compliance, Business Associate Agreements, audit trails, and the technical complexity of integrating with Electronic Health Record (EHR) systems.

This isn't about whether Copilot can draft a SOAP note faster than a physician typing manually. It's about whether your deployment architecture prevents Protected Health Information (PHI) leakage, satisfies HIPAA's minimum necessary standard, maintains audit logs for compliance investigations, and integrates with EHR platforms like Epic, Cerner, and Meditech without violating data residency requirements.

Healthcare CIOs deploying Copilot discover quickly that clinical use cases demand fundamentally different security controls than general business applications. A physician asking Copilot to "summarize Mrs. Johnson's recent lab results" triggers a chain of technical dependencies: EHR API authentication, role-based access controls, sensitivity labeling for PHI, real-time audit logging, and conditional access policies that prevent data exfiltration.

Here's what actually breaks when you deploy Copilot in healthcare—and how to architect around those failures.

The Healthcare AI Compliance Challenge

Microsoft 365 Copilot operates as a large language model (LLM) that accesses content through Microsoft Graph API. In healthcare environments, that content includes PHI stored across SharePoint sites, OneDrive folders, Teams conversations, Outlook emails, and increasingly, data synchronized from EHR systems.

The fundamental problem: HIPAA requires that PHI access follows the "minimum necessary" standard—users should only access the specific PHI required to perform their job function. Copilot's semantic search capabilities retrieve information based on contextual understanding, which can violate minimum necessary requirements if permissions aren't properly scoped.

What breaks in practice:

• A billing clerk asks Copilot for "patient insurance information for January claims." Copilot retrieves clinical notes from SharePoint because the billing team has read access to the clinical documentation library (technical permissions are correct, but functional access violates HIPAA).
• A physician asks Copilot to draft a discharge summary. Copilot includes information from another patient's chart because both records were discussed in the same Teams channel (contextual retrieval creates a privacy breach).
• An external consultant working on a quality improvement project uses Copilot, which surfaces patient identifiers from archived documents that should have been de-identified (retention policies weren't enforced, creating a Business Associate Agreement violation).

Root cause analysis:

• Microsoft 365 permission model doesn't align with HIPAA's minimum necessary standard
• SharePoint sites and Teams channels were designed for collaboration, not patient-record isolation
• Sensitivity labels for PHI aren't consistently applied across content repositories
• EHR data synchronized to Microsoft 365 lacks proper access controls
• Audit logging doesn't capture sufficient detail for HIPAA compliance investigations

Technical remediation: Healthcare organizations need permission architectures that enforce role-based access, sensitivity labels that automatically classify PHI, DLP policies that block inappropriate Copilot queries, and comprehensive audit trails that satisfy OCR (Office for Civil Rights) investigation requirements.

Clinical Documentation Use Cases

Copilot's highest-value healthcare applications target clinical documentation workloads where physician burnout is directly correlated with administrative burden. The technical challenge is enabling these use cases while maintaining PHI protection.

SOAP Note Generation

Use case: Physician dictates patient encounter details, Copilot drafts a structured SOAP (Subjective, Objective, Assessment, Plan) note in real-time, physician reviews and signs.

Technical architecture:

• Physician uses Copilot in Microsoft Word with EHR-integrated templates
• Copilot accesses patient context from EHR API (read-only via FHIR or proprietary Epic/Cerner API)
• Draft note is generated with PHI sensitivity label automatically applied
• DLP policy prevents copying draft to non-PHI-protected locations (personal OneDrive, external email)
• Audit log captures prompt, retrieved data sources, and final document signature

Implementation complexity:

• EHR API authentication requires OAuth 2.0 with SMART on FHIR for Epic/Cerner
• Patient context must be passed securely (no PHI in URL parameters or browser history)
• Copilot must distinguish between "current patient" and "other patients mentioned in recent charts"
• Auto-save functionality must respect PHI retention policies (no persistent copies outside EHR)

Permission model:

# Configure sensitivity label for clinical documentation
$labelConfig = @{
    Name = "PHI - Clinical Documentation"
    Comment = "Applies to all documents containing protected health information"
    EncryptionEnabled = $true
    EncryptionProtectionType = "Template"
    EncryptionRightsDefinitions = @{
        "Physicians" = "View,Edit,Save"
        "Nurses" = "View"
        "Billing" = "None"
    }
    SiteAndGroupProtectionEnabled = $true
    ContentType = "File, Email, Site"
}

New-Label @labelConfig -AdvancedSettings @{
    copilotAccess = "RestrictedToPrimaryCareClinicians"
    phiClassification = "ClinicalDocumentation"
}

Risk mitigation:

• Physician must review 100% of AI-generated content before signing (no auto-commit to EHR)
• Version control tracks all edits between Copilot draft and final note
• DLP policy blocks Copilot from accessing PHI if physician's session doesn't have active EHR context
• Conditional access requires MFA and compliant device for Copilot access to clinical content

Discharge Summary Automation

Use case: At patient discharge, Copilot aggregates hospital stay information (admission notes, daily progress notes, lab results, imaging reports, procedures) and generates a comprehensive discharge summary.

Technical architecture:

• Copilot accesses EHR data via HL7 FHIR API
• Data retrieval limited to single patient encounter (enforced via API scope)
• Discharge summary template pre-populated with structured data elements
• Physician reviews, edits, and approves summary before EHR commit

HIPAA compliance challenges:

• Copilot's semantic search might retrieve data from similar but incorrect patient encounters
• Discharge summary includes sensitive diagnoses that require explicit consent for certain conditions (HIV, substance abuse, mental health)
• If discharge summary is stored in SharePoint (common for teaching hospitals), access controls must prevent unauthorized viewing

DLP policy configuration:

# Block Copilot from including certain diagnosis codes in discharge summaries
New-DlpComplianceRule -Name "Block Restricted Diagnoses in Copilot" `
    -ContentContainsSensitiveInformation @{
        Name = "ICD-10 Substance Abuse Codes"
        MinCount = 1
    } `
    -GenerateAlert $true `
    -NotifyUser "Physician" `
    -BlockAccess $true `
    -BlockAccessScope "PerUser"

Integration pattern:

• Copilot must query EHR using patient-specific API token (no broad "all patients" access)
• EHR system logs all API queries for HIPAA audit trails
• Discharge summary generation triggers workflow approval before SharePoint storage

Prior Authorization Request Drafting

Use case: Copilot drafts prior authorization requests for insurance companies by aggregating clinical documentation, treatment plans, and medical necessity justifications.

Technical value: Prior authorizations consume significant administrative time (average 15 minutes per request, 30+ requests per physician per week). Automating this workflow saves 7-8 hours per physician weekly.

Compliance risk: Prior authorization requests often contain more PHI than necessary for insurance review, violating minimum necessary standard. Copilot must be configured to include only clinically relevant information.

Technical architecture:

• Physician initiates prior auth request from EHR workflow
• Copilot accesses patient chart, treatment plan, and relevant clinical guidelines
• AI generates draft with only information required by insurance policy (no extraneous PHI)
• Billing team reviews and submits (Copilot doesn't have direct external submission capability)

Security control: DLP policy prevents Copilot from including social history, family history, or unrelated diagnoses in prior auth drafts. This requires custom sensitive information types in Microsoft Purview that recognize clinical documentation structures.

EHR Integration Patterns: Epic, Cerner, Meditech

Healthcare organizations don't have the luxury of standalone Microsoft 365 deployments. Clinical workflows depend on EHR systems, meaning Copilot's value depends entirely on integration architecture.

Epic Integration via SMART on FHIR

Epic's approach: Epic supports SMART on FHIR (Substitutable Medical Applications Reusable Technologies on Fast Healthcare Interoperability Resources), enabling third-party applications to access EHR data via standardized API.

Copilot integration architecture:

1. Physician launches Copilot-enabled application from Epic App Orchard
2. SMART on FHIR authentication establishes OAuth 2.0 session with patient context
3. Copilot queries Epic API for specific data elements (e.g., "Get recent lab results for current patient")
4. Epic returns FHIR-formatted JSON response
5. Copilot processes data and generates clinical documentation
6. Draft is reviewed and committed back to Epic via API write operation

Technical requirements:

• Epic App Orchard registration and certification
• OAuth 2.0 client credentials with specific FHIR scopes (e.g., patient/Observation.read, patient/Condition.read)
• Epic environment must support FHIR R4 standard (requires Epic version 2018 or later)
• Healthcare organization must enable "external API access" in Epic security settings

Implementation example (pseudocode for FHIR query):

// Authenticate with Epic FHIR endpoint
const authResponse = await fetch('https://fhir.epic.com/oauth2/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
        grant_type: 'client_credentials',
        client_id: 'copilot-app-client-id',
        client_secret: 'secret',
        scope: 'patient/Observation.read'
    })
});

const accessToken = authResponse.json().access_token;

// Query patient observations (lab results)
const patientId = getPatientContextFromEpicSession();
const labResults = await fetch(`https://fhir.epic.com/api/FHIR/R4/Observation?patient=${patientId}&category=laboratory`, {
    headers: { 'Authorization': `Bearer ${accessToken}` }
});

// Pass data to Copilot for summarization
const copilotSummary = await copilot.generateClinicalSummary(labResults.json());

Security controls:

• Access token expires after 1 hour (requires re-authentication)
• Epic audit logs capture all API queries with user identity and patient context
• FHIR scopes limit data access (physician can't access administrative/billing data)

Limitation: Epic's FHIR API doesn't expose all clinical data elements. Some workflows require proprietary Epic Web Services API, which is more complex to integrate.

Cerner (Oracle Health) Integration

Cerner's approach: Similar to Epic, Cerner supports FHIR-based API access. However, Cerner's implementation varies across healthcare organizations due to customization.

Integration differences from Epic:

• Cerner requires separate API registration per healthcare organization (no centralized app marketplace)
• FHIR resource coverage varies depending on Cerner version and organizational configuration
• Some Cerner instances require VPN or on-premises network access (no cloud-based API endpoint)

Copilot integration pattern:

1. Healthcare IT team registers Copilot application in Cerner Code Console
2. Obtain FHIR API credentials (client ID, client secret, token endpoint)
3. Copilot authenticates using OAuth 2.0 with organizational FHIR server
4. Query patient data using FHIR R4 standard
5. Return data to Copilot for clinical documentation generation

Deployment complexity: Cerner integration requires healthcare organization's IT team to manage API registration, credential rotation, and network access. This is more operationally intensive than Epic's App Orchard model.

Meditech Integration Challenges

Meditech's limitation: Unlike Epic and Cerner, Meditech has historically lacked robust FHIR API support. Older Meditech versions (Magic, Client-Server) require custom HL7 interfaces or proprietary API access.

Integration options:

1. HL7 messaging: Copilot triggers HL7 ADT (Admission, Discharge, Transfer) or ORU (Observation Result) messages to query patient data. Requires middleware (e.g., Mirth Connect) to translate HL7 to REST API for Copilot consumption.
2. Meditech Data Repository (DR): Query clinical data warehouse instead of production EHR. Adds latency but reduces impact on clinical systems.
3. Meditech Expanse FHIR API: Newer Meditech Expanse platform supports FHIR R4, enabling similar integration pattern to Epic/Cerner. However, many healthcare organizations haven't upgraded to Expanse.

Copilot deployment recommendation for Meditech environments: Start with non-clinical use cases (administrative documentation, clinical education, policy drafting) until EHR integration architecture is validated. Attempting clinical documentation without reliable EHR API access creates physician workflow disruptions.

HIPAA Compliance Requirements for Copilot

Deploying Copilot in healthcare requires compliance with HIPAA's Privacy Rule, Security Rule, and Breach Notification Rule. Microsoft provides a Business Associate Agreement (BAA) for Microsoft 365, but that BAA doesn't automatically make your Copilot deployment compliant.

Business Associate Agreement (BAA)

What Microsoft's BAA covers:

• Microsoft 365 services (Exchange, SharePoint, OneDrive, Teams)
• Azure services used for PHI processing
• Copilot for Microsoft 365 (as of 2024, Copilot is BAA-covered)

What Microsoft's BAA doesn't cover:

• Your organization's permission misconfigurations that expose PHI
• Third-party plugins or Copilot Studio extensions you build
• PHI in prompt logs if you enable Copilot chat history

Critical BAA requirement: Healthcare organizations must sign Microsoft's BAA before processing PHI in Microsoft 365. Without a BAA, using Copilot with PHI is a HIPAA violation.

How to verify BAA coverage:

# Check if your Microsoft 365 tenant has BAA coverage
Connect-MsolService
Get-MsolCompanyInformation | Select-Object CompanyType, PartnerCompanyName

# Verify Copilot services are included in BAA
# (Manual verification required via Microsoft Healthcare Privacy Agreement)

PHI Protection Strategies

HIPAA's Security Rule requires administrative, physical, and technical safeguards for PHI. In Copilot deployments, technical safeguards are most critical.

Required technical safeguards:

1. Access controls: Only authorized users (physicians, nurses, care coordinators) can use Copilot to query PHI.
2. Audit trails: All Copilot interactions with PHI must be logged and retained for 6 years (HIPAA minimum).
3. Encryption: PHI must be encrypted at rest and in transit (Microsoft 365 provides this by default, but verify configurations).
4. Data integrity: Mechanisms to detect unauthorized PHI modification (version history, audit logs).
5. Authentication: Multi-factor authentication (MFA) required for all Copilot access to PHI.

Conditional access policy for clinical Copilot access:

# Require MFA and compliant device for Copilot access to PHI-labeled content
New-AzureADMSConditionalAccessPolicy -DisplayName "Copilot PHI Access Controls" `
    -State "Enabled" `
    -Conditions @{
        Applications = @{ IncludeApplications = "Microsoft 365 Copilot" }
        Users = @{ IncludeGroups = "ClinicalStaff" }
    } `
    -GrantControls @{
        Operator = "AND"
        BuiltInControls = @("mfa", "compliantDevice")
    } `
    -SessionControls @{
        SignInFrequency = @{ Value = 1; Type = "Hours" }
    }

Sensitivity label for PHI:

# Create PHI sensitivity label with encryption and access restrictions
New-Label -Name "PHI - Protected Health Information" `
    -Comment "HIPAA-protected patient data" `
    -EncryptionEnabled $true `
    -EncryptionProtectionType "Template" `
    -EncryptionRightsDefinitions @{
        "ClinicalStaff" = "View,Edit,Save,Print"
        "BillingStaff" = "View"
        "AllEmployees" = "None"
    } `
    -AdvancedSettings @{
        blockCopilotAccess = "Restrict to authorized clinical users"
        phiCategory = "HIPAA-Protected"
    }

Audit Logging for Clinical Use

HIPAA requires healthcare organizations to log all PHI access events. Microsoft Purview Premium Audit provides the necessary logging, but you must configure it correctly.

Required audit log events:

• Copilot query that retrieved PHI
• User identity (physician, nurse, etc.)
• Patient identifier (if available in query context)
• Data sources accessed (SharePoint, EHR API, Teams)
• Timestamp (precise to the second)
• Access outcome (success, denied, error)

Enable Premium Audit for HIPAA:

# Enable Premium Audit with 10-year retention for PHI access logs
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

New-UnifiedAuditLogRetentionPolicy -Name "HIPAA PHI Access Logs" `
    -RecordTypes CopilotInteraction, SharePointFileOperation, ExchangeItem `
    -RetentionDuration TenYears `
    -Priority 1

# Query Copilot PHI access events
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -RecordType CopilotInteraction `
    -ResultSize 5000 |
Where-Object { $_.AuditData -like "*PHI*" } |
Export-Csv -Path "C:\Audit\CopilotPHIAccess.csv" -NoTypeInformation

SIEM integration: Healthcare organizations should forward Copilot audit logs to a SIEM platform (Microsoft Sentinel, Splunk, or similar) for real-time alerting on anomalous PHI access patterns.

Alert example: Trigger investigation if a user queries Copilot for PHI outside normal work hours, accesses >50 patient records in a single session, or queries PHI for patients not on their care team roster.

Security Controls Specific to Healthcare

Healthcare Copilot deployments require security controls beyond standard enterprise configurations.

Role-Based Access Controls (RBAC)

Challenge: Healthcare organizations have complex role structures (attending physician, resident, nurse practitioner, physician assistant, medical assistant, billing specialist, case manager). Each role has different PHI access requirements.

Copilot RBAC model:

• Map Azure AD security groups to clinical roles
• Apply sensitivity labels with role-specific permissions
• Configure DLP policies that enforce role-based restrictions
• Use Copilot Studio to create role-specific Copilot agents with limited data scope

Example RBAC structure:

Role: Attending Physician
- Full access to patient charts (all clinical documentation)
- Can use Copilot for SOAP notes, discharge summaries, clinical research

Role: Medical Assistant
- Limited access (vital signs, scheduling, patient demographics)
- Can use Copilot for appointment summaries, referral letters
- Cannot access psychiatric notes, HIV status, substance abuse history

Role: Billing Specialist
- Access to billing codes, insurance information, claims
- Can use Copilot for prior authorization drafting
- Cannot access clinical notes, lab results, imaging reports

Data Residency and Sovereignty

Healthcare organizations in certain jurisdictions (EU, Switzerland, Canada) face data residency requirements that restrict where PHI can be processed.

Microsoft 365 data residency options:

• Multi-Geo: Store data in specific geographic regions (EU, Canada, Australia)
• Advanced Data Residency: Guarantees data processing stays within specified region
• Azure Government: For U.S. government and DoD healthcare facilities

Copilot data residency consideration: Copilot processes data using Azure OpenAI Service. Verify that your Copilot deployment uses Azure OpenAI instances in compliant regions (e.g., EU Azure OpenAI for GDPR compliance).

Configuration verification:

# Check Microsoft 365 tenant data location
Get-MsolCompanyInformation | Select-Object PreferredDataLocation

# Verify Advanced Data Residency is enabled
Get-OrganizationConfig | Select-Object IsAdvancedDataResidencyEnabled

Zero Trust Architecture for Clinical Access

Healthcare Copilot deployments should implement Zero Trust principles:

• Verify explicitly (MFA, device compliance)
• Use least privilege access (role-based permissions)
• Assume breach (audit all access, segment networks)

Zero Trust implementation for Copilot:

1. Conditional access policies require MFA + compliant device
2. Continuous access evaluation (CAE) terminates sessions if user leaves hospital network
3. DLP policies block data exfiltration (no copying PHI to personal devices)
4. Sensitivity labels enforce encryption and access restrictions
5. Audit logs feed into SIEM for anomaly detection

Workflow Optimization Examples

Case study 1: Academic Medical Center

• Challenge: Resident physicians spend 3 hours per day on clinical documentation, contributing to burnout.
• Solution: Deployed Copilot for SOAP note generation, integrated with Epic via SMART on FHIR.
• Result: Reduced documentation time by 45%, improved resident satisfaction scores by 30%.
• Technical architecture: Copilot accessed Epic API with patient-specific scopes, applied PHI sensitivity labels automatically, required attending physician review before EHR commit.

Case study 2: Community Hospital

• Challenge: Prior authorization requests average 20 minutes per submission, delaying patient care.
• Solution: Copilot drafts prior auth requests using EHR data and insurance policy guidelines stored in SharePoint.
• Result: Reduced prior auth time to 8 minutes (60% improvement), improved approval rates from 70% to 85% (more complete medical necessity justifications).
• Technical architecture: Copilot Studio agent trained on insurance policy documents, integrated with Cerner API, DLP policies ensured minimum necessary PHI in requests.

Case study 3: Multi-Site Health System

• Challenge: Discharge summary quality varied across 15 hospitals, contributing to readmission rates.
• Solution: Standardized discharge summary templates with Copilot automation, pulling data from EHR and clinical pathways library.
• Result: Improved discharge summary completeness by 40%, reduced 30-day readmission rate by 12% (better patient/family understanding of post-discharge care plans).
• Technical architecture: Copilot accessed Epic FHIR API, used sensitivity labels to restrict access to care coordination team, audit logs tracked all summary generations for quality review.

Deployment Roadmap for Healthcare Organizations

Phase 1: Governance foundation (Weeks 1-4)

• Execute Microsoft Business Associate Agreement
• Conduct permission audit across SharePoint, OneDrive, Teams
• Configure sensitivity labels for PHI
• Deploy DLP policies to block inappropriate Copilot access
• Enable Premium Audit with 10-year retention

Phase 2: Pilot deployment (Weeks 5-8)

• Select pilot group (10-20 physicians, single specialty)
• Configure Copilot access with conditional access policies
• Integrate with EHR (read-only API access initially)
• Train clinicians on prompt engineering and PHI protection
• Monitor audit logs daily for compliance issues

Phase 3: EHR integration (Weeks 9-12)

• Expand EHR API access to include write operations (discharge summaries, prior auth requests)
• Implement FHIR-based data retrieval for SOAP notes
• Configure role-based access controls aligned with clinical roles
• Deploy Copilot Studio agents for specialized workflows (oncology, cardiology, surgery)

Phase 4: Production rollout (Weeks 13-16)

• Expand to 100+ clinicians across multiple specialties
• Enable Copilot for non-physician roles (nurse practitioners, physician assistants)
• Integrate with quality improvement workflows (readmission reduction, sepsis screening)
• Establish ongoing audit log review process (monthly compliance reports)

Phase 5: Optimization (Ongoing)

• Measure clinical documentation time savings
• Track physician satisfaction and burnout metrics
• Refine DLP policies based on false positive rates
• Expand EHR integration to include additional data sources (lab systems, imaging archives)

Frequently Asked Questions

Is Microsoft Copilot approved for clinical use with patient data?

Microsoft 365 Copilot is covered under Microsoft's Business Associate Agreement (BAA) for HIPAA compliance, making it legally permissible for processing Protected Health Information (PHI). However, "approved for clinical use" depends on your organization's deployment architecture. You must implement proper access controls, sensitivity labels, DLP policies, audit logging, and EHR integration patterns. Simply licensing Copilot doesn't make it clinically appropriate—you need governance frameworks that enforce role-based access, prevent PHI oversharing, and maintain audit trails for compliance investigations. Healthcare organizations should complete a Privacy Impact Assessment (PIA) before clinical deployment.

How does Microsoft Copilot integrate with my EHR system?

Integration depends on your EHR vendor. Epic and Cerner support FHIR (Fast Healthcare Interoperability Resources) APIs that allow Copilot to query patient data using standardized OAuth 2.0 authentication. Epic's SMART on FHIR framework enables context-aware access (Copilot knows which patient the physician is currently viewing). Meditech integration is more complex, often requiring HL7 messaging middleware or querying the clinical data repository. Technical implementation requires EHR API credentials, FHIR resource scopes aligned with clinical roles, and audit logging of all API queries. Integration is bidirectional: Copilot can read EHR data for documentation generation and write completed notes back to the EHR via API. Organizations should start with read-only access during pilot phases.

Is Microsoft Copilot HIPAA compliant?

Microsoft provides HIPAA compliance through its Business Associate Agreement, which covers Copilot for Microsoft 365 and underlying Azure services. However, HIPAA compliance is a shared responsibility model. Microsoft secures the infrastructure, but your organization must configure access controls, sensitivity labels, DLP policies, audit logging, and user training. Common HIPAA violations in Copilot deployments: (1) Over-permissioned SharePoint sites that expose PHI to unauthorized users, (2) Missing sensitivity labels that prevent DLP enforcement, (3) Insufficient audit log retention (HIPAA requires 6 years minimum), (4) Lack of Business Associate Agreements with Microsoft. Compliance requires technical controls (encryption, access restrictions) and administrative safeguards (policies, training, audit reviews). Organizations should engage HIPAA legal counsel before clinical deployment.

What security controls are required for clinical Copilot deployment?

Clinical Copilot deployments require five categories of security controls: (1) Authentication and authorization: Multi-factor authentication (MFA) for all clinical users, conditional access policies requiring compliant devices, role-based access controls aligned with HIPAA's minimum necessary standard. (2) Data protection: Sensitivity labels with encryption for PHI, DLP policies that block inappropriate data retrieval, external sharing restrictions preventing PHI leakage. (3) Audit and monitoring: Microsoft Purview Premium Audit with 10-year retention, SIEM integration for real-time alerting, audit log reviews in case of compliance investigations. (4) EHR integration security: OAuth 2.0 authentication with FHIR scopes limiting data access, patient-specific API tokens preventing broad data queries, audit trails in EHR system logging all Copilot API requests. (5) Incident response: Breach notification procedures, data breach investigation workflows, user access revocation capabilities. Healthcare organizations should review Microsoft's Security Baseline for Microsoft 365 and customize for clinical workflows.

Can Copilot access psychiatric notes or substance abuse records?

By default, yes—if a user has permission to access that content, Copilot can retrieve it. However, 42 CFR Part 2 (federal substance abuse confidentiality regulations) and state laws often impose stricter access controls on substance abuse treatment records. Best practice: Store substance abuse and psychiatric records in separate SharePoint libraries with explicit permission grants (no inherited permissions from parent sites). Apply custom sensitivity labels that block Copilot access unless the user is directly involved in the patient's care. Configure DLP policies that detect ICD-10 codes for substance abuse (F10-F19) and mental health conditions, triggering administrator review before Copilot can surface that content. EHR integration should exclude "break-the-glass" records that require explicit consent before access. Audit all access to sensitive diagnoses and investigate anomalous queries.