PatientDesk.ai — Implementation Playbook (DSO)

PatientDesk.ai Implementation Playbook

AI Receptionist Deployment Guide for Dental Service Organizations

---

1. Executive Summary

What PatientDesk.ai Does

PatientDesk.ai is an AI-powered virtual receptionist platform that handles inbound and outbound patient communications—including phone calls, text messages, appointment scheduling, confirmations, and recall outreach—autonomously or with minimal human oversight. The platform integrates with practice management systems to access real-time scheduling availability, patient records, and treatment history, enabling it to conduct natural-language conversations that feel human while operating 24/7 without staffing constraints.

Why DSOs Benefit from AI Receptionists at Scale

AI receptionist technology delivers exponential returns for DSOs compared to single-location deployments:

Scale Advantages:

• A single AI platform replaces or augments 15–50+ front desk FTEs worth of phone capacity across your portfolio
• After-hours call handling (typically 30–40% of total call volume) becomes revenue-generating rather than lost opportunity
• Peak-hour overflow during lunch, morning rush, and Monday surges no longer requires overstaffing

Standardization Benefits:

• Every patient interaction follows your scripting, compliance requirements, and brand voice—no location-level variation
• Scheduling rules, cancellation policies, and recall protocols are enforced uniformly
• New location acquisitions can be onboarded to your communication standards within days, not months

Data Aggregation Power:

• Centralized visibility into call volumes, conversion rates, and patient communication patterns across all locations
• Identify underperforming locations or high-demand periods that require operational intervention
• Aggregate data enables ML model improvements that benefit all locations simultaneously

Expected Timeline: Decision to Full Deployment

Phase	Timeline	Milestone
Contract to Kick-off	1–2 weeks	SOW signed, project team assigned
Pre-Implementation & Pilot Prep	2–3 weeks	Baseline metrics, Wave 1 locations selected
Wave 1 Pilot (2–3 locations)	3–4 weeks	Full deployment, initial optimization
Wave 2 Expansion (5–8 locations)	3–4 weeks	Refined playbook, scaled training
Wave 3+ Full Rollout	4–8 weeks	Remaining locations, final optimization
Total: Decision to Full Deployment	13–21 weeks	All locations live and optimized

Timeline assumes 15–50 locations. Organizations with 50+ locations should plan for additional waves.

---

2. Pre-Implementation Checklist (Weeks 1–2)

Technical Requirements

Hardware Requirements

☐ Confirm each location has a dedicated workstation for monitoring AI interactions (can be existing front desk computer) ☐ Verify headset/speaker availability for call monitoring during training phase ☐ Assess phone system compatibility (VoIP preferred; legacy PBX may require adapters)

Software Requirements

☐ Practice Management System (PMS) version compatibility check:

• Dentrix G7.3 or higher
• Eaglesoft 21.0 or higher
• Open Dental 22.1 or higher
• Other PMS: confirm API availability with vendor ☐ Browser requirements: Chrome 90+, Edge 90+, or Firefox 88+ for dashboard access ☐ Operating system: Windows 10/11 or macOS 11+ for administrative interface

Network Requirements

☐ Minimum 25 Mbps download / 10 Mbps upload per location (50/20 recommended) ☐ Static IP or dynamic DNS for locations using on-premise phone systems ☐ Firewall rules: outbound HTTPS (443), WebSocket (443), SIP/RTP ports if applicable ☐ ⚠️ VPN configurations may cause latency issues—document any existing VPN usage

Integration Requirements

☐ 🔵 Confirm PatientDesk.ai supported integrations for your PMS version ☐ Identify phone system vendor and model at each location ☐ Document existing patient communication tools (Weave, Lighthouse 360, RevenueWell, etc.) that may need deactivation or integration

---

Vendor Onboarding Steps

Step	Action	Owner	Timeline
1	🔵 Execute BAA and MSA	Legal + Vendor	Day 1–3
2	🔵 Complete vendor security questionnaire	IT Security + Vendor	Day 1–5
3	🔵 Schedule kick-off call with implementation team	Project Lead + Vendor	Day 3–5
4	🔵 Obtain dedicated implementation manager contact	Project Lead	Day 5
5	🔵 Establish support escalation contacts and SLAs	IT + Vendor	Day 5–7
6	🔵 Access vendor training portal and documentation	Project Lead	Day 7

Key Contacts to Establish

☐ PatientDesk.ai Implementation Manager (primary contact for deployment) ☐ PatientDesk.ai Technical Integration Specialist (API/PMS issues) ☐ PatientDesk.ai Support Tier 2 escalation (post-go-live issues) ☐ PatientDesk.ai Customer Success Manager (ongoing optimization)

---

Data/Access Prerequisites

PMS Access Requirements

☐ API credentials or integration user account for each PMS instance ☐ Read access: patient demographics, appointment schedule, provider calendars ☐ Write access: appointment creation, modification, cancellation, notes ☐ ⚠️ Some PMS require vendor certification—confirm with PMS vendor before providing access

Phone System Access

☐ Admin credentials for phone system/VoIP platform ☐ Call forwarding/routing configuration access ☐ Call recording settings (for compliance and QA)

Administrative Access

☐ 🟣 Designate Super Admin users (recommend 2–3 central team members) ☐ Establish role-based access structure for regional managers and location champions ☐ SSO configuration details (if using Okta, Azure AD, or similar)

---

Enterprise-Level Requirements

Network Standards Across Locations

☐ Audit network performance at all locations against minimum requirements ☐ Identify locations requiring network upgrades before deployment ☐ 🟣 Approve budget for network remediation at underperforming locations

Hosting Architecture Decision

Option	Pros	Cons	Recommendation
Centralized Hosting	Single configuration, easier updates, consolidated data	Single point of failure, may introduce latency for distant locations	✅ Recommended for DSOs
Location-Level Hosting	Lower latency, location autonomy	Configuration drift, harder to maintain consistency	Not recommended

☐ 🟣 Document hosting architecture decision

Single Sign-On (SSO)

☐ 🔵 Confirm PatientDesk.ai supports your identity provider (IdP) ☐ Configure SAML 2.0 or OIDC integration ☐ Test SSO with pilot users before broad rollout

Centralized Credentialing

☐ Create standardized user roles and permission sets ☐ Document provisioning workflow for new users ☐ Establish deprovisioning protocol for termed employees (critical for HIPAA)

---

Internal Stakeholder Alignment

Stakeholder Alignment Map

Stakeholder	Role in Implementation	Communication Cadence	Key Concerns to Address
Board/Investors	Approve investment, expect ROI reporting	Monthly summary	ROI timeline, competitive differentiation, risk mitigation
C-Suite (CEO, COO, CDO)	🟣 Executive sponsors, strategic decisions	Bi-weekly steering committee	Strategic alignment, cross-functional impact, resource allocation
VP of Operations	Primary project owner, operational decisions	Weekly project meetings	Operational efficiency, staff impact, standardization
Chief Dental Officer	Clinical workflow approval, provider adoption	Bi-weekly clinical review	Patient experience, clinical appropriateness, provider workflow
VP of IT	Technical integration, security approval	Weekly technical sync	Security, compliance, integration complexity, support burden
Regional Managers	Wave deployment coordination, local escalation	Weekly during active waves	Location readiness, staff concerns, timeline feasibility
Office Managers	Local implementation, staff coordination	Daily during go-live week	Training, workflow changes, patient reactions
Providers	Clinical adoption, patient communication	Initial briefing + ongoing updates	Patient experience, call quality, override capabilities

Approval Checkpoints

☐ 🟣 Budget approval from CFO/Finance ☐ 🟣 Security approval from VP of IT/CISO ☐ 🟣 Clinical workflow approval from Chief Dental Officer ☐ 🟣 Legal approval of BAA and MSA ☐ 🟣 Board notification (if required by governance structure)

---

Baseline Metrics to Capture

⚠️ Critical: Capture These BEFORE Go-Live to Enable ROI Measurement

Standardize measurement methodology across all locations to enable cross-location comparison.

Metric Category	Specific Metrics	Data Source	Collection Method
Call Volume	Total inbound calls/month, calls by hour, calls by day	Phone system reports	Export 90-day history
Call Handling	Answer rate (%), average hold time, abandonment rate, after-hours missed calls	Phone system/PMS	Export 90-day history
Scheduling Efficiency	Appointments booked via phone (%), appointment conversion rate (call → booking)	PMS + manual tracking	Sample 2-week period
Staff Utilization	FTE hours spent on phones, cost per call handled	Payroll + time tracking	Calculate from existing data
Patient Satisfaction	NPS or satisfaction scores (if tracked), complaints related to phone access	Patient surveys	Pull existing data
Revenue Impact	No-show rate, confirmation success rate, recall reactivation rate	PMS	Export 90-day history

Standardization Requirements for DSO Measurement

☐ Create uniform metric definitions document distributed to all locations ☐ Establish date range for baseline (recommend: 90 days pre-implementation) ☐ Identify locations with incomplete data and establish manual tracking before go-live ☐ ⚠️ Verify phone system reporting is enabled and accurate at all locations ☐ Create centralized spreadsheet or dashboard for baseline data collection

---

3. Location Readiness Assessment

Scoring Framework

Rate each location 1–5 on the following factors, then calculate a composite readiness score.

Factor 1: IT Infrastructure Maturity (Weight: 25%)

Score	Criteria
5	Fiber internet (100+ Mbps), modern VoIP system, hardware <3 years old, current PMS version
4	Cable internet (50+ Mbps), VoIP system, hardware <5 years old, supported PMS version
3	Cable internet (25+ Mbps), hybrid phone system, hardware 5–7 years old, slightly outdated PMS
2	DSL or inconsistent internet, legacy PBX requiring adapters, hardware >7 years old
1	Unreliable internet, legacy phone system incompatible without major upgrades, unsupported PMS version

Factor 2: Staff Tenure and Adaptability (Weight: 20%)

Score	Criteria
5	Low turnover (<15% annually), staff has adopted 2+ tech tools in past 2 years, positive attitudes toward change
4	Moderate turnover (15–25%), staff has adopted 1+ tech tool recently, generally receptive
3	Average turnover (25–35%), mixed tech adoption history, neutral attitudes
2	High turnover (35–50%), limited tech adoption success, some resistance to change
1	Very high turnover (>50%), failed tech implementations, active resistance culture

Factor 3: Patient Volume (Weight: 20%)

Score	Criteria
5	High volume (80+ calls/day): Maximum impact potential, sufficient data for optimization
4	Medium-high volume (60–79 calls/day): Strong impact potential
3	Medium volume (40–59 calls/day): Moderate impact, manageable risk
2	Low-medium volume (20–39 calls/day): Lower impact, good for learning
1	Low volume (<20 calls/day): Minimal impact, but low risk for testing

Note: For Wave 1 pilots, medium volume (Score 3) may be preferable to reduce risk while still generating meaningful data.

Factor 4: Tech Stack Compatibility (Weight: 20%)

Score	Criteria
5	PMS is top-tier integration (Dentrix, Eaglesoft, Open Dental current version), VoIP phone, no conflicting tools
4	PMS is supported integration, VoIP phone, 1 tool requiring coordination (e.g., existing patient communication tool)
3	PMS is supported but older version, mixed phone system, 2 tools requiring coordination
2	PMS integration requires custom work, legacy phone system needing adapters, multiple tool conflicts
1	PMS not currently supported, incompatible phone system, major tech stack conflicts

Factor 5: Local Champion Availability (Weight: 15%)

Score	Criteria
5	Tech-forward office manager AND provider champion identified, both eager to lead
4	Strong office manager champion OR enthusiastic provider champion
3	Office manager willing but not tech-savvy, or champion identified but limited availability
2	No clear champion, but no active detractors
1	No champion available, key staff resistant to technology changes

---

Composite Readiness Score Calculation

Formula: (Infrastructure × 0.25) + (Staff × 0.20) + (Volume × 0.20) + (Tech Stack × 0.20) + (Champion × 0.15) = Composite Score

Readiness Categories

Composite Score	Readiness Level	Rollout Recommendation
4.0–5.0	High Readiness	Wave 1 candidate (if diverse representation)
3.0–3.9	Medium Readiness	Wave 2 candidate
2.0–2.9	Low Readiness	Wave 3, with remediation plan
1.0–1.9	Not Ready	Defer until infrastructure/staffing improvements complete

---

Sample Location Readiness Scorecard

Location	Infrastructure (25%)	Staff (20%)	Volume (20%)	Tech Stack (20%)	Champion (15%)	Composite	Wave
Downtown Main	5	4	5	4	5	4.55	Wave 1
Suburban Plaza	4	4	3	5	4	3.95	Wave 1
Westside Family	3	3	4	4	3	3.40	Wave 2
Eastside Dental	4	2	3	4	2	3.10	Wave 2
North County	2	3	2	3	2	2.45	Wave 3

---

Rollout Sequence Recommendation

Based on readiness scores, structure your waves as follows:

Wave 1 Selection Criteria (2–3 locations)

• Composite score ≥ 4.0
• Geographic/demographic diversity (at least one urban, one suburban if applicable)
• Different PMS instances represented (to validate integration across variations)
• Strong local champions who can provide detailed feedback
• ⚠️ Avoid selecting ALL highest-performing locations—you need learnings applicable to average locations

Wave 2 Selection Criteria (5–8 locations)

• Composite score 3.0–3.9
• Include at least one location with each "challenge factor" identified in Wave 1
• Prioritize locations with remediable issues addressed between waves

Wave 3+ Selection Criteria (remaining locations)

• All locations scoring 2.0–2.9 (with remediation plans executed)
• Recently acquired locations with completed system standardization
• Locations initially deferred due to specific blockers now resolved

---

4. Rollout Strategy

Wave Structure Overview

Wave	Locations	Timeline	Purpose
Wave 1 (Pilot)	2–3	Weeks 4–7	Validate integration, refine training, identify edge cases
Buffer Period	—	Week 8	Analyze results, update playbook, address issues
Wave 2 (Expansion)	5–8	Weeks 9–12	Scale proven approach, stress-test support model
Buffer Period	—	Week 13	Final optimization, prepare for full deployment
Wave 3+ (Full Rollout)	Remaining	Weeks 14–21	Accelerated deployment using refined playbook

---

Wave 1 Pilot Location Selection

Selection Criteria Matrix

Criterion	Weight	Evaluation
High readiness score (≥4.0)	30%	Minimizes implementation friction
Manageable call volume (40–70 calls/day)	20%	Enough data without overwhelming first deployment
Representative characteristics	20%	Mix of specialties, demographics, phone systems
Strong local champion	20%	Ensures quality feedback and local ownership
Geographic proximity to central team	10%	Enables on-site support if needed

Recommended Wave 1 Configuration

• Location A: High-readiness urban location with highest volume (stress test)
• Location B: Medium-high readiness suburban location (typical portfolio representative)
• Location C (optional): Location with one "manageable challenge" (e.g., older PMS version) to validate edge case handling

---

Timeline Per Wave

Wave 1 Detailed Timeline (Weeks 4–7)

Week	Phase	Key Activities
Week 4	Configuration	🔵 Complete PMS integration, configure phone routing, customize scripts
Week 5	Training	Train champions, train all Wave 1 staff, conduct mock go-lives
Week 6	Go-Live	Launch AI receptionist, daily monitoring, rapid issue resolution
Week 7	Stabilization	Optimize based on data, document learnings, prepare Wave 2 materials

Wave 2+ Timeline (3–4 weeks per wave)

Week	Phase	Key Activities
Week 1	Configuration	Apply standardized configuration, location-specific customizations
Week 2	Training	Champion training (condensed), staff training
Week 3	Go-Live	Staggered launches (2–3 locations per day), intensive monitoring
Week 4	Stabilization	Optimization, address outliers, prepare next wave

---

Go/No-Go Criteria

Criteria to Advance from Wave 1 to Wave 2

🟣 Executive Decision Required: All criteria must be met or formally waived.

Category	Go Criteria	No-Go Triggers
Technical Stability	<2% call failures, no critical integration bugs, <5 second response latency	>5% call failures, critical bugs unresolved, unacceptable latency
Staff Adoption	80%+ staff trained and using system, champion engagement strong	<60% adoption, champion disengaged, widespread resistance
Patient Experience	No significant patient complaints, call quality scores ≥4/5	Multiple patient complaints, quality scores <3/5
Operational Impact	Positive or neutral impact on scheduling efficiency, no workflow disruptions	Measurable decline in scheduling, major workflow breakdowns
Support Readiness	Issue resolution <4 hours for P1, <24 hours for P2	Issue backlog growing, response times unacceptable

Go/No-Go Review Meeting

• Timing: End of Week 7 (Wave 1) or final week of each subsequent wave
• Attendees: VP Operations, VP IT, Implementation PM, Vendor Success Manager
• Decision Authority: 🟣 VP Operations with input from above stakeholders
• Documentation: Formal go/no-go decision memo with criteria assessment

---

Rollback Plan

Rollback Triggers

• Critical system failure affecting patient access
• Data integrity issues (scheduling conflicts, patient record errors)
• Compliance/security incident
• 🟣 Executive decision based on aggregate risk assessment

Rollback Procedure

Step	Action	Owner	Timeline
1	Initiate rollback via central IT	IT Lead	Immediate
2	Revert phone routing to direct-to-location	IT + Phone Vendor	<30 minutes
3	Disable AI receptionist for affected locations	IT	<30 minutes
4	Notify location champions and office managers	Regional Manager	<1 hour
5	Activate backup staffing plan (if needed)	Office Manager	Same day
6	🔵 Conduct root cause analysis with vendor	IT + Vendor	Within 48 hours
7	🟣 Review and approve remediation plan	VP Operations	Within 1 week
8	Schedule re-deployment after remediation	Project Team	Per remediation plan

Rollback Scope Options

• Single Location: Isolate one location without affecting others
• Wave Rollback: Revert entire wave while maintaining previous waves
• Full Rollback: Complete system deactivation (nuclear option—rarely needed)

---

5. Configuration & Integration (Weeks 2–3)

PMS Integration: Step-by-Step

Dentrix Integration

Step	Action	Owner	Est. Time
1	🔵 Request PatientDesk.ai Dentrix integration package	Vendor	Day 1
2	Verify Dentrix version (G7.3+) and patch level	Local IT/Office Manager	30 min
3	Create dedicated integration user in Dentrix with appropriate permissions	Office Manager	15 min
4	⚠️ Configure Dentrix API settings (may require Henry Schein support)	IT + Henry Schein	1–2 hours
5	🔵 Provide API credentials to PatientDesk.ai	IT	15 min
6	🔵 PatientDesk.ai configures connection and runs test queries	Vendor	1–2 hours
7	Validate data sync: test patient lookup, schedule visibility, appointment creation	IT + Vendor	1 hour
8	⚠️ Test two-way sync: create test appointment in PatientDesk.ai, verify in Dentrix	IT	30 min
9	Document integration settings for replication across locations	IT	30 min

Eaglesoft Integration

Step	Action	Owner	Est. Time
1	🔵 Request PatientDesk.ai Eaglesoft integration package	Vendor	Day 1
2	Verify Eaglesoft version (21.0+)	Local IT/Office Manager	30 min
3	Enable Eaglesoft API access (Patterson support may be required)	IT + Patterson	1–2 hours
4	Create integration user with scheduling and patient record access	Office Manager	15 min
5	🔵 Configure connection in PatientDesk.ai admin panel	Vendor	1 hour
6	Test patient search, calendar access, and appointment booking	IT + Vendor	1 hour
7	⚠️ Verify Eaglesoft's sync frequency (some versions have delayed sync)	IT	30 min
8	Document any Eaglesoft-specific workarounds	IT	30 min

Open Dental Integration

Step	Action	Owner	Est. Time
1	🔵 Request PatientDesk.ai Open Dental API integration	Vendor	Day 1
2	Verify Open Dental version (22.1+) and API module is enabled	IT	30 min
3	Generate API key in Open Dental (Setup > Advanced Setup > API)	Office Manager/IT	15 min
4	🔵 Provide API key and Open Dental server URL to PatientDesk.ai	IT	15 min
5	🔵 Vendor configures connection and tests endpoints	Vendor	1–2 hours
6	Validate: patient search, appointment creation, schedule blocking	IT + Vendor	1 hour
7	Test operatory mapping and provider calendar accuracy	IT	30 min

---

Phone System Integration

VoIP System Configuration (RingCentral, 8x8, Vonage, etc.)

Step	Action	Owner	Est. Time
1	Obtain admin credentials for phone system	IT	—
2	🔵 Provide SIP trunk details or API credentials to PatientDesk.ai	IT + Vendor	30 min
3	Configure call routing rules: which calls route to AI vs. direct to staff	IT + Office Manager	1–2 hours
4	Set up fallback routing: AI unavailable → route to front desk	IT	30 min
5	Configure call recording settings (ensure compliance with state laws)	IT + Legal	30 min
6	⚠️ Test routing with live calls in off-hours before go-live	IT	1 hour
7	Document emergency bypass procedure (how to disable AI routing instantly)	IT	30 min

Legacy PBX Requirements

☐ 🔵 Confirm PatientDesk.ai compatibility with specific PBX model ☐ Procure necessary adapters or SIP gateways ☐ Schedule PBX vendor for configuration assistance ☐ ⚠️ Budget additional 2–3 days for legacy system integration

---

Test Environment Setup

Centralized Test Environment (Recommended for DSO)

Step	Action	Owner	Est. Time
1	🔵 Request sandbox/test environment from PatientDesk.ai	Vendor	Day 1
2	Connect test environment to PMS test/training database (if available)	IT	2–4 hours
3	Configure test phone number for routing to sandbox	IT	30 min
4	Create test patient profiles and appointments	Project Team	1 hour
5	Conduct end-to-end test scenarios (list below)	QA Team	4–8 hours
6	Document issues and create fix tickets	QA Team	2 hours
7	🔵 Vendor addresses issues, retest	Vendor + QA	Variable
8	Sign off on test environment readiness	IT + Project Lead	—

Validation Checklist

☐ Patient lookup by name, DOB, phone number returns correct records ☐ Available appointment slots match PMS calendar ☐ New appointment creation reflects in PMS within 5 minutes ☐ Appointment modification updates PMS correctly ☐ Appointment cancellation processes correctly and opens slot ☐ Call routing to AI functions correctly ☐ Fallback to human answers when AI cannot help ☐ Call recording captures complete conversation ☐ ⚠️ After-hours handling routes correctly ☐ Spanish language handling (if configured) functions correctly ☐ Emergency keywords (pain, swelling, bleeding) trigger appropriate response

---

Data Migration / Historical Ingestion

Patient Communication History (If Applicable)

Step	Action	Owner	Est. Time
1	Identify historical data to import (past call logs, text history, recall lists)	Project Team	2 hours
2	🔵 Confirm PatientDesk.ai data import capabilities and formats	Vendor	—
3	Export data from legacy systems in required format	IT	2–4 hours
4	⚠️ Scrub data for PHI compliance before transfer	IT + Compliance	2–4 hours
5	🔵 Import data to PatientDesk.ai	Vendor	2–4 hours
6	Validate imported data accuracy (spot check 5% of records)	QA Team	2–4 hours

---

Security and HIPAA Compliance

Enterprise-Level HIPAA Checklist

Requirement	Verification Step	Owner	Status
Business Associate Agreement	🔵 Executed BAA on file	Legal	☐
Data Encryption - Transit	🔵 Confirm TLS 1.2+ for all data transmission	IT Security	☐
Data Encryption - Rest	🔵 Confirm AES-256 encryption for stored data	IT Security	☐
Access Controls	Role-based access configured, least privilege enforced	IT	☐
Audit Logging	🔵 Confirm all access is logged and retrievable	IT Security + Vendor	☐
Data Retention	Retention policy aligns with organizational requirements	Compliance	☐
Breach Notification	🔵 Breach notification procedures documented in BAA	Legal + Vendor	☐
Subcontractors	🔵 Vendor's subcontractors identified and covered by BAAs	Legal + Vendor	☐
Physical Security	🔵 Vendor data center certifications (SOC 2, HITRUST) obtained	IT Security	☐
Employee Training	🔵 Vendor HIPAA training documentation obtained	Compliance	☐

Data Governance

☐ Document what PHI flows to PatientDesk.ai (patient names, DOB, phone, appointment details) ☐ 🟣 Approve data flow with Chief Compliance Officer or equivalent ☐ Establish data retention policy for call recordings (typically 6 years for HIPAA) ☐ Configure automatic data deletion per retention policy ☐ Document patient consent process for AI-handled communications (check state requirements)

---

Standardized vs. Location-Specific Configuration

Standardized Configuration Template

Apply these settings identically across ALL locations:

Setting Category	Standardized Setting	Rationale
Greeting Script	"Thank you for calling [Practice Name], a [DSO Name] practice. How may I help you today?"	Brand consistency
Appointment Types	Standard list: New Patient, Recall/Cleaning, Emergency, Consultation, Follow-up	Data aggregation
Business Hours Logic	AI identifies after-hours based on PMS schedule	Accuracy
Emergency Keywords	Pain, swelling, bleeding, trauma, broken tooth, knocked out	Patient safety