Oryx Dental
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
Oryx Dental — Implementation Playbook (DSO)
Oryx Dental Implementation Playbook
Practice Management AI for Dental Support Organizations
Version 1.0 | DSO Edition
1. Executive Summary
What Oryx Dental Does
Oryx Dental is a cloud-based practice management platform with integrated AI capabilities designed to unify clinical workflows, patient engagement, billing operations, and business intelligence across multiple dental locations. The platform consolidates scheduling, charting, treatment planning, patient communications, insurance verification, and analytics into a single system with AI-driven automation for claims processing, patient recall optimization, and operational insights.
Why DSOs Benefit from AI-Powered Practice Management at Scale
DSOs operating 15–50+ locations face a fundamental challenge: achieving operational consistency while maintaining clinical autonomy. Traditional practice management systems create data silos, inconsistent workflows, and fragmented reporting that compound exponentially with each location added.
Scale Advantages:
- Data Aggregation: Consolidated patient records, financial data, and operational metrics across all locations enable pattern recognition impossible in siloed systems
- Standardization Without Rigidity: AI learns from your highest-performing locations and propagates best practices while allowing location-appropriate flexibility
- Centralized Intelligence: One platform means one source of truth for executive reporting, compliance auditing, and strategic planning
- Negotiating Leverage: Unified claims data across locations strengthens payer negotiations and identifies systematic denial patterns
Category-Specific DSO Benefits:
- Reduce administrative overhead by 20–35% through automated patient communications, insurance verification, and claims scrubbing
- Enable cross-location patient portability with unified records
- Standardize coding practices to minimize compliance risk and revenue leakage
- Generate real-time dashboards for regional managers without manual data compilation
Expected Timeline: Decision to Full Deployment
| Phase | Timeline | Description |
|---|---|---|
| Pre-Implementation | Weeks 1–2 | Stakeholder alignment, baseline metrics, infrastructure assessment |
| Wave 1 Pilot | Weeks 3–6 | 2–3 pilot locations live, intensive learning capture |
| Wave 2 Expansion | Weeks 7–12 | Next 5–8 locations, refined playbook |
| Wave 3 Full Deployment | Weeks 13–20 | Remaining locations, parallel processing |
| Optimization | Weeks 21–24 | Fine-tuning, advanced feature activation |
Total Timeline: 5–6 months for a 30-location DSO
Larger portfolios (40–50 locations) should plan for 7–8 months. Rushing deployment to save weeks will cost months in remediation.
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware Requirements per Location
☐ Workstations: Windows 10/11 or macOS 12+ with minimum 8GB RAM, SSD storage (12 months old or newer preferred) ☐ Displays: 1920x1080 resolution minimum; dual monitors recommended for clinical workstations ☐ Tablets (if using chairside features): iPad 8th generation+ or Android tablets with Chrome support ☐ Printers: Network-capable for patient forms, treatment plans, claims ☐ Scanners: Insurance card and document scanning capability ☐ Signature pads (if transitioning from paper consents): Topaz or compatible USB devices
Software Requirements
☐ Supported browsers: Chrome (primary), Edge, Safari (latest versions) ☐ Current antivirus/endpoint protection that allows Oryx cloud connections ☐ No conflicting local software that locks ports 443, 8080
Network Requirements (⚠️ Most common failure point)
☐ Minimum bandwidth: 50 Mbps down / 20 Mbps up per location (100/50 recommended) ☐ Latency: <50ms to Oryx cloud servers ☐ Dedicated VLAN or network segment for practice management traffic (recommended) ☐ Firewall rules allowing outbound connections to Oryx domains (whitelist provided during onboarding) ☐ Guest Wi-Fi segregated from practice network ☐ Backup internet connection (LTE/5G failover) for business continuity
Integration Requirements
☐ Inventory existing tech stack per location:
- Current PMS (Dentrix, Eaglesoft, Open Dental, other)
- Imaging system (Dexis, Schick, Carestream, other)
- Patient communication platform (if separate from PMS)
- Payment processing system
- HR/payroll system (for provider schedule imports)
Vendor Onboarding Steps
| Step | Owner | Timeline | Notes |
|---|---|---|---|
| 🔵 Execute Master Services Agreement | Legal + Oryx | Day 1 | Include BAA, SLA terms |
| 🔵 Complete enterprise customer questionnaire | IT + Oryx | Days 1–3 | Oryx provides template |
| 🔵 Establish Oryx account team contacts | Project Lead | Day 2 | Get names, emails, phone for: Implementation Manager, Technical Lead, Support Escalation |
| 🔵 Schedule kickoff call | Project Lead + Oryx | Day 3 | Include C-suite sponsor, IT lead |
| 🔵 Receive test environment credentials | IT + Oryx | Day 5 | One test instance for central team initially |
| 🔵 Define success criteria jointly | Ops + Oryx | Day 7 | Document mutually agreed KPIs |
Key Vendor Contacts to Establish:
- Implementation Project Manager (your primary contact)
- Technical Integration Specialist (for API and data questions)
- Tier 2 Support Escalation (for issues beyond standard support)
- Customer Success Manager (for post-deployment relationship)
- Executive Sponsor (Oryx side, for escalation if needed)
Data/Access Prerequisites
Per-Location Data Collection
☐ Current PMS login credentials (admin-level for data export) ☐ Historical patient database size and date range ☐ Active patient count (seen within last 18 months) ☐ Insurance payer mix documentation ☐ Current fee schedules (UCR and contracted) ☐ Provider NPI and licensing information ☐ Location tax ID and practice information ☐ Imaging archive access credentials ☐ Patient communication template inventory
Enterprise-Level Data
☐ Corporate entity structure documentation ☐ Consolidated chart of accounts (if standardizing financial reporting) ☐ Brand guidelines for patient-facing communications ☐ Employee roster with roles and locations
Enterprise-Level Requirements
Network Standards Across Locations
🟣 Decision Required: Centralized hosting vs. distributed architecture
| Architecture | Best For | Considerations |
|---|---|---|
| Centralized | Locations with reliable high-speed internet; organizations prioritizing data governance | Single point of control; requires robust connectivity |
| Distributed | Locations in areas with variable connectivity; organizations needing offline capability | More complex management; local data sync requirements |
Recommendation: Oryx Dental is cloud-native; adopt centralized with local caching for resilience.
Single Sign-On (SSO)
☐ Determine SSO provider (Okta, Azure AD, Google Workspace) ☐ 🔵 Confirm Oryx SAML/OIDC compatibility ☐ Map role-based access control (RBAC) groups to Oryx permission levels ☐ Plan SSO rollout timing relative to Oryx deployment
Centralized Credentialing
☐ Document current provider credentialing process ☐ Identify integration points with Oryx provider management ☐ Establish workflow for new provider onboarding post-implementation
Internal Stakeholder Alignment
Stakeholder Alignment Map
| Stakeholder Level | Names/Roles | Involvement Type | Communication Cadence |
|---|---|---|---|
| Board/Investors | [List names] | Informed | Monthly summary, milestone updates |
| C-Suite | CEO, COO, CDO, CFO | Approve + Sponsor | Weekly briefing, go/no-go decisions |
| Regional Managers | [List by region] | Accountable for locations | Weekly status, daily during wave deployment |
| Location Office Managers | [List all] | Responsible for local execution | Daily during rollout, then weekly |
| Lead Providers | [List by location] | Clinical workflow approval | Pre-deployment training, workflow validation |
| IT Leadership | CIO/IT Director | Technical ownership | Daily during implementation, weekly ongoing |
🟣 Approval Gates Required
☐ Budget approval for implementation costs, ongoing subscription ☐ Data migration scope approval ☐ Go-live date approval for each wave ☐ Rollback criteria approval ☐ Staff overtime/training time budget approval
Baseline Metrics to Capture
⚠️ Critical: Measure these BEFORE go-live or ROI calculation becomes impossible.
Standardized Metric Collection Protocol
Instruct all locations to pull identical reports for the same 90-day period.
| Metric Category | Specific Metric | Current Measurement Method | Target Collection Date |
|---|---|---|---|
| Revenue Cycle | Average days to claim submission | PMS report | Week 1 |
| Claim denial rate (% of claims) | PMS or clearinghouse | Week 1 | |
| Average days to payment | PMS report | Week 1 | |
| Collections rate (% of production) | PMS report | Week 1 | |
| Patient Flow | New patient volume (monthly) | PMS report | Week 1 |
| Patient no-show rate | PMS report | Week 1 | |
| Recall effectiveness rate | PMS report | Week 1 | |
| Average time from scheduling to appointment | Manual tracking or PMS | Week 1 | |
| Clinical | Case acceptance rate | Manual tracking | Week 1 |
| Average treatment plan value | PMS report | Week 1 | |
| Production per provider per day | PMS report | Week 1 | |
| Operational | Front desk hours spent on scheduling (estimated) | Time study | Week 1 |
| Time spent on insurance verification per patient | Time study | Week 1 | |
| Patient check-in time | Time study | Week 1 |
Cross-Location Standardization Requirements:
- Use identical date ranges (e.g., last complete 90 days)
- Apply consistent definitions (e.g., "active patient" = seen within 18 months)
- Use same report templates from current PMS
- Central team compiles and validates before baseline is locked
☐ Create shared folder for baseline data collection ☐ Assign Regional Manager responsibility for location compliance ☐ Set deadline for baseline submission: End of Week 1 ☐ Central team validates data quality by Day 10 ☐ 🟣 Executive sign-off on baseline data set: Day 12
3. Location Readiness Assessment
Scoring Framework
Score each location on a 1–5 scale for each factor, then calculate composite score.
Factor 1: IT Infrastructure Maturity (Weight: 25%)
| Score | Criteria |
|---|---|
| 5 | Fiber internet 100+ Mbps, all workstations <3 years old, modern network equipment, IT-managed |
| 4 | 50+ Mbps internet, workstations <5 years old, stable network |
| 3 | 25–50 Mbps, mixed-age workstations, occasional network issues |
| 2 | <25 Mbps, workstations 5+ years old, frequent network issues |
| 1 | Unreliable internet, outdated hardware requiring replacement, no on-site IT capability |
Factor 2: Staff Tenure and Adaptability (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | >80% staff tenure 2+ years, history of successful tech adoption, low turnover (<15%) |
| 4 | 60–80% tenure 2+ years, generally positive toward tech, moderate turnover (15–25%) |
| 3 | Mixed tenure, neutral toward tech, average turnover (25–35%) |
| 2 | <50% tenure 2+ years, some tech resistance history, high turnover (35–50%) |
| 1 | High turnover (>50%), documented resistance to past changes, unstable team |
Factor 3: Patient Volume (Weight: 15%)
| Score | Impact Assessment |
|---|---|
| 5 | High volume (40+ patients/day): Highest impact potential, but needs strong execution |
| 4 | Medium-high (30–40 patients/day): Good impact, manageable complexity |
| 3 | Medium (20–30 patients/day): Balanced risk/reward, good for pilots |
| 2 | Medium-low (10–20 patients/day): Lower risk, limited data for learning |
| 1 | Low volume (<10 patients/day): Limited implementation value, not priority |
Note: For pilot selection, score 3–4 is often ideal (meaningful volume without overwhelming risk).
Factor 4: Tech Stack Compatibility (Weight: 25%)
| Score | Criteria |
|---|---|
| 5 | Current PMS has documented Oryx integration, imaging system compatible, clean data |
| 4 | PMS integration available, minor imaging compatibility work needed |
| 3 | PMS requires custom integration work, moderate data cleanup needed |
| 2 | PMS integration challenging, significant data cleanup or manual migration required |
| 1 | PMS not compatible, requires full replacement or manual data transfer |
🔵 Oryx involvement required: Request compatibility assessment during pre-implementation.
Factor 5: Local Champion Availability (Weight: 15%)
| Score | Criteria |
|---|---|
| 5 | Enthusiastic, tech-savvy Office Manager AND provider willing to champion; training experience |
| 4 | One strong champion (either OM or provider) with tech aptitude |
| 3 | Potential champion identified but needs development |
| 2 | No clear champion; most likely candidate is neutral |
| 1 | No viable champion; resistance from potential candidates |
Composite Score Calculation
Formula: (IF × 0.25) + (SA × 0.20) + (PV × 0.15) + (TC × 0.25) + (LC × 0.15) = Composite Score
| Composite Score | Readiness Tier | Rollout Recommendation |
|---|---|---|
| 4.0 – 5.0 | Tier 1: High Readiness | Candidate for Wave 1 pilot |
| 3.0 – 3.9 | Tier 2: Moderate Readiness | Wave 2 deployment |
| 2.0 – 2.9 | Tier 3: Remediation Needed | Wave 3 after infrastructure/staffing improvements |
| <2.0 | Tier 4: Not Ready | Defer until prerequisites addressed |
Recommended Rollout Sequence
Step 1: Complete Assessment
☐ Central team provides assessment template to Regional Managers ☐ Regional Managers score each location with Office Manager input ☐ IT validates infrastructure scores with technical verification ☐ Central team aggregates and ranks all locations
Step 2: Select Wave 1 Pilots (2–3 locations)
Selection Criteria:
- Composite score 4.0+ (high readiness)
- Represents different regions/geographies (if applicable)
- Mix of practice types (GP, specialty mix) that reflects portfolio
- Office Manager enthusiastic and available for extended support
- NOT your highest-volume location (minimize patient impact risk)
- NOT your most problematic location (set up for success)
Anti-Pattern to Avoid: Choosing only your "easiest" locations for pilot. Pilots must be representative enough to generate learnings that transfer.
Step 3: Plan Remediation for Tier 3–4 Locations
☐ Create infrastructure upgrade timeline ☐ Identify staffing changes or training needed ☐ Set re-assessment date ☐ Decide: remediate in parallel with early waves vs. defer
4. Rollout Strategy
Recommended Wave Structure
| Wave | Locations | Timeline | Purpose |
|---|---|---|---|
| Wave 1 | 2–3 pilot locations | Weeks 3–6 | Validate integration, refine training, build playbook |
| Wave 2 | 5–8 locations | Weeks 7–12 | Scale learnings, stress-test support model |
| Wave 3 | Remaining locations | Weeks 13–20 | Full deployment with optimized process |
Wave Timeline Detail
Week 3: Wave 1 configuration and integration begins
Week 4: Wave 1 training delivered
Week 5: Wave 1 go-live (staggered by 2–3 days per location)
Week 6: Wave 1 stabilization and learning capture
Week 7: Wave 2 configuration begins
Week 8: Wave 2 training delivered
Weeks 9–10: Wave 2 go-live (staggered)
Weeks 11–12: Wave 2 stabilization
Week 13–14: Wave 3 Group A configuration
Week 15: Wave 3 Group A go-live
Week 16–17: Wave 3 Group B configuration + go-live
Week 18–20: Wave 3 Group C + D (as applicable)
Buffer Requirement: Minimum 1 week between waves for learning integration. Do not compress.
Wave 1 Pilot Selection Criteria
Mandatory Criteria
☐ Composite readiness score ≥4.0 ☐ Office Manager available for additional support (not on PTO, not distracted by other initiatives) ☐ Stable staffing (no recent turnover, no expected departures) ☐ Current PMS in supported integration tier ☐ No major patient-facing events during go-live week (open houses, marketing pushes)
Preferred Criteria
☐ Located near regional or central office (for on-site support visits) ☐ Provider is engaged and supportive (not just tolerant) ☐ Past history of successful change adoption ☐ Variety in practice type to test Oryx across scenarios
🟣 Decision: Wave 1 Site Selection
Present 4–5 candidate locations to executive sponsor. Final selection of 2–3 sites requires sign-off.
Go/No-Go Criteria
Wave 1 → Wave 2 Advancement
| Criterion | Threshold | Measurement |
|---|---|---|
| System stability | <3 critical bugs requiring Oryx escalation | Support ticket log |
| Data integrity | 100% patient records migrated correctly | Audit sample |
| Staff competency | 80%+ staff pass competency check | Training completion records |
| Workflow completion | Core workflows functional without workarounds | Champion report |
| Patient impact | Zero patient complaints attributable to system | Patient feedback, staff reports |
All criteria must be met before Wave 2 begins.
Wave 2 → Wave 3 Advancement
| Criterion | Threshold | Measurement |
|---|---|---|
| System stability | <1 critical bug per location | Support ticket log |
| Training scalability | Train-the-trainer model working | Champion feedback |
| Support capacity | Central team can handle 15+ locations | Support queue metrics |
| Process documentation | Playbook updated with Wave 2 learnings | Document review |
Rollback Plan
Triggers for Rollback Consideration
- Critical system outage >4 hours affecting patient care
- Data integrity issue affecting clinical records
- 50%+ staff unable to complete core workflows after training
- Patient safety concern (misrouted prescriptions, incorrect records displayed)
Rollback Procedure (Per Location)
| Step | Action | Owner | Timeline |
|---|---|---|---|
| 1 | Declare rollback, notify Oryx support | Central Team | Immediate |
| 2 | Reactivate legacy PMS access | IT | Within 2 hours |
| 3 | Notify location staff, provide legacy workflow reference | Office Manager | Within 2 hours |
| 4 | Export any data entered in Oryx during go-live period | IT + Oryx | Within 24 hours |
| 5 | Conduct root cause analysis | Central + Oryx | Within 72 hours |
| 6 | Develop remediation plan | All stakeholders | Within 1 week |
| 7 | 🟣 Re-attempt decision with executive approval | C-suite | Per remediation plan |
Isolation Protocol
If one location requires rollback:
- Do NOT halt other locations unless root cause indicates systemic issue
- Central team assesses whether issue is location-specific or platform-wide
- Continue other wave deployments unless 2+ locations experience same issue
5. Configuration & Integration (Weeks 2–3)
Integration with Practice Management Systems
Dentrix Integration
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | Confirm Dentrix version compatibility (G7.4+) | IT | 15 min | 🔵 Oryx provides version matrix |
| 2 | Export patient database using Dentrix Report Builder | IT | 2 hours | ⚠️ Run during off-hours |
| 3 | Configure Dentrix API connector in Oryx | IT + Oryx | 1 hour | 🔵 Oryx guides configuration |
| 4 | Map field mappings (patient demographics, procedures, insurance) | IT + Oryx | 2 hours | Use Oryx mapping template |
| 5 | Test patient lookup, appointment sync | IT | 1 hour | Document any discrepancies |
| 6 | Test bidirectional updates | IT | 1 hour | Create test patient, modify in both systems |
| 7 | Validate insurance information transfer | Billing Lead | 2 hours | Compare 10 random records |
Eaglesoft Integration
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | Confirm Eaglesoft version (21+) | IT | 15 min | 🔵 Oryx provides version matrix |
| 2 | Enable Eaglesoft HL7 interface | IT | 30 min | May require Patterson support |
| 3 | Export historical data via Eaglesoft utility | IT | 3 hours | ⚠️ Database size affects time |
| 4 | 🔵 Oryx ingests Eaglesoft export | Oryx | 4–24 hours | Depends on data volume |
| 5 | Configure real-time sync connector | IT + Oryx | 2 hours | |
| 6 | Test appointment synchronization | Office Manager | 1 hour | Create/modify appointments in both |
| 7 | Validate procedure history transfer | Provider | 1 hour | Review 5 patient charts |
Open Dental Integration
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | Confirm Open Dental version compatibility | IT | 15 min | 🔵 Open Dental API typically compatible |
| 2 | Generate API key in Open Dental | IT | 10 min | Admin → API Keys |
| 3 | Enter API credentials in Oryx | IT | 10 min | |
| 4 | 🔵 Oryx pulls initial data sync | Oryx | 2–4 hours | Automated process |
| 5 | Configure sync frequency (recommend: 5 min) | IT | 15 min | |
| 6 | Test bidirectional patient updates | IT | 1 hour | |
| 7 | Validate financial data transfer | Billing Lead | 2 hours | Reconcile account balances |
Integration with Imaging Systems
General Imaging Integration Steps
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | Document imaging system and version | IT | 15 min | Dexis, Schick, Carestream, XDR, etc. |
| 2 | 🔵 Confirm Oryx compatibility | Oryx | 30 min | Some systems require bridge software |
| 3 | Establish DICOM or proprietary connection | IT + Oryx | 2 hours | ⚠️ Network configuration critical |
| 4 | Test image pull from Oryx interface | Provider | 30 min | Open patient chart, view images |
| 5 | Test image capture trigger | Clinical staff | 30 min | Take test image, confirm appears in Oryx |
| 6 | Validate image quality and metadata | Provider | 30 min | Ensure date, tooth number correct |
Test Environment Setup
☐ 🔵 Request dedicated test environment from Oryx (1 per Wave during rollout) ☐ Populate test environment with anonymized or synthetic data ☐ Create test user accounts mirroring production roles ☐ Document test scenarios to validate:
- Patient check-in workflow
- Appointment scheduling
- Treatment planning
- Clinical charting
- Insurance verification
- Claims submission
- Payment posting
- Reporting
Test Environment Validation Checklist
| Workflow | Test Case | Pass/Fail | Notes |
|---|---|---|---|
| Scheduling | Create new patient appointment | ||
| Scheduling | Modify existing appointment | ||
| Scheduling | Cancel appointment, verify recall created | ||
| Check-in | Patient self check-in (if using kiosk) | ||
| Check-in | Staff check-in, insurance verification triggered | ||
| Charting | Enter clinical notes, perio chart | ||
| Treatment | Create treatment plan, present to patient | ||
| Imaging | View existing images in chart | ||
| Imaging | Capture new image, verify storage | ||
| Insurance | Verify eligibility | ||
| Claims | Submit claim, track status | ||
| Payment | Post patient payment | ||
| Payment | Post insurance payment/ERA | ||
| Reporting | Run production report | ||
| Reporting | Run A/R aging report |
Data Migration
Migration Phases
Phase 1: Core Data (Required before Go-Live) ☐ Patient demographics ☐ Insurance information ☐ Appointment history (minimum 2 years) ☐ Provider and operatory setup ☐ Fee schedules ☐ Treatment codes and categories
Phase 2: Clinical History (Can continue post-Go-Live) ☐ Clinical notes ☐ Treatment history ☐ Perio charts ☐ Imaging archives (can be phased)
Phase 3: Financial History (Timeline varies) ☐ Account ledgers ☐ Outstanding balances ☐ Payment history ☐ Claims history
⚠️ Data Migration Common Failure Points
- Duplicate patients: Run deduplication before migration
- Incomplete insurance records: Verify payer IDs, group numbers
- Date format inconsistencies: Standardize before import
- Missing provider NPIs: Audit provider records pre-migration
Security and HIPAA Compliance
Enterprise-Level HIPAA Checklist
| Requirement | Action | Owner | Status |
|---|---|---|---|
| BAA Execution | 🔵 Sign Business Associate Agreement with Oryx | Legal | ☐ |
| Data Encryption (Transit) | Confirm TLS 1.2+ for all connections | IT + Oryx | ☐ |
| Data Encryption (Rest) | Confirm AES-256 encryption at rest | IT + Oryx | ☐ |
| Access Controls | Define RBAC roles matching organization structure | IT + HR | ☐ |
| Audit Logging | Confirm Oryx audit logs meet retention requirements | IT + Compliance | ☐ |
| Minimum Necessary | Configure role-based data visibility | IT + Compliance | ☐ |
| Breach Notification | Confirm Oryx breach notification procedures in BAA | Legal | ☐ |
| Data Backup | Document Oryx backup frequency and recovery RPO/RTO | IT | ☐ |
| Employee Training | Include HIPAA refresher in Oryx training | HR + Training | ☐ |
| Physical Security | Workstation timeout policies configured | IT | ☐ |
Per-Location Security Verification
☐ Workstation auto-lock configured (recommend: 5 minutes inactivity) ☐ Staff access provisioned with correct role ☐ Former employee accounts disabled ☐ Shared login accounts eliminated ☐ Patient-facing screens positioned away from waiting area
Standardized vs. Location-Specific Configuration
Standardize Centrally
| Configuration Element | Rationale |
|---|---|
| Procedure code library | Consistent coding for reporting, compliance |
| Fee schedule structure | Enable cross-location comparison |
| RBAC role definitions | Security consistency |
| Appointment type categories | Standardized scheduling metrics |
| Patient communication templates | Brand consistency |
| Report templates | Cross-location comparability |
| Insurance payer aliases | Standardized claims routing |
| Recall intervals | Clinical consistency |
Allow Local Discretion
| Configuration Element | Rationale |
|---|---|
| Provider-specific preferences (chart colors, shortcuts) | Individual productivity |
| Operatory naming | Local workflow |
| Business hours | Location-specific |
| Contracted fee schedules | Payer-specific by market |
| Local referral network | Geographic variation |
| Patient communication timing | Patient population preferences |
6. Team Training Plan
Train-the-Trainer Model
Champion Selection Criteria
Mandatory: ☐ Full-time employee, minimum 1 year tenure at location ☐ Proficient with current PMS (top 25% of users) ☐ Strong communication skills (can explain complex topics simply) ☐ Available for 8 hours of champion-specific training ☐ Committed to supporting go-live and first 30 days
Preferred: ☐ Office Manager or lead provider ☐ Previous training or teaching experience ☐ Respected by peers (influence, not just authority) ☐ Patient and even-tempered (will face frustrated colleagues)
Champion Responsibilities
| Phase | Responsibility |
|---|---|
| Pre-Go-Live | Complete champion certification training |
| Pre-Go-Live | Deliver role-specific training to location staff |
| Pre-Go-Live | Verify training completion for all staff |
| Go-Live Day | Serve as on-site first responder for questions |
| First Week | Daily check-in with central team |
| First Month | Weekly pulse survey administration |
| Ongoing | Train new hires, deliver refresher training |
Champion Certification Process
| Step | Duration | Format | Owner |
|---|---|---|---|
| 1. Complete all role-based training modules | 4 hours | Online | Champion |
| 2. Attend champion-specific session | 2 hours | Live (virtual) | 🔵 Oryx |
| 3. Pass champion competency assessment | 1 hour | Online quiz | Central Team |
| 4. Shadow existing champion (Wave 2+) | 2 hours | Observation | Central Team |
| 5. Receive certification and training materials | — | — | Central Team |
Role-Specific Training Outlines
Dentists/Providers
Estimated Training Time: 2 hours
Recommended Format: 90-minute live demo (in-person or video) + 30-minute hands-on practice in test environment
Core Content:
- Logging in, navigation overview (15 min)
- Patient chart access: where clinical information lives (15 min)
- Treatment planning workflow: creating, modifying, presenting (25 min)
- Clinical notes and charting interface (20 min)
- AI-assisted features: how to interpret recommendations, when to override (15 min)
- E-prescribing workflow (if applicable) (10 min)
What Changes for Providers:
- Treatment planning moves from [legacy location] to Oryx treatment module
- AI will pre-populate suggested treatment codes based on chart history—verify, don't assume
- Imaging access is now integrated (no switching applications)
- Electronic signatures on consents
Common Resistance Points & Responses:
| Resistance | Response |
|---|---|
| "I don't have time for this" | "Training is 2 hours total. The time you spend now will save 15+ minutes per day once proficient." |
AI-generated implementation guide based on public vendor information. Verify specifics directly with Oryx Dental.