LocalMed
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
LocalMed — Implementation Playbook (DSO)
LocalMed Implementation Playbook for DSOs
Intelligent Online Scheduling at Scale
1. Executive Summary
What LocalMed Does
LocalMed is an AI-powered real-time online scheduling platform that integrates directly with practice management systems to enable patients to book appointments 24/7 based on actual provider availability, insurance verification, and appointment-type logic. The system uses intelligent rules to match patients with the right provider, operatory, and time slot while respecting complex scheduling preferences.
Why DSOs Benefit from AI-Powered Scheduling
DSOs operating at scale face a universal challenge: scheduling inefficiency compounds across locations. A single practice losing 3-5 potential patients weekly to after-hours booking gaps becomes 150-250 lost patients monthly across a 50-location portfolio. LocalMed's AI scheduling delivers three distinct scale advantages:
- Standardization Without Rigidity: Deploy consistent scheduling rules across all locations while accommodating local provider preferences and specialty mixes
- Data Aggregation for Strategic Decisions: Centralized visibility into scheduling patterns, no-show rates, and demand signals across your entire footprint enables portfolio-level capacity optimization
- Operational Leverage: One configuration, one training protocol, one support relationship—multiplied across every location
Expected Timeline: Decision to Full Deployment
- 15-25 Locations: 10-14 weeks
- 26-40 Locations: 14-18 weeks
- 41-50 Locations: 18-22 weeks
Timeline assumes 3-4 waves with 2-week buffer between waves for learning capture.
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware
☐ Verify minimum workstation specs at each location (Windows 10+ or macOS 10.14+, 8GB RAM minimum) ☐ Confirm stable internet connectivity (minimum 25 Mbps download/10 Mbps upload per location) ☐ Document existing router/firewall configurations across locations
Software
☐ Inventory PMS versions across all locations (Dentrix, Eaglesoft, Open Dental, other) ☐ Confirm PMS versions meet LocalMed minimum requirements:
- Dentrix: Version 17.0+
- Eaglesoft: Version 19.0+
- Open Dental: Version 19.1+ ☐ Document browser versions on front desk workstations (Chrome 90+ or Edge 90+ recommended)
Network
☐ Whitelist LocalMed domains and IP ranges in corporate firewall (vendor will provide) 🔵 ☐ Verify SSL/TLS 1.2+ enabled on all location networks ☐ Test API connectivity from each location to LocalMed servers ⚠️
Integrations
☐ Map existing tech stack per location:
- Practice management system
- Patient communication platform
- Insurance verification tool
- Website/patient portal ☐ Identify integration conflicts (existing scheduling widgets, competing tools)
Vendor Onboarding Steps
| Step | Action | Timeline | Owner |
|---|---|---|---|
| 1 | Execute enterprise agreement and BAA 🔵 | Day 1-3 | Legal/Compliance |
| 2 | Complete vendor security questionnaire | Day 3-5 | IT Security |
| 3 | Establish primary and secondary account contacts | Day 5 | Ops Leadership |
| 4 | Schedule kickoff call with LocalMed implementation team 🔵 | Day 5-7 | Project Lead |
| 5 | Receive dedicated implementation manager contact info 🔵 | Day 7 | Vendor |
| 6 | Gain access to enterprise admin portal | Day 7-10 | IT/Vendor |
Key Contacts to Establish
☐ LocalMed Implementation Manager (primary point of contact) ☐ LocalMed Technical Support escalation contact ☐ LocalMed Customer Success Manager (post-implementation) ☐ PMS vendor technical support contact (for integration issues)
Data/Access Prerequisites
Logins and Credentials
☐ Create enterprise admin credentials for LocalMed portal 🟣 ☐ Document PMS admin credentials for each location (or centralized if using cloud PMS) ☐ Prepare SSO configuration details if implementing (SAML 2.0 or OAuth 2.0) ☐ Gather website CMS admin credentials for scheduling widget installation
API Keys and Integrations
☐ Request API credentials from PMS vendor (if not already available) ☐ Document existing patient communication platform API keys ☐ Prepare insurance eligibility verification credentials (if integrating)
Data Requirements
☐ Export provider schedules and availability templates from each location ☐ Compile appointment type definitions and durations across all locations ⚠️ ☐ Document scheduling rules currently used (new patient protocols, emergency slots, etc.) ☐ Prepare provider licensure and credentialing data for scheduling rules
Internal Stakeholder Alignment
Stakeholder Alignment Map
| Stakeholder Level | Role | Engagement Type | Timing |
|---|---|---|---|
| Board/Investors | Awareness | Quarterly update inclusion | Pre-decision |
| C-Suite (CEO, CFO, COO) | Approval | Business case presentation, budget approval | Week 1 🟣 |
| Chief Dental Officer | Approval + Champion | Clinical workflow sign-off, provider communication | Week 1-2 🟣 |
| VP of Operations | Owner | Project sponsorship, resource allocation | Week 1 |
| IT Leadership | Approval + Execution | Technical requirements, security review | Week 1-2 |
| Regional Managers | Execution + Cascade | Location selection, timeline coordination | Week 2 |
| Office Managers | Execution | Local implementation, staff coordination | Week 2+ |
| Providers | Informed + Adoption | Workflow changes, scheduling preference input | Week 2+ |
| Front Desk Staff | Adoption | Training, daily use | Week 3+ |
Approval Requirements
☐ C-suite budget approval for enterprise licensing 🟣 ☐ CDO sign-off on clinical scheduling protocols 🟣 ☐ IT security approval after vendor assessment 🟣 ☐ Legal approval of BAA and enterprise agreement 🟣
Baseline Metrics to Capture BEFORE Go-Live ⚠️
Critical: Standardize metric definitions and collection methods across ALL locations before capturing baselines. Inconsistent measurement will invalidate ROI analysis.
Scheduling Efficiency Metrics
| Metric | Definition | Collection Method | Target Source |
|---|---|---|---|
| Online booking rate | % of appointments booked online vs. total | PMS report + current widget data | PMS/Current tool |
| After-hours booking requests | # of appointment requests received outside business hours | Website analytics, voicemail logs | Web analytics |
| Phone call volume for scheduling | # of inbound calls resulting in appointment booking | Phone system data | Phone system |
| Average time-to-book | Time from patient first contact to confirmed appointment | Manual sample or PMS timestamps | PMS |
| Schedule fill rate | % of available appointment slots filled | PMS schedule analysis | PMS |
Patient Experience Metrics
| Metric | Definition | Collection Method | Target Source |
|---|---|---|---|
| New patient conversion rate | % of new patient inquiries that become scheduled appointments | CRM or manual tracking | CRM/Manual |
| Appointment abandonment rate | % of online booking attempts not completed | Current widget analytics | Current tool |
| Patient satisfaction (scheduling) | Survey responses related to scheduling ease | Patient survey | Survey tool |
Operational Metrics
| Metric | Definition | Collection Method | Target Source |
|---|---|---|---|
| No-show rate | % of scheduled appointments where patient didn't arrive | PMS report | PMS |
| Same-day cancellation rate | % of appointments cancelled <24 hours before | PMS report | PMS |
| Front desk time on scheduling | Estimated hours/week spent on phone scheduling | Time study (sample 1 week) | Manual |
| Scheduling errors | # of double-bookings, wrong provider, wrong appointment type/month | Manual tracking | Manual |
Standardization Protocol
☐ Create centralized baseline data collection template ☐ Assign regional managers to verify data collection at each location ☐ Set data collection period: minimum 4 weeks pre-implementation ☐ Store baseline data in centralized location for post-implementation comparison
Enterprise-Level Requirements
Network Standards Across Locations
☐ Document minimum bandwidth requirements for each location tier (by patient volume) ☐ Standardize firewall rules across all locations 🟣 ☐ Verify VPN or direct connection requirements for centralized hosting ☐ Test latency from each location to LocalMed servers (<200ms target)
Centralized vs. Location-Level Hosting Decision 🟣
| Model | Pros | Cons | Recommended For |
|---|---|---|---|
| Centralized | Single configuration, unified reporting, easier updates | Single point of failure, requires robust connectivity | Cloud PMS users, standardized operations |
| Location-Level | Resilience, local control | Configuration drift, harder to maintain consistency | On-premise PMS, variable connectivity |
Recommendation: Centralized hosting with location-level failover for DSOs with cloud PMS platforms.
Single Sign-On (SSO) Configuration
☐ Confirm identity provider (Azure AD, Okta, Google Workspace, other) ☐ Document SSO requirements with LocalMed 🔵 ☐ Plan user provisioning workflow (automatic vs. manual) ☐ Define role-based access control structure:
- Enterprise Admin (C-suite, VP Ops)
- Regional Admin (Regional managers)
- Location Admin (Office managers)
- User (Front desk, providers)
Centralized Credentialing
☐ Compile provider credentialing data in standardized format ☐ Map provider credentials to scheduling permissions (specialty restrictions, procedure types) ☐ Establish update protocol for new providers and credential changes
3. Location Readiness Assessment
Scoring Framework
Score each location on the following factors (1-5 scale). Calculate composite score to determine rollout sequence.
Factor 1: IT Infrastructure Maturity (Weight: 25%)
| Score | Criteria |
|---|---|
| 5 | Fiber internet (100+ Mbps), workstations <2 years old, cloud PMS, modern network equipment |
| 4 | Cable internet (50+ Mbps), workstations <3 years old, PMS meets requirements |
| 3 | Adequate internet (25+ Mbps), workstations <5 years old, PMS version compatible |
| 2 | Inconsistent internet, mixed workstation ages, PMS at minimum supported version |
| 1 | Poor internet reliability, outdated workstations, PMS version issues requiring upgrade |
Factor 2: Staff Tenure and Adaptability (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | <15% annual turnover, previous successful tech rollouts, staff actively requests new tools |
| 4 | 15-25% turnover, successful tech adoption history, generally positive about change |
| 3 | 25-35% turnover, mixed results with past tech changes, neutral attitude |
| 2 | 35-50% turnover, struggled with past implementations, some resistance expected |
| 1 | >50% turnover, failed previous tech rollouts, known change-resistant culture |
Factor 3: Patient Volume (Weight: 20%)
| Score | Criteria | Risk/Reward Profile |
|---|---|---|
| 5 | 800-1000 patients/month | High impact, high complexity |
| 4 | 600-800 patients/month | Strong impact, manageable complexity |
| 3 | 400-600 patients/month | Moderate impact, moderate complexity—ideal for pilots |
| 2 | 250-400 patients/month | Lower impact, lower risk |
| 1 | <250 patients/month | Minimal impact, may not justify priority implementation |
Note: For pilot locations, scores of 3-4 are often preferable to 5s—high enough volume to demonstrate value without overwhelming risk.
Factor 4: Existing Tech Stack Compatibility (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | Same PMS as majority of locations, no conflicting scheduling tools, modern patient communication platform |
| 4 | Compatible PMS, minimal integration conflicts, standard tech stack |
| 3 | Compatible PMS, some integration work needed, manageable conflicts |
| 2 | PMS requires configuration, multiple integration conflicts, legacy tools to sunset |
| 1 | PMS at version limit, significant integration barriers, complex legacy tech debt |
Factor 5: Local Champion Availability (Weight: 15%)
| Score | Criteria |
|---|---|
| 5 | Office manager AND lead provider both tech-forward, expressed enthusiasm for AI tools |
| 4 | Strong office manager OR engaged provider champion identified |
| 3 | Competent office manager willing to lead, no strong provider advocate |
| 2 | Office manager will comply but not champion, no obvious local advocate |
| 1 | Office manager overwhelmed or resistant, no viable champion identified |
Composite Score Calculation
Formula:
Composite Score = (IT × 0.25) + (Staff × 0.20) + (Volume × 0.20) + (TechStack × 0.20) + (Champion × 0.15)
Readiness Tiers
| Composite Score | Tier | Rollout Recommendation |
|---|---|---|
| 4.0 - 5.0 | Tier 1: Pilot Ready | Wave 1 candidates |
| 3.0 - 3.9 | Tier 2: Standard Ready | Wave 2-3 candidates |
| 2.0 - 2.9 | Tier 3: Needs Preparation | Address gaps before including in rollout |
| 1.0 - 1.9 | Tier 4: Significant Barriers | Remediation plan required, may delay to final wave |
Location Assessment Template
| Location | IT Score | Staff Score | Volume Score | Tech Stack Score | Champion Score | Composite | Tier |
|---|---|---|---|---|---|---|---|
| Example Location A | 4 | 4 | 3 | 5 | 4 | 4.0 | Tier 1 |
| Example Location B | 3 | 3 | 4 | 3 | 3 | 3.2 | Tier 2 |
| Example Location C | 2 | 2 | 3 | 2 | 2 | 2.2 | Tier 3 |
Rollout Sequence Recommendations
Wave 1 Selection Criteria (2-3 Locations)
- Composite score ≥4.0
- Geographic diversity (different regions to test regional support model)
- Representative PMS mix (if using multiple PMS platforms)
- At least one location near corporate office (for hands-on support if needed)
- Avoid highest-volume locations (reduce risk during learning phase)
Wave 2-3 Selection
- Prioritize by composite score within each tier
- Balance geographic distribution across waves
- Group locations with same PMS platform when possible (efficiency in configuration)
- Consider regional manager span—don't overload one region in a single wave
Pre-Rollout Remediation
For Tier 3-4 locations, create remediation plan: ☐ IT infrastructure upgrades ☐ PMS version updates ☐ Staff training pre-work ☐ Champion identification/development ☐ Legacy tool sunset timeline
4. Rollout Strategy
Wave Structure
Recommended Wave Model (30-Location Example)
| Wave | Locations | Duration | Cumulative Coverage |
|---|---|---|---|
| Wave 1 (Pilot) | 3 locations | 3 weeks active + 2 weeks stabilization | 10% |
| Wave 2 | 7 locations | 3 weeks active + 1 week stabilization | 33% |
| Wave 3 | 10 locations | 3 weeks active + 1 week stabilization | 67% |
| Wave 4 | 10 locations | 3 weeks active | 100% |
Total timeline: 16 weeks from Wave 1 start to full deployment
Wave 1 Pilot Location Selection 🟣
Selection Matrix
| Criteria | Weight | Rationale |
|---|---|---|
| Composite readiness score ≥4.0 | Required | Maximize success probability |
| Patient volume 400-600/month | Preferred | Meaningful data without overwhelming risk |
| Different regions represented | Required | Test regional support model |
| Mix of provider types (GP + specialist if applicable) | Preferred | Validate scheduling rules across specialties |
| Office manager tenure >2 years | Preferred | Institutional knowledge aids troubleshooting |
| No major initiatives in parallel | Required | Avoid competing priorities |
Wave 1 Go-Live Sequence
- Location 1: Monday go-live
- Location 2: Wednesday go-live (2 days buffer)
- Location 3: Following Monday go-live (5 days buffer)
Staggered launch allows learning capture and support capacity management.
Timeline Per Wave
Wave 1 (Pilot) - 5 Weeks Total
| Week | Activities |
|---|---|
| Week 1 | Configuration, integration testing, champion training |
| Week 2 | Staff training, parallel run (online booking available but not promoted) |
| Week 3 | Go-live, daily monitoring, active patient promotion begins |
| Week 4 | Stabilization, issue resolution, metric collection |
| Week 5 | Learning capture, process refinement, Wave 2 prep |
Waves 2-4 - 4 Weeks Each
| Week | Activities |
|---|---|
| Week 1 | Configuration (using refined templates), champion training |
| Week 2 | Staff training, go-live |
| Week 3 | Stabilization, issue resolution |
| Week 4 | Metric validation, next wave prep |
Go/No-Go Criteria 🟣
Criteria to Advance from Wave 1 to Wave 2
| Category | Metric | Threshold | Status |
|---|---|---|---|
| Technical | Integration uptime | >99% | ☐ Pass ☐ Fail |
| Technical | Critical bugs open | 0 | ☐ Pass ☐ Fail |
| Technical | Data sync accuracy | >99.5% | ☐ Pass ☐ Fail |
| Adoption | Staff completing training | 100% | ☐ Pass ☐ Fail |
| Adoption | Provider satisfaction (survey) | >3.5/5 | ☐ Pass ☐ Fail |
| Operational | Scheduling errors vs. baseline | ≤ baseline | ☐ Pass ☐ Fail |
| Operational | Patient complaints related to booking | <5 per location | ☐ Pass ☐ Fail |
| Process | Champion confidence rating | >4/5 | ☐ Pass ☐ Fail |
Decision Framework
- All criteria pass → Proceed to next wave
- 1-2 criteria fail (non-critical) → Proceed with mitigation plan
- Any critical criteria fail (technical stability, data accuracy) → Pause, remediate, re-evaluate in 1 week
- 3+ criteria fail → Extend current wave by 2 weeks, escalate to executive sponsor 🟣
Criteria for Subsequent Waves
| Category | Metric | Threshold |
|---|---|---|
| Technical | Integration uptime | >99% |
| Adoption | Training completion | 100% |
| Operational | No increase in scheduling errors | ≤ previous wave |
| Process | Champion sign-off | Required |
Rollback Plan ⚠️
Rollback Triggers
- Critical data sync failure affecting patient safety
- Integration causes PMS instability
10% of appointments affected by system errors
- Vendor unable to resolve critical issue within 48 hours
Rollback Procedure
Immediate Actions (0-4 Hours) ☐ Disable LocalMed scheduling widget on affected location websites ☐ Redirect online booking to phone/contact form ☐ Notify vendor of rollback initiation 🔵 ☐ Brief office manager and front desk on temporary phone-only booking
Short-Term Actions (4-24 Hours) ☐ Audit any appointments booked during issue period ☐ Contact affected patients to confirm appointments ☐ Document root cause (if known) ☐ Communicate status to regional manager
Stabilization Actions (24-72 Hours) ☐ Conduct root cause analysis with vendor 🔵 ☐ Develop remediation plan ☐ Define criteria for re-enabling ☐ Update rollout timeline for subsequent waves if needed 🟣
Isolation Protocol
- Rollback is location-specific; does not affect other locations
- If issue is systemic (affects multiple locations), pause all active waves
- Locations not yet live continue preparation but hold go-live until issue resolved
5. Configuration & Integration (Weeks 2–3)
Practice Management System Integrations
Dentrix Integration 🔵
Prerequisites ☐ Dentrix version 17.0 or higher confirmed ☐ Dentrix local admin credentials available ☐ eCentral account active (if using cloud features)
Step-by-Step Configuration
- ☐ Install LocalMed Dentrix Connector on server workstation (vendor provides installer) 🔵
- ☐ Configure Windows service to run with appropriate permissions
- ☐ Map Dentrix operatories to LocalMed scheduling resources
- ☐ Map Dentrix appointment types to LocalMed booking options
- ☐ Configure provider schedules and availability templates
- ☐ Enable real-time sync service
- ☐ Test bi-directional data flow (create test appointment in LocalMed, verify in Dentrix)
- ☐ Validate insurance information sync (if using insurance filtering)
- ☐ Configure appointment confirmation settings
Estimated Time: 2-3 hours per location Vendor Involvement: Required for steps 1, 7 🔵
Eaglesoft Integration 🔵
Prerequisites ☐ Eaglesoft version 19.0 or higher confirmed ☐ Eaglesoft admin login credentials ☐ SQL Server access credentials (for database connection)
Step-by-Step Configuration
- ☐ Verify SQL Server connection parameters
- ☐ Install LocalMed Eaglesoft integration service 🔵
- ☐ Configure database connection string
- ☐ Map Eaglesoft providers to LocalMed resources
- ☐ Map appointment categories and types
- ☐ Configure operatory assignments
- ☐ Set up schedule template sync
- ☐ Test appointment creation and sync
- ☐ Validate patient demographic sync
Estimated Time: 2-4 hours per location Vendor Involvement: Required for steps 2, 8 🔵
Open Dental Integration 🔵
Prerequisites ☐ Open Dental version 19.1 or higher ☐ Open Dental API key generated (in Setup > Program Links) ☐ CustomerKey from Open Dental (required for API access)
Step-by-Step Configuration
- ☐ Generate API key in Open Dental
- ☐ Provide API credentials to LocalMed 🔵
- ☐ Configure provider mapping via LocalMed portal
- ☐ Map appointment types and durations
- ☐ Set operatory preferences
- ☐ Configure scheduling rules (new patient, emergency, specialty)
- ☐ Test API connectivity
- ☐ Validate appointment sync (both directions)
- ☐ Confirm patient data mapping
Estimated Time: 1-2 hours per location (Open Dental's API is generally more straightforward) Vendor Involvement: Required for steps 2, 8 🔵
Website/Patient Portal Integration 🔵
Scheduling Widget Installation
Prerequisites ☐ Website CMS admin access (WordPress, Squarespace, custom, etc.) ☐ SSL certificate active on website ☐ LocalMed widget code from vendor 🔵
Step-by-Step Configuration
- ☐ Receive unique widget code for each location from LocalMed 🔵
- ☐ Identify widget placement location(s) on website:
- Homepage (prominent)
- Contact page
- Services pages
- Dedicated "Book Appointment" page
- ☐ Install widget code in appropriate page templates
- ☐ Configure widget styling to match website branding
- ☐ Test widget functionality across browsers (Chrome, Safari, Firefox, Edge)
- ☐ Test mobile responsiveness
- ☐ Verify tracking/analytics integration if applicable
- ☐ Set up conversion tracking (Google Analytics goal or event)
Estimated Time: 1-2 hours per location (varies by website complexity)
Test Environment Setup ⚠️
Centralized Test Environment (Recommended for DSOs)
Configuration ☐ Request sandbox/test environment from LocalMed 🔵 ☐ Create test location profiles mirroring pilot locations ☐ Configure test PMS connections (use test database if available, or designate test operatory) ☐ Populate with representative test data:
- Provider schedules
- Appointment types
- Insurance parameters
- Scheduling rules
Validation Checklist
Integration Validation ☐ Create appointment via LocalMed → verify appears in PMS within 60 seconds ☐ Create appointment in PMS → verify LocalMed availability updates ☐ Cancel appointment in PMS → verify LocalMed reflects cancellation ☐ Modify appointment in LocalMed → verify PMS updates ☐ Test patient demographic sync (new patient vs. existing patient) ☐ Test insurance eligibility display (if configured)
Scheduling Logic Validation ☐ Test new patient booking flow (correct appointment type, duration, operatory assignment) ☐ Test existing patient booking flow (recognition, history display) ☐ Test provider-specific restrictions (specialty procedures, certifications) ☐ Test time restrictions (morning-only providers, specific day availability) ☐ Test buffer time rules (gaps between appointment types) ☐ Test overbooking prevention ☐ Test same-day booking rules (if restricted)
Edge Case Validation ⚠️ ☐ Test booking at schedule boundaries (first/last slot of day) ☐ Test booking during holidays/blocked time ☐ Test multiple simultaneous booking attempts ☐ Test booking when provider schedule changes mid-session ☐ Test handling of PMS-side schedule conflicts
Data Migration/Historical Data
LocalMed is primarily a forward-looking scheduling tool; historical appointment data migration is typically not required. However, the following data preparation ensures optimal configuration:
Data Preparation Checklist
☐ Export current appointment types and average durations from PMS ☐ Document current scheduling rules (written or tribal knowledge) ☐ Compile provider preference documentation ☐ Export operatory configurations ☐ Document insurance-based scheduling restrictions (if applicable)
Security and HIPAA Compliance Verification
Enterprise-Level HIPAA Checklist 🟣
Business Associate Agreement ☐ Executed BAA with LocalMed on file 🔵 ☐ BAA covers all protected health information (PHI) transmission and storage ☐ BAA includes breach notification requirements ☐ Legal review completed 🟣
Data Governance ☐ Document what PHI LocalMed will access:
- Patient name, DOB, contact information
- Insurance information
- Appointment history
- Limited clinical information (appointment type) ☐ Confirm data residency (where is data stored/processed) 🔵 ☐ Verify encryption standards:
- Data in transit: TLS 1.2+ ☐
- Data at rest: AES-256 ☐ ☐ Confirm data retention policies align with organizational requirements 🔵 ☐ Verify data deletion/export capabilities for patient requests
Access Controls ☐ Role-based access control implemented ☐ Individual user accounts (no shared logins) ☐ Audit logging enabled for all PHI access ☐ Session timeout configured (recommend: 15 minutes inactivity) ☐ Multi-factor authentication enabled for admin accounts
Security Assessment ☐ Request LocalMed's SOC 2 Type II report 🔵 ☐ Review LocalMed's security policies and incident response plan 🔵 ☐ Conduct internal security assessment or engage third-party ☐ Document any compensating controls required ☐ Schedule annual security review
DSO-Specific Configuration
Standardized Configuration Template
The following settings should be IDENTICAL across all locations:
| Configuration Element | Standardize? | Rationale |
|---|---|---|
| Appointment type names | Yes | Consistent patient experience, unified reporting |
| Appointment type durations | Yes (with exceptions) | Capacity planning, scheduling efficiency |
| New patient booking flow | Yes | Brand consistency |
| Widget branding/styling | Yes | Brand consistency |
| Insurance verification rules | Yes | Consistent patient messaging |
| Confirmation message templates | Yes | Brand voice |
| Cancellation policy display | Yes | Legal consistency |
| Data retention settings | Yes | Compliance |
| User role definitions | Yes | Governance |
Location-Specific Configuration
The following settings CAN/SHOULD vary by location:
| Configuration Element | Allow Variance? | Rationale |
|---|---|---|
| Provider schedules | Yes | Individual provider availability |
| Operatory assignments | Yes | Physical differences between locations |
| Provider-specific appointment types | Yes | Specialty differences |
| Emergency slot frequency | Yes | Based on local demand patterns |
| Specific blocking rules | Yes | Local events, preferences |
| Office hours | Yes | Market differences |
| Holiday schedules | Partial | Regional holidays may differ |
Configuration Template Management
☐ Create master configuration template in LocalMed portal 🔵 ☐ Document all standard settings with rationale ☐ Create location configuration checklist for regional managers ☐ Establish change control process for template modifications 🟣 ☐ Schedule quarterly configuration audit across locations
6. Team Training Plan
Train-the-Trainer Model
Overview
For DSO-scale deployment, a centralized training approach is not sustainable. Instead, deploy a train-the-trainer model where certified champions at each location deliver training to their teams.
Champion Selection Criteria
| Criteria | Weight | Assessment Method |
|---|---|---|
| Tenure at location | Medium | >12 months preferred |
| Tech comfort level | High | Self-assessment + manager observation |
| Peer influence | High | Are they respected? Do others go to them for help? |
| Reliability | High | Attendance record, task completion history |
| Communication skills | High | Can they explain concepts clearly? |
| Enthusiasm for the initiative | Medium | Volunteers preferred over conscripts |
Ideal Champion Profile: Office manager or senior front desk team member with strong peer relationships and demonstrated comfort with technology. Backup champion: Lead hygienist or associate dentist (for provider-specific training).
Champion Responsibilities
- Complete champion certification training (2-hour session with vendor + practice exercises)
- Deliver training to all staff at their location
- Serve as first-line support for questions and issues
- Provide daily check-in reports during go-live week
- Identify and escalate issues requiring vendor/IT involvement
- Conduct training for new hires
Champion Certification Program 🔵
Certification Training (Vendor-Led)
Format: Virtual instructor-led training via video conference Duration: 2 hours per session Class Size: 8-12 champions per session Sessions Required: Calculate based on total locations (e.g., 50 locations ÷ 10 per session = 5 sessions)
**Agenda
AI-generated implementation guide based on public vendor information. Verify specifics directly with LocalMed.