OraQ AI (Data Infrastructure)
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
OraQ AI (Data Infrastructure) — Implementation Playbook (DSO)
OraQ AI Implementation Playbook
Data Infrastructure Deployment for Dental Support Organizations
1. Executive Summary
What OraQ AI Does
OraQ AI is a data infrastructure platform that aggregates, normalizes, and analyzes clinical and operational data across dental practice networks. It creates a unified data layer connecting practice management systems, imaging systems, and clinical workflows—transforming fragmented location-level data into enterprise-grade business intelligence and clinical analytics.
Why DSOs Benefit from This Category of AI
Data infrastructure tools deliver exponential value at scale. A single practice generates useful data; 15–50 locations generate strategic intelligence. DSOs specifically benefit from:
- Standardization: Enforce consistent data definitions across locations—so "case acceptance" means the same thing in Phoenix as it does in Philadelphia
- Aggregation: Surface network-wide patterns invisible at the location level (e.g., which operatory configurations correlate with higher production, which providers have unusual treatment planning variance)
- Benchmarking: Enable true apples-to-apples comparison across your portfolio
- Due Diligence: Clean, normalized data dramatically accelerates M&A integration and valuation accuracy
- Predictive Capability: Scale provides the data volume necessary for meaningful predictive analytics (patient churn, hygiene reactivation, provider capacity forecasting)
Expected Timeline
- Decision to Pilot Launch: 6–8 weeks
- Pilot to Wave 2: 4–6 weeks
- Full Deployment (15–50 locations): 16–24 weeks total
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware
☐ Verify server capacity for data aggregation (if on-premise component exists) ☐ Confirm workstation specifications meet minimum requirements at each location ☐ Assess network hardware age—switches and routers should be <5 years old
Software
☐ Document PMS versions across all locations (Dentrix, Eaglesoft, Open Dental, other) ☐ Inventory imaging systems (Dexis, Schick, Planmeca, etc.) and software versions ☐ Confirm operating systems are current (Windows 10/11, no legacy systems)
Network
☐ Minimum 100 Mbps symmetric bandwidth at each location (⚠️ common failure point—many locations have asymmetric connections with slow upload speeds) ☐ Static IP or VPN capability for secure data transmission ☐ Firewall rules documented and change management process identified
Integrations
☐ List all existing integrations per location (patient communication, insurance verification, etc.) ☐ Identify any custom-built data connections that may conflict
Vendor Onboarding Steps
| Step | Action | Owner | Timeline |
|---|---|---|---|
| 1 | 🔵 Schedule kickoff call with OraQ AI implementation team | VP Operations | Day 1 |
| 2 | 🔵 Assign dedicated OraQ AI implementation manager | Vendor | Day 1–3 |
| 3 | 🔵 Complete vendor security questionnaire | IT Director | Days 1–5 |
| 4 | 🔵 Execute BAA and MSA | Legal/Compliance | Days 1–7 |
| 5 | Establish communication channels (Slack, Teams, or email distribution) | Project Manager | Day 3 |
| 6 | 🔵 Receive technical documentation and API specifications | Vendor | Day 5 |
Key Contacts to Establish
☐ OraQ AI Implementation Manager (primary contact) ☐ OraQ AI Technical Support (Tier 1 and Tier 2) ☐ OraQ AI Customer Success Manager (post-implementation) ☐ OraQ AI Executive Sponsor (for escalations)
Data/Access Prerequisites
☐ PMS administrative credentials for each location (⚠️ often distributed across office managers—centralize early) ☐ Imaging system database access credentials ☐ API keys for any existing integrations ☐ Historical data access parameters (how far back? 1 year minimum recommended, 3 years ideal) ☐ 🔵 OraQ AI data connector installation credentials ☐ SFTP or secure transfer mechanism for initial data migration
Enterprise-Level Requirements
Network Standards
🟣 ☐ Decide: Centralized hosting (all data flows to corporate) vs. Location-level hosting (data processed locally, aggregated centrally)
- Recommendation: Centralized hosting for DSOs—simplifies security, reduces local IT burden, enables true cross-location analytics
☐ Establish minimum network SLA per location (uptime, bandwidth, latency) ☐ Document network topology for each location ☐ Confirm VPN or SD-WAN capability for secure data transmission
Identity and Access Management
🟣 ☐ Decide: SSO integration (Azure AD, Okta, etc.) vs. OraQ AI native authentication
- Recommendation: SSO for organizations with existing identity management—reduces credential sprawl
☐ Define role-based access control (RBAC) structure:
- Corporate Admin (full access)
- Regional Manager (multi-location view, no configuration)
- Office Manager (single-location view)
- Provider (clinical data only, own patients)
- Analyst (aggregate data, no PHI)
Centralized Credentialing
☐ Create master credentials spreadsheet (encrypted) with all location access ☐ Establish credential rotation policy ☐ Document break-glass procedures for emergency access
Internal Stakeholder Alignment
Stakeholder Alignment Map
| Stakeholder | Role in Implementation | Communication Frequency | Key Concerns to Address |
|---|---|---|---|
| Board/Investors | Approve budget, receive ROI updates | Monthly | Investment justification, competitive positioning, timeline to value |
| C-Suite | Executive sponsorship, resource allocation | Bi-weekly | Strategic alignment, cross-functional impact, risk management |
| CDO/Chief Dental Officer | Clinical workflow approval, provider adoption | Weekly | Clinical accuracy, provider burden, patient safety |
| VP Operations | Day-to-day ownership, rollout execution | Daily during rollout | Operational disruption, staff capacity, timeline adherence |
| IT Director | Technical implementation, security | Daily during rollout | Integration complexity, security compliance, support burden |
| Regional Managers | Local execution, escalation | Weekly | Staff training, location readiness, local resistance |
| Office Managers | Location-level coordination | Weekly | Workflow changes, staff scheduling, day-to-day concerns |
| Providers | Clinical adoption, workflow compliance | Per-wave training | Time impact, clinical trust, workflow changes |
Approval Requirements
🟣 ☐ Budget approval: Board/C-suite 🟣 ☐ Security approval: IT Director/CISO 🟣 ☐ Clinical workflow approval: CDO 🟣 ☐ Timeline approval: VP Operations 🟣 ☐ BAA execution: Legal/Compliance
Baseline Metrics to Capture
⚠️ Critical: Capture these BEFORE go-live at every location. Without baselines, ROI measurement becomes opinion rather than fact.
Standardized Measurement Protocol
To enable cross-location comparison, establish uniform definitions:
| Metric | Definition | Data Source | Capture Method |
|---|---|---|---|
| Case Acceptance Rate | % of treatment plans presented that are scheduled within 30 days | PMS | Auto-extract |
| Average Diagnosis Time | Time from patient check-in to treatment plan presentation | PMS + manual sampling | 1-week time study |
| Production per Provider Hour | Total production / total scheduled provider hours | PMS | Auto-extract |
| Hygiene Reactivation Rate | % of patients 6+ months overdue who schedule within 60 days of outreach | PMS | Auto-extract |
| Claim Denial Rate | % of claims denied on first submission | PMS/Clearinghouse | Auto-extract |
| Data Entry Error Rate | % of charts with missing required fields | PMS | Audit sample |
| Report Generation Time | Time to produce standard operational reports | Manual | Log tracking |
| Inter-Location Data Reconciliation Time | Time to normalize data across locations for aggregate reporting | Manual | Log tracking |
Baseline Capture Checklist
☐ Distribute standardized measurement definitions to all office managers ☐ Set 2-week baseline capture window ☐ Collect data via PMS exports and manual tracking ☐ Aggregate baseline data centrally ☐ Create baseline report by location ☐ Identify outliers requiring investigation before go-live
3. Location Readiness Assessment
Scoring Framework
Score each location 1–5 on the following factors:
Factor 1: IT Infrastructure Maturity
| Score | Criteria |
|---|---|
| 1 | Internet <25 Mbps, hardware >7 years old, PMS version >3 releases behind |
| 2 | Internet 25–50 Mbps, hardware 5–7 years old, PMS version 2 releases behind |
| 3 | Internet 50–100 Mbps, hardware 3–5 years old, PMS version 1 release behind |
| 4 | Internet 100+ Mbps, hardware 1–3 years old, PMS current version |
| 5 | Internet 200+ Mbps, hardware <1 year old, PMS current with all modules, existing API integrations working |
Weight: 25%
Factor 2: Staff Tenure and Adaptability
| Score | Criteria |
|---|---|
| 1 | >50% annual turnover, no prior tech implementations, resistance to change in culture |
| 2 | 30–50% turnover, 1 failed tech implementation, mixed change receptivity |
| 3 | 15–30% turnover, 1 successful tech implementation, generally open to change |
| 4 | <15% turnover, multiple successful tech implementations, proactive improvement culture |
| 5 | <10% turnover, tech-forward culture, staff actively requests new tools |
Weight: 20%
Factor 3: Patient Volume
| Score | Criteria |
|---|---|
| 1 | <800 patient visits/month (low impact) |
| 2 | 800–1,200 visits/month |
| 3 | 1,200–1,600 visits/month (moderate impact and risk) |
| 4 | 1,600–2,000 visits/month |
| 5 | >2,000 visits/month (high impact, higher risk—consider whether this is pilot-appropriate) |
Weight: 15%
⚠️ Note: For pilot locations, a score of 3 or 4 is often ideal—enough volume to demonstrate value, not so much that issues cause major disruption.
Factor 4: Tech Stack Compatibility
| Score | Criteria |
|---|---|
| 1 | Non-standard PMS, legacy imaging, no existing integrations |
| 2 | Supported PMS but customized, imaging requires middleware |
| 3 | Standard PMS configuration, supported imaging system |
| 4 | Standard PMS, standard imaging, 1–2 existing integrations working smoothly |
| 5 | Standard PMS, standard imaging, multiple integrations, existing data warehouse connection |
Weight: 25%
Factor 5: Local Champion Availability
| Score | Criteria |
|---|---|
| 1 | No candidate—all staff at capacity or resistant |
| 2 | Potential candidate but lacks either time or influence |
| 3 | Willing candidate with moderate influence (e.g., lead hygienist) |
| 4 | Strong candidate—office manager or senior provider with time allocated |
| 5 | Exceptional candidate—tech-forward provider or OM who has led implementations before, actively volunteering |
Weight: 15%
Composite Score Calculation
Composite Score = (IT × 0.25) + (Staff × 0.20) + (Volume × 0.15) + (Tech Stack × 0.25) + (Champion × 0.15)
Readiness Tiers
| Composite Score | Tier | Rollout Recommendation |
|---|---|---|
| 4.0–5.0 | Tier 1: Ready | Wave 1 pilot candidate |
| 3.0–3.9 | Tier 2: Moderate | Wave 2—minimal prep needed |
| 2.0–2.9 | Tier 3: Needs Work | Wave 3—address gaps before rollout |
| <2.0 | Tier 4: Not Ready | Hold—significant infrastructure or staffing remediation required |
Sample Readiness Scorecard
| Location | IT (×.25) | Staff (×.20) | Volume (×.15) | Tech (×.25) | Champion (×.15) | Composite | Tier |
|---|---|---|---|---|---|---|---|
| Phoenix West | 4 | 4 | 3 | 5 | 5 | 4.20 | Tier 1 |
| Denver Main | 4 | 3 | 4 | 4 | 4 | 3.80 | Tier 2 |
| Austin South | 3 | 2 | 5 | 3 | 2 | 2.95 | Tier 3 |
| Seattle Downtown | 2 | 4 | 3 | 2 | 3 | 2.70 | Tier 3 |
| Miami Beach | 1 | 2 | 2 | 2 | 1 | 1.60 | Tier 4 |
Using Scores to Recommend Rollout Sequence
Wave 1 Pilot Selection (2–3 locations)
Select locations that are:
- ✅ Tier 1 readiness (composite 4.0+)
- ✅ Representative of your portfolio (different PMS systems, geography, size)
- ✅ Manageable risk (not your highest-revenue flagship—save that for Wave 2 when you have lessons learned)
- ✅ Strong champions who will provide candid feedback
Wave 2 Expansion (5–8 locations)
- All Tier 2 locations
- Tier 1 locations not selected for pilot
- Address any gaps identified in Tier 3 during Wave 1, upgrade those ready for Wave 2
Wave 3 Full Rollout (remaining locations)
- Tier 3 locations with remediated gaps
- Any Tier 4 locations that have been upgraded
🟣 Executive Decision: Determine whether Tier 4 locations should receive accelerated infrastructure investment to enable rollout, or whether they remain excluded from the initial deployment scope.
4. Rollout Strategy
Recommended Wave Structure
| Wave | Locations | Timeline | Objectives |
|---|---|---|---|
| Wave 1: Pilot | 2–3 Tier 1 locations | Weeks 6–9 | Validate integration, stress-test workflows, document lessons learned |
| Wave 2: Expansion | 5–8 Tier 2 locations | Weeks 11–16 | Scale validation, refine training materials, build internal expertise |
| Wave 3: Full Rollout | Remaining 7–39 locations | Weeks 18–24 | Efficient deployment using established playbook |
Timeline assumes 15–50 locations. Larger organizations (30+ locations) should extend Wave 3 or add a Wave 4.
Wave 1 Pilot Location Selection Criteria
Must-Have
☐ Composite readiness score ≥4.0 ☐ Champion available and committed ☐ PMS represents at least 25% of your portfolio (test common configurations) ☐ Location manager supportive of "learning mode" mentality
Nice-to-Have
☐ Geographic proximity to corporate (easier on-site support) ☐ Recent technology success (builds on momentum) ☐ Moderate volume (1,200–1,600 visits/month sweet spot)
Explicitly Avoid for Pilot
☐ Highest-revenue locations (too much risk if issues occur) ☐ Locations with active M&A integration (too many variables) ☐ Locations with recent leadership changes (unstable environment)
Timeline Per Wave with Learning Capture
Wave 1 (Weeks 6–9)
| Week | Activities |
|---|---|
| Week 6 | Configuration and integration for pilot locations, test environment validation |
| Week 7 | Champion training, staff training, parallel testing |
| Week 8 | Go-live pilot locations, daily monitoring |
| Week 9 | Stabilization, lesson capture, documentation refinement |
Buffer: Week 10 — Learning capture, documentation updates, Wave 2 prep
Wave 2 (Weeks 11–16)
| Week | Activities |
|---|---|
| Week 11–12 | Configuration for Wave 2 locations (2–3 locations per week) |
| Week 13–14 | Champion training, staff training |
| Week 15 | Go-live Wave 2 locations (staggered—2–3 per day if needed) |
| Week 16 | Stabilization, optimization |
Buffer: Week 17 — Learning capture, prepare for Wave 3
Wave 3 (Weeks 18–24)
| Week | Activities |
|---|---|
| Week 18–20 | Configuration for remaining locations (batch processing—5+ per week) |
| Week 21–22 | Champion training (train-the-trainer at scale) |
| Week 23 | Go-live remaining locations (staggered over 5 business days) |
| Week 24 | Stabilization, transition to BAU operations |
Go/No-Go Criteria to Advance Waves
From Wave 1 to Wave 2
| Category | Go Criteria | No-Go Triggers |
|---|---|---|
| Technical | All integrations functioning, data syncing within SLA | Any critical integration failure, data loss, or sync latency >2 hours |
| Operational | <5% increase in workflow time post-training | >15% increase in workflow time, staff completing workarounds |
| Adoption | 80%+ of target users logging in daily | <60% daily active usage |
| Stability | <3 escalations to vendor support per location per week | >10 escalations or any unresolved P1 issue |
| Feedback | Champion confidence rating ≥4/5 | Champion confidence <3/5 |
🟣 Approval Required: VP Operations and CDO must sign off on Wave advancement.
From Wave 2 to Wave 3
Same criteria as above, measured at aggregate Wave 2 level:
- 90%+ of Wave 2 locations meeting all Go criteria
- Remaining 10% have documented remediation plans and do not require vendor intervention
Rollback Plan
If a wave fails to meet Go criteria:
Immediate Actions (Days 1–3)
- ☐ Pause Wave—do not proceed to next locations
- ☐ Triage: Classify issue as Technical, Training, or Change Management
- ☐ 🔵 Engage OraQ AI escalation support if technical
- ☐ Document failure mode with specificity
- ☐ Communicate pause to all stakeholders (see Change Management section)
Recovery Path (Days 4–14)
- ☐ Root cause analysis with vendor and internal team
- ☐ Develop remediation plan with specific success criteria
- ☐ 🟣 Present remediation plan to C-suite for timeline adjustment
- ☐ Test remediation at affected locations
- ☐ Re-validate against Go criteria
- ☐ Resume Wave with updated playbook
Isolation Protocol
- Failing locations can be "quarantined"—reverted to pre-OraQ workflows while remainder of wave continues
- This requires clear data architecture that doesn't create dependency chains
- 🔵 Confirm with OraQ AI that location-level rollback is technically feasible before Wave 1
5. Configuration & Integration (Weeks 2–3)
PMS Integration: Step-by-Step
Dentrix Enterprise
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | 🔵 Confirm Dentrix Enterprise version compatibility with OraQ AI | IT + Vendor | 30 min |
| 2 | Export API credentials from Dentrix Enterprise admin console | IT | 15 min |
| 3 | ⚠️ Create dedicated service account for OraQ AI (do not use personal admin accounts) | IT | 20 min |
| 4 | 🔵 Install OraQ AI connector module on Dentrix server | Vendor + IT | 1–2 hours |
| 5 | Configure data scope (all patients vs. active only, date range) | IT | 30 min |
| 6 | 🔵 Run initial sync validation | Vendor | 1–2 hours |
| 7 | Verify record counts match between Dentrix and OraQ AI | IT | 30 min |
Total Time: 4–6 hours per location (can be parallelized)
Eaglesoft
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | 🔵 Confirm Eaglesoft version compatibility | IT + Vendor | 30 min |
| 2 | Enable ODBC connectivity in Eaglesoft (Admin > Preferences > Database) | IT | 20 min |
| 3 | ⚠️ Document database server location and port (often overlooked) | IT | 15 min |
| 4 | 🔵 Configure OraQ AI Eaglesoft connector | Vendor + IT | 1–2 hours |
| 5 | Map Eaglesoft procedure codes to OraQ AI taxonomy | IT + Vendor | 1 hour |
| 6 | 🔵 Run initial sync and validation | Vendor | 1–2 hours |
| 7 | Verify patient demographics, treatment history, and ledger sync | IT | 45 min |
Total Time: 5–7 hours per location
Open Dental
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | Confirm Open Dental version and hosting (on-premise vs. cloud) | IT | 15 min |
| 2 | 🔵 Generate API key from Open Dental (Setup > Program Links > API) | IT + Vendor | 30 min |
| 3 | Configure OraQ AI to connect via Open Dental REST API | IT + Vendor | 1 hour |
| 4 | ⚠️ Verify API rate limits are sufficient for initial data load | IT | 20 min |
| 5 | 🔵 Run initial sync | Vendor | 1–2 hours |
| 6 | Validate appointment, patient, and claim data accuracy | IT | 45 min |
Total Time: 4–5 hours per location
Imaging System Integration
General Steps (Dexis, Schick, Planmeca)
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | 🔵 Confirm imaging system compatibility with OraQ AI | IT + Vendor | 30 min |
| 2 | Document image storage location (local NAS, cloud, hybrid) | IT | 20 min |
| 3 | ⚠️ Verify image format support (DICOM, JPG, PNG, proprietary) | IT + Vendor | 30 min |
| 4 | 🔵 Configure image bridge or API connection | Vendor | 2–4 hours |
| 5 | Run test batch—sync 100 images and verify metadata accuracy | IT | 1 hour |
| 6 | Validate image-to-patient linkage accuracy | IT + Clinical Lead | 45 min |
Total Time: 5–7 hours per location
Test Environment Setup and Validation Checklist
Centralized Test Environment (Recommended for DSOs)
🟣 Decision Required: Centralized test environment is recommended—allows controlled testing without impacting any production location.
☐ 🔵 OraQ AI provisions test tenant with anonymized data ☐ Configure test tenant with representative PMS configurations (one per PMS type in portfolio) ☐ Connect to sandboxed imaging storage ☐ Create test users for each role (Admin, Regional, Office Manager, Provider) ☐ Document test scenarios (see below) ☐ Execute test scenarios and document results ☐ Sign off on test environment validation before production rollout
Test Scenarios
| Scenario | Expected Outcome | Pass/Fail |
|---|---|---|
| Patient data sync | New patient in PMS appears in OraQ AI within 15 min | ☐ |
| Treatment plan sync | Completed treatment appears with correct codes | ☐ |
| Image sync | New radiograph appears linked to correct patient | ☐ |
| Report generation | Production report matches PMS report within 1% | ☐ |
| User access control | Provider cannot access other location's data | ☐ |
| SSO login | User authenticates via corporate SSO | ☐ |
| Data export | Aggregate report exports correctly to CSV/PDF | ☐ |
Data Migration / Historical Data Ingestion
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | 🟣 Determine historical data scope (1 year, 3 years, all-time) | VP Operations | Decision |
| 2 | 🔵 Review OraQ AI data ingestion capacity and pricing for historical data | Vendor + Finance | 1 hour |
| 3 | ⚠️ Export historical data from PMS (large exports may require after-hours scheduling) | IT | 2–8 hours per location |
| 4 | 🔵 Stage historical data for secure transfer | IT + Vendor | 1 hour |
| 5 | 🔵 Ingest historical data into OraQ AI | Vendor | 2–24 hours (volume dependent) |
| 6 | Validate historical data accuracy (spot-check 50 records per location) | IT + Clinical Lead | 2 hours |
Enterprise-Level Security and HIPAA Compliance
Enterprise HIPAA Checklist
| Requirement | Action | Owner | Status |
|---|---|---|---|
| BAA Execution | 🔵 Execute Business Associate Agreement with OraQ AI | Legal | ☐ |
| Data Encryption in Transit | Verify TLS 1.2+ for all data transmission | IT + Vendor | ☐ |
| Data Encryption at Rest | Confirm AES-256 encryption for stored data | IT + Vendor | ☐ |
| Access Controls | Implement RBAC per role definitions | IT | ☐ |
| Audit Logging | Verify all access is logged and retained per policy | IT + Vendor | ☐ |
| Breach Notification | Confirm vendor breach notification SLA (72 hours max) | Legal + Vendor | ☐ |
| Data Retention | Document data retention and deletion policies | Compliance | ☐ |
| Subprocessors | Review and approve any OraQ AI subprocessors | Legal | ☐ |
| Employee Training | Verify OraQ AI staff HIPAA training documentation | Compliance | ☐ |
| Penetration Testing | 🔵 Request most recent pen test results | IT + Vendor | ☐ |
Standardized vs. Location-Specific Configuration
Standardize Centrally
| Setting | Rationale |
|---|---|
| Data retention period | Compliance consistency |
| Report definitions and metrics | Cross-location comparability |
| Role-based access levels | Security consistency |
| Alert thresholds (e.g., claim denial rate >10%) | Benchmarking accuracy |
| Procedure code mappings | Apples-to-apples comparison |
| Integration sync frequency | Predictable data freshness |
Allow Local Variation
| Setting | Rationale |
|---|---|
| Dashboard layout preferences | User adoption—let people arrange their view |
| Notification preferences (email vs. in-app) | Workflow fit |
| Provider-specific goals | Individual performance context |
| Specialty-specific views (ortho, pedo, GP) | Clinical relevance |
| Local reporting cadence | Office manager workflow fit |
6. Team Training Plan
Train-the-Trainer Model
Champion Selection Criteria
| Criteria | Ideal Candidate |
|---|---|
| Role | Office Manager or Lead Dental Assistant preferred; motivated Provider acceptable |
| Tech Comfort | Has led or participated in previous tech rollout successfully |
| Influence | Respected by clinical and admin staff |
| Availability | Can dedicate 3–5 hours/week during rollout period |
| Communication | Clear communicator who can translate "tech speak" to practical workflow |
Champion Responsibilities
☐ Complete champion certification training (4 hours) ☐ Deliver role-specific training to location staff ☐ Serve as first-line support during go-live week ☐ Report daily to regional manager during go-live ☐ Collect and submit staff feedback ☐ Conduct monthly refresher training for new hires
Champion Certification Program
| Module | Duration | Format | Content |
|---|---|---|---|
| 1: Platform Overview | 60 min | 🔵 Live webinar | Navigation, core features, data flow |
| 2: Configuration Deep Dive | 60 min | 🔵 Live webinar | Location-specific settings, troubleshooting |
| 3: Role-Specific Workflows | 90 min | Self-paced video + quiz | Detailed workflows for each role |
| 4: Training Delivery Skills | 30 min | Self-paced video | How to train adults, handle resistance |
| 5: Certification Exam | 30 min | Online quiz | 80% pass required |
Role-Specific Training Outlines for Champion Delivery
Dentists/Providers
Training Time: 60–90 minutes Format: Live demo + hands-on practice during lunch or team meeting
| Topic | Duration | Key Points |
|---|---|---|
| Platform access and login | 10 min | SSO login, mobile access, password reset |
| Patient data view | 15 min | Finding patients, reviewing aggregated history |
| Clinical analytics | 20 min | Interpreting AI-generated insights, benchmarks vs. peers |
| Treatment planning data | 15 min | How treatment data flows, what's captured automatically |
| When to question AI outputs | 15 min | AI limitations, override scenarios, feedback submission |
| Q&A | 15 min | Open discussion |
Common Resistance Points and Responses:
- "This is just more data I don't have time to look at." → Response: "The platform surfaces what matters. Think of it as a pre-filtered dashboard, not more work. Show them the 3-minute morning snapshot."
- "I don't trust AI to interpret clinical data." → Response: "OraQ AI is data infrastructure—it organizes and presents data. It doesn't make clinical decisions. You remain the diagnostician."
- "What happens if it's wrong?" → Response: "Flag any data discrepancy to your champion. We have a feedback loop to correct issues."
Day 1 Cheat Sheet: Providers
📋 PROVIDER QUICK REFERENCE — OraQ AI
LOGIN:
→ Go to [URL] or open OraQ AI app
→ Click "SSO Login" and use your corporate credentials
DAILY SNAPSHOT (2 min):
→ Dashboard > My Performance > Today
→ Check: Patients seen vs. scheduled, Production vs. goal
PATIENT VIEW (during exam):
→ Search patient name in top bar
→ Review: Treatment history (all locations), Outstanding treatment, Insurance status
IF SOMETHING LOOKS WRONG:
→ Click ⚑ flag icon to report data issue
→ Tell your
AI-generated implementation guide based on public vendor information. Verify specifics directly with OraQ AI (Data Infrastructure).