HIPAA Compliance with Microsoft 365 Copilot: What Healthcare Organizations Need to Know

Microsoft 365 Copilot introduces Protected Health Information (PHI) exposure risks that most healthcare organizations haven't considered. The AI doesn't distinguish between clinical notes, billing records, and cafeteria menus—it retrieves whatever the user has access to. If your SharePoint sites contain unencrypted PHI, and your employees have overly broad permissions, Copilot becomes a HIPAA violation waiting to happen.

This isn't about whether Microsoft's infrastructure is HIPAA-compliant. Microsoft offers a Business Associate Agreement (BAA) and maintains SOC 2 Type II attestation. The question is whether your implementation meets the HIPAA Security Rule's administrative, physical, and technical safeguards—specifically §164.312(a)(1) access controls and §164.312(b) audit controls.

Healthcare CIOs face a binary choice: implement proper PHI governance before Copilot deployment, or wait for the first breach notification and OCR investigation. Here's the technical framework for the former.

HIPAA Security Rule Requirements: What Applies to Copilot

The HIPAA Security Rule (45 CFR §§ 164.302-318) establishes three categories of safeguards. Copilot deployment impacts all three, but technical safeguards are where most healthcare organizations fail.

Administrative Safeguards (§164.308)

§164.308(a)(1) - Security Management Process: Requires risk analysis and risk management procedures. For Copilot, this means:

• Documenting where PHI is stored across Microsoft 365
• Identifying who has access to PHI-containing documents
• Analyzing how Copilot's semantic search exposes PHI
• Implementing controls to mitigate identified risks

§164.308(a)(3) - Workforce Security: Requires procedures to ensure workforce members have appropriate access to ePHI. Copilot surfaces this requirement's most common failure: access granted once but never revoked.

§164.308(a)(4) - Information Access Management: The "minimum necessary" standard. Copilot violates this by design unless you implement content-level access controls, not just site-level permissions.

Physical Safeguards (§164.310)

Less relevant for Copilot since it's cloud-based, but §164.310(d) requires device and media controls. This matters for:

• Mobile device access to Copilot
• Downloading PHI retrieved by Copilot to unmanaged devices
• Printing PHI from Copilot responses

Technical Safeguards (§164.312)

§164.312(a)(1) - Access Control: Required implementation specification. You must implement technical policies and procedures to allow access only to authorized persons. For Copilot:

• Unique user identification (Required): Azure AD accounts, MFA enforcement
• Emergency access procedure (Required): Break-glass accounts for Copilot admin access
• Automatic logoff (Addressable): Session timeouts for Copilot interfaces
• Encryption and decryption (Addressable): Sensitivity labels with encryption for PHI

§164.312(b) - Audit Controls: Required implementation specification. You must implement hardware, software, and procedural mechanisms to record and examine access to ePHI. For Copilot:

• Microsoft Purview Audit (Premium tier required)
• Retention of audit logs for 6 years (OCR requirement)
• Monitoring of Copilot queries that retrieve PHI
• SIEM alerting for anomalous PHI access patterns

§164.312(c)(1) - Integrity: Addressable implementation specification. Electronic PHI must not be improperly altered or destroyed. For Copilot:

• Sensitivity labels preventing modification
• Version control in SharePoint
• DLP policies blocking copy/paste of PHI from Copilot

§164.312(e)(1) - Transmission Security: Addressable implementation specification. Technical security measures to guard against unauthorized access to ePHI transmitted over electronic networks. For Copilot:

• TLS 1.3 for all Copilot API communications (Microsoft default)
• Conditional Access policies requiring managed devices
• Network isolation for Copilot traffic (Azure Private Link)

What Breaks: PHI Exposure Scenarios with Copilot

Scenario 1: Clinical Notes Retrieval by Non-Clinical Staff

The setup: A hospital's SharePoint site structure includes a "Patient Care" library where nurses upload clinical notes. Site permissions grant all employees read access because "everyone needs to find the forms."

What breaks: An HR coordinator asks Copilot "What complications did we see in orthopedic surgeries last month?" Copilot retrieves clinical notes containing patient names, MRNs, and surgical outcomes. The HR coordinator has read access to the SharePoint site (technically compliant with permissions) but no legitimate need for PHI (violation of minimum necessary standard).

HIPAA violation:

• §164.502(b) - Minimum necessary requirement
• §164.308(a)(4)(i) - Information access management
• §164.312(a)(1) - Access control

Technical root cause: SharePoint permissions granted at site level without document-level access controls. Clinical notes lack sensitivity labels. No DLP policy restricts Copilot access to PHI.

Remediation:

# Identify all documents in Patient Care library without sensitivity labels
$siteUrl = "https://contoso.sharepoint.com/sites/ClinicalOps"
$libraryName = "Patient Care"

Connect-PnPOnline -Url $siteUrl -Interactive
$items = Get-PnPListItem -List $libraryName -PageSize 1000

$unlabeled = @()
foreach ($item in $items) {
    if (-not $item.FieldValues._SensitivityLabel) {
        $unlabeled += [PSCustomObject]@{
            FileName = $item.FieldValues.FileLeafRef
            CreatedDate = $item.FieldValues.Created
            ModifiedDate = $item.FieldValues.Modified
            Author = $item.FieldValues.Author.LookupValue
        }
    }
}

$unlabeled | Export-Csv -Path "C:\Audit\UnlabeledPHI.csv" -NoTypeInformation

Scenario 2: Billing Records Exposed Through Historical Access

The setup: A former billing department employee transferred to marketing 18 months ago. Their account still has access to the Billing SharePoint site because nobody processed the access removal workflow.

What breaks: The employee asks Copilot "What was our revenue from cardiology last quarter?" Copilot retrieves billing records with patient names, insurance information, and payment details from the Billing site. The employee hasn't thought about those records in 18 months, but Copilot remembers the access grants.

HIPAA violation:

• §164.308(a)(3)(ii)(C) - Termination procedures (transfer = partial termination)
• §164.312(a)(1) - Access control
• §164.308(a)(1)(ii)(D) - Information system activity review

Technical root cause: No automated access certification process. Permissions granted indefinitely. No time-based access controls. Audit logs not reviewed for dormant account activity.

Remediation:

# Identify users with SharePoint access but no activity in 90+ days
$inactiveDays = 90
$cutoffDate = (Get-Date).AddDays(-$inactiveDays)
$sites = Get-SPOSite -Limit All -Filter "Title -like '*Billing*' -or Title -like '*Patient*'"

foreach ($site in $sites) {
    $users = Get-SPOUser -Site $site.Url
    foreach ($user in $users) {
        # Query audit log for last activity
        $activity = Search-UnifiedAuditLog -StartDate $cutoffDate -EndDate (Get-Date) `
            -UserIds $user.LoginName -RecordType SharePointFileOperation `
            -ResultSize 1

        if (-not $activity) {
            Write-Output "$($user.LoginName) has access to $($site.Url) but no activity in $inactiveDays days"
            # Optional: Remove access automatically
            # Remove-SPOUser -Site $site.Url -LoginName $user.LoginName
        }
    }
}

Scenario 3: Research Data Without Proper De-Identification

The setup: A research team uses Microsoft 365 to collaborate on a clinical trial. They believe they de-identified the data by removing patient names, but MRNs and dates of service remain in spreadsheets stored in OneDrive.

What breaks: A data analyst asks Copilot "Show me patient outcomes from the diabetes trial." Copilot retrieves spreadsheets with MRNs and dates of service—18 identifiers under HIPAA's Safe Harbor method. The data isn't de-identified. It's still PHI, and now it's accessible through Copilot to anyone with OneDrive access.

HIPAA violation:

• §164.514(b) - De-identification requirements
• §164.312(a)(1) - Access control
• §164.530(c) - Safeguards for PHI

Technical root cause: Incomplete de-identification process. No technical controls preventing re-identification. Spreadsheets stored in personal OneDrive without encryption. No sensitivity labels marking research data as PHI.

Safe Harbor de-identification checklist (all 18 identifiers must be removed):

1. Names
2. Geographic subdivisions smaller than state (including ZIP codes)
3. Dates (except year) related to the individual
4. Telephone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers (MRNs)
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers and serial numbers
13. Device identifiers and serial numbers
14. URLs
15. IP addresses
16. Biometric identifiers
17. Full-face photos
18. Any other unique identifying number

Validation script:

# Scan Excel files for potential PHI identifiers using regex patterns
$oneDrivePath = "C:\Users\analyst\OneDrive - Contoso\Research"
$excelFiles = Get-ChildItem -Path $oneDrivePath -Filter "*.xlsx" -Recurse

$phiPatterns = @{
    SSN = "\d{3}-\d{2}-\d{4}"
    MRN = "MRN[:\s]*\d{6,10}"
    Email = "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"
    Phone = "\d{3}[-.\s]?\d{3}[-.\s]?\d{4}"
    ZipCode = "\d{5}(-\d{4})?"
}

foreach ($file in $excelFiles) {
    $excel = New-Object -ComObject Excel.Application
    $excel.Visible = $false
    $workbook = $excel.Workbooks.Open($file.FullName)

    foreach ($worksheet in $workbook.Worksheets) {
        $usedRange = $worksheet.UsedRange
        $content = $usedRange.Text

        foreach ($pattern in $phiPatterns.GetEnumerator()) {
            if ($content -match $pattern.Value) {
                Write-Warning "Potential $($pattern.Key) found in $($file.Name) - Sheet: $($worksheet.Name)"
            }
        }
    }

    $workbook.Close($false)
    $excel.Quit()
}

Business Associate Agreement (BAA) Requirements

Microsoft offers a BAA for Microsoft 365, covering services listed in the Microsoft Product Terms. Copilot is included, but the BAA doesn't exempt you from implementing proper safeguards.

What the BAA Covers

• §164.504(e)(2)(i) - Business associate must not use or disclose PHI except as permitted by the agreement
• §164.504(e)(2)(ii)(A) - Business associate must implement safeguards to prevent unauthorized use or disclosure
• §164.504(e)(2)(ii)(B) - Business associate must report breaches to covered entity
• §164.504(e)(2)(ii)(H) - Business associate must make PHI available for amendment
• §164.504(e)(2)(ii)(I) - Business associate must provide accounting of disclosures

What the BAA Doesn't Cover

Microsoft's BAA protects their infrastructure—not your implementation. You remain responsible for:

• Access controls: Who can use Copilot to retrieve PHI
• Minimum necessary: Ensuring Copilot only surfaces PHI when justified
• Audit trails: Monitoring who accessed what PHI through Copilot
• Breach notification: Detecting and reporting unauthorized PHI access
• Risk analysis: Identifying and mitigating Copilot-specific risks

Obtaining the Microsoft BAA

Healthcare organizations must sign Microsoft's BAA through one of these methods:

1. Enterprise Agreement (EA): BAA executed as part of enterprise licensing
2. Microsoft Customer Agreement: BAA amendment available through Microsoft account team
3. Cloud Solution Provider (CSP): BAA executed through CSP partner

Critical: The BAA must be signed before PHI is processed using Microsoft 365 Copilot. Retroactive BAAs don't cure prior violations.

Verification:

# Verify Microsoft 365 tenant has BAA executed
# Check compliance score in Microsoft Purview Compliance Manager
Connect-MgGraph -Scopes "ComplianceManager.Read.All"

$complianceScore = Get-MgComplianceManagerComplianceScore
$hipaaControls = $complianceScore.Controls | Where-Object { $_.Title -like "*HIPAA*" }

$hipaaControls | Select-Object Title, ImplementationStatus, Score |
Export-Csv -Path "C:\Audit\HIPAA-Compliance-Status.csv" -NoTypeInformation

Technical Implementation: HIPAA-Compliant Copilot Deployment

Phase 1: PHI Identification and Classification

Objective: Locate all PHI across Microsoft 365 and apply sensitivity labels.

Implementation steps:

1. Content scan using Microsoft Purview:

# Create custom sensitive information type for MRNs
$mrnPattern = "\b[A-Z]{2}\d{6,8}\b"

New-DlpSensitiveInformationType -Name "Medical Record Number" `
    -Description "Hospital MRN format (2 letters + 6-8 digits)" `
    -Classification "Confidential" `
    -Patterns @{
        Pattern = $mrnPattern
        Confidence = 85
    }

1. Auto-labeling policy for PHI:

# Create auto-labeling policy that applies "PHI - Restricted" label
$labelId = "12345678-1234-1234-1234-123456789012"

New-AutoSensitivityLabelPolicy -Name "Auto-Label PHI Documents" `
    -Comment "Automatically labels documents containing PHI indicators" `
    -SharePointLocation "All" `
    -OneDriveLocation "All" `
    -ExchangeLocation "All" `
    -Mode Enable `
    -ApplySensitivityLabel $labelId `
    -Conditions @{
        ContentContainsSensitiveInformation = @(
            @{ Name = "U.S. Social Security Number (SSN)" }
            @{ Name = "Medical Record Number" }
            @{ Name = "International Classification of Diseases (ICD-10)" }
        )
    }

1. Validation: Use Content Explorer to verify labeling coverage.

Phase 2: Access Control Implementation

Objective: Restrict Copilot access to PHI based on role and clinical necessity.

Implementation steps:

1. Create PHI access security groups in Azure AD:

# Create security groups for PHI access levels
$groups = @(
    "PHI-Clinical-Full-Access",
    "PHI-Billing-Limited-Access",
    "PHI-Research-Deidentified-Only",
    "PHI-Admin-Emergency-Access"
)

foreach ($group in $groups) {
    New-AzureADGroup -DisplayName $group `
        -MailEnabled $false `
        -SecurityEnabled $true `
        -MailNickName $group `
        -Description "HIPAA access group for $group"
}

1. Configure DLP policy to block Copilot for non-authorized users:

# DLP rule: Block Copilot access to PHI unless user is in authorized group
New-DlpComplianceRule -Name "Block Copilot PHI Access" `
    -Policy "HIPAA PHI Protection" `
    -ContentContainsSensitiveInformation @{
        Name = "Medical Record Number"
        MinCount = 1
    } `
    -BlockAccess $true `
    -ExceptIfFrom @("PHI-Clinical-Full-Access@contoso.com") `
    -GenerateIncidentReport "DLPAdmin@contoso.com" `
    -NotifyUser "Owner,LastModifier" `
    -NotifyUserType NotSet

1. Conditional Access policy for managed devices:

# Require compliant devices for Copilot access to PHI
New-AzureADMSConditionalAccessPolicy -DisplayName "Copilot PHI - Require Compliant Device" `
    -State "Enabled" `
    -Conditions @{
        Users = @{
            IncludeGroups = @("PHI-Clinical-Full-Access")
        }
        Applications = @{
            IncludeApplications = @("Microsoft 365 Copilot")
        }
    } `
    -GrantControls @{
        BuiltInControls = @("CompliantDevice", "MFA")
        Operator = "AND"
    }

Phase 3: Audit and Monitoring Configuration

Objective: Capture all Copilot interactions involving PHI and retain logs for 6 years.

Implementation steps:

1. Enable Premium Audit:

# Enable Premium Audit for all users
Set-OrganizationConfig -AuditEnabled $true
Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled $true

# Enable CopilotInteraction event logging
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true `
    -LogLevel Verbose

1. Create 6-year retention policy (OCR requirement):

# Create audit log retention policy for HIPAA compliance
New-UnifiedAuditLogRetentionPolicy -Name "HIPAA Audit Log Retention - 6 Years" `
    -Description "Retains Copilot PHI access logs for 6 years per OCR guidance" `
    -RecordTypes CopilotInteraction,SharePointFileOperation,AzureActiveDirectory `
    -RetentionDuration TenYears `
    -Priority 100

1. SIEM integration for real-time alerting:

# Export Copilot audit logs to Azure Sentinel
$workspaceId = "12345678-1234-1234-1234-123456789012"
$workspaceKey = "base64EncodedKey"

$auditLogs = Search-UnifiedAuditLog -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) `
    -RecordType CopilotInteraction -ResultSize 5000

foreach ($log in $auditLogs) {
    $json = @{
        TimeGenerated = $log.CreationDate
        UserPrincipalName = $log.UserIds
        Operation = $log.Operations
        Workload = $log.RecordType
        AuditData = $log.AuditData | ConvertFrom-Json
    } | ConvertTo-Json

    # Send to Azure Sentinel via HTTP Data Collector API
    Invoke-RestMethod -Method Post -Uri "https://$workspaceId.ods.opinsights.azure.com/api/logs?api-version=2016-04-01" `
        -Headers @{ "Authorization" = "SharedKey $workspaceId:$workspaceKey" } `
        -Body $json
}

Phase 4: Breach Detection and Response

Objective: Detect unauthorized PHI access and trigger breach notification workflow.

Implementation steps:

1. Alert rule for anomalous Copilot PHI queries:

# Create alert policy for Copilot queries retrieving high volumes of PHI
New-ProtectionAlert -Name "Copilot PHI Mass Retrieval" `
    -Category DataGovernance `
    -Description "Alerts when user retrieves more than 50 PHI documents via Copilot in 1 hour" `
    -NotifyUser @("SecurityTeam@contoso.com", "PrivacyOfficer@contoso.com") `
    -Severity High `
    -Condition "CopilotInteraction AND ContentContainsSensitiveInformation:MedicalRecordNumber > 50" `
    -TimeWindow 60

1. Automated incident response workflow:
   • Disable user's Copilot access immediately
   • Lock affected SharePoint sites
   • Generate breach investigation report
   • Notify HIPAA Privacy Officer and Security Officer
   • Document for potential OCR reporting (500+ individuals = mandatory report)

Learn more about our HIPAA Incident Response service.

Compliance Validation and Testing

Before deploying Copilot to clinical users, validate HIPAA compliance through structured testing.

Test Case 1: Minimum Necessary Enforcement

Test: Non-clinical user attempts to retrieve PHI through Copilot.

Expected result: DLP policy blocks access, user receives notification, incident logged.

Validation:

# Test DLP policy effectiveness
$testUser = "hr@contoso.com"
$testQuery = "Show me patient records from cardiology"

# Simulate Copilot query (requires test environment)
# Verify DLP block in audit log
Search-UnifiedAuditLog -StartDate (Get-Date).AddMinutes(-10) -EndDate (Get-Date) `
    -UserIds $testUser -RecordType DLP `
    -Operations "DlpRuleMatch"

Test Case 2: Audit Log Completeness

Test: Clinical user retrieves PHI through Copilot.

Expected result: Audit log captures user identity, timestamp, query text, documents accessed, and sensitivity labels.

Validation:

# Verify audit log contains required HIPAA elements
$auditLog = Search-UnifiedAuditLog -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) `
    -RecordType CopilotInteraction -ResultSize 1000

$requiredFields = @("UserId", "CreationTime", "Operation", "ObjectId", "SensitivityLabel")

foreach ($entry in $auditLog) {
    $auditData = $entry.AuditData | ConvertFrom-Json
    foreach ($field in $requiredFields) {
        if (-not $auditData.$field) {
            Write-Warning "Audit log missing required field: $field"
        }
    }
}

Test Case 3: Breach Detection Alerting

Test: User executes query that retrieves excessive PHI volume.

Expected result: Alert fires within 5 minutes, security team notified, user access suspended.

Validation: Review alert policy execution in Microsoft 365 Defender.

OCR Audit Preparation

The Office for Civil Rights (OCR) conducts HIPAA compliance audits using a risk-based approach. Copilot introduces new areas of focus for auditors.

Documentation OCR will request:

1. Risk analysis documenting Copilot PHI exposure risks
2. BAA with Microsoft covering Copilot service
3. Access control policies defining who can use Copilot for PHI
4. Audit log samples showing Copilot PHI access events
5. Workforce training records on Copilot HIPAA compliance
6. Breach response plan addressing Copilot-specific incidents
7. Sanction policy for unauthorized Copilot PHI access

Prepare evidence packages in advance:

# Generate OCR audit evidence package
$outputPath = "C:\HIPAA-Audit-Evidence"
New-Item -Path $outputPath -ItemType Directory -Force

# 1. Export all Copilot audit logs for past 6 years
Search-UnifiedAuditLog -StartDate (Get-Date).AddYears(-6) -EndDate (Get-Date) `
    -RecordType CopilotInteraction -ResultSize 50000 |
Export-Csv -Path "$outputPath\Copilot-Audit-Logs.csv" -NoTypeInformation

# 2. Export DLP policy configurations
Get-DlpCompliancePolicy | Export-Clixml -Path "$outputPath\DLP-Policies.xml"

# 3. Export sensitivity label configurations
Get-Label | Export-Csv -Path "$outputPath\Sensitivity-Labels.csv" -NoTypeInformation

# 4. Export access control group memberships
$phiGroups = Get-AzureADGroup -Filter "DisplayName like 'PHI-%'"
foreach ($group in $phiGroups) {
    $members = Get-AzureADGroupMember -ObjectId $group.ObjectId
    $members | Export-Csv -Path "$outputPath\$($group.DisplayName)-Members.csv" -NoTypeInformation
}

# 5. Generate compliance report
$report = @{
    GeneratedDate = Get-Date
    TotalUsers = (Get-AzureADUser -All $true).Count
    PHIAccessGroups = $phiGroups.Count
    DLPPolicies = (Get-DlpCompliancePolicy).Count
    AuditLogRetention = "6 Years"
    BAAStatus = "Executed with Microsoft"
}
$report | ConvertTo-Json | Out-File "$outputPath\Compliance-Summary.json"

Our HIPAA Audit Readiness service provides comprehensive preparation for OCR reviews.

Frequently Asked Questions

Is Microsoft 365 Copilot HIPAA compliant?

Microsoft's infrastructure for Copilot is HIPAA-compliant when covered by a Business Associate Agreement (BAA). However, HIPAA compliance is a shared responsibility. Microsoft provides the secure platform, but your organization must implement proper access controls, audit logging, encryption, and minimum necessary restrictions. A BAA alone doesn't make your Copilot deployment compliant—you must configure sensitivity labels, DLP policies, and monitoring to meet §164.312 technical safeguards. Most healthcare organizations fail on access control implementation, not Microsoft's infrastructure.

Do I need a Business Associate Agreement (BAA) for Copilot?

Yes, if Copilot will access, process, or retrieve Protected Health Information (PHI). Under HIPAA §164.504(e), covered entities must have a BAA with any vendor that handles PHI on their behalf. Microsoft offers a BAA for Microsoft 365 services, including Copilot, through Enterprise Agreement customers and Cloud Solution Provider partners. The BAA must be executed before PHI is processed—retroactive agreements don't cure prior violations. Without a BAA, using Copilot with PHI is a HIPAA violation regardless of technical controls.

How do I prevent Copilot from exposing PHI to unauthorized users?

Prevention requires four technical layers: (1) Sensitivity labels on all PHI documents that enforce encryption and access restrictions; (2) DLP policies that block Copilot from surfacing PHI unless the user is in an authorized Azure AD group; (3) SharePoint permission remediation to remove overly broad access grants; and (4) Conditional Access policies requiring managed, compliant devices for Copilot access. The minimum necessary standard (§164.502(b)) requires limiting access to the minimum PHI needed for a specific role—implement this through security group segmentation, not site-level permissions.

What audit logging is required for HIPAA compliance with Copilot?

The HIPAA Security Rule §164.312(b) requires audit controls to record and examine ePHI access. For Copilot, this means: (1) Microsoft Purview Audit Premium tier (Standard tier only retains 90 days); (2) audit log retention of 6 years per OCR guidance; (3) capture of CopilotInteraction events including user identity, timestamp, query text, and documents retrieved; and (4) SIEM integration for real-time analysis and alerting. Audit logs must include sufficient detail to answer "who accessed what PHI, when, and for what purpose" during breach investigations or OCR audits.

How long does HIPAA-compliant Copilot implementation take for healthcare organizations?

For a typical hospital or health system (2,000-5,000 users), expect 12-16 weeks: 2-3 weeks for PHI inventory and risk analysis; 4-6 weeks for sensitivity label deployment and DLP configuration; 2-3 weeks for access control remediation and security group setup; 2-3 weeks for audit logging and SIEM integration; 1-2 weeks for compliance validation and testing. Organizations with existing Microsoft Purview implementations can accelerate to 10-12 weeks. Those with severe permission sprawl or decentralized SharePoint governance may require 20+ weeks. The timeline depends on PHI volume, permission complexity, and existing governance maturity—not technical capability.