OraQ AI
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
OraQ AI — Implementation Playbook (DSO)
OraQ AI Implementation Playbook
Diagnostic Imaging AI for Dental Support Organizations
1. Executive Summary
What OraQ AI Does
OraQ AI is a diagnostic imaging analysis platform that uses artificial intelligence to detect pathologies, anatomical structures, and clinical findings in dental radiographs (panoramic, periapical, bitewing, and CBCT images). The system provides real-time second-read analysis, highlighting potential caries, periapical lesions, bone loss, and other findings that clinicians can accept, modify, or dismiss within their existing imaging workflow.
Why DSOs Specifically Benefit from Diagnostic Imaging AI
Scale Advantages: Across 15–50 locations, a single diagnostic AI deployment multiplies clinical consistency exponentially. Where a solo practice gains one AI second-read per patient, a 30-location DSO gains diagnostic standardization across potentially 50,000+ patient encounters annually—transforming individual clinical variation into enterprise-level diagnostic reliability.
Standardization Value: Diagnostic imaging AI eliminates the variability inherent in human radiograph interpretation. Studies show inter-examiner reliability in caries detection ranges from 0.45–0.85 kappa; AI provides a consistent baseline across all providers, regardless of experience level, fatigue, or time pressure.
Data Aggregation Power: At scale, OraQ AI generates enterprise-wide diagnostic intelligence unavailable to single practices:
- Comparative detection rates across locations, providers, and patient populations
- Identification of systematic underdiagnosis patterns by region or provider
- Aggregate pathology prevalence data that informs clinical protocols and training investments
- Case acceptance correlation analysis across your entire patient base
Expected Timeline
| Phase | Duration | Milestone |
|---|---|---|
| Decision to Contract Signed | 2–3 weeks | Vendor selection, legal review, BAA execution |
| Pre-Implementation Setup | 2 weeks | Technical requirements, baseline metrics, stakeholder alignment |
| Pilot Wave (2–3 locations) | 4 weeks | Full deployment, optimization, success criteria validation |
| Wave 2 Expansion (5–8 locations) | 3–4 weeks | Refined playbook, scaled training |
| Wave 3+ Full Deployment | 4–6 weeks | Remaining locations, enterprise optimization |
| Total Decision to Full Deployment | 15–20 weeks | All locations live with optimization underway |
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware Requirements
☐ Verify workstation specifications at each location meet OraQ AI minimum requirements:
- Processor: Intel i5 (8th gen or newer) or AMD Ryzen 5 equivalent
- RAM: 8GB minimum, 16GB recommended
- Display: 1920x1080 resolution minimum; medical-grade monitors preferred for primary diagnostic stations
- GPU: Integrated graphics acceptable for cloud deployment; dedicated GPU required for local processing option
☐ Confirm imaging sensor compatibility:
- Supported digital sensor manufacturers (verify with OraQ AI for current compatibility list)
- Panoramic unit integration requirements
- CBCT compatibility (if applicable to your locations)
Software Requirements
☐ Operating systems: Windows 10/11 (64-bit) or macOS 12+ across clinical workstations ☐ Browser requirements: Chrome 90+, Edge 90+, Safari 15+ for cloud interface ☐ Current imaging software versions documented per location ☐ Practice management system versions documented per location
Network Requirements ⚠️
☐ Bandwidth assessment per location: Minimum 50 Mbps download/10 Mbps upload per location; 100/20+ recommended for high-volume practices ☐ Latency testing to OraQ AI servers: <100ms recommended for real-time analysis ☐ Firewall configuration requirements documented ☐ VPN implications if applicable (OraQ AI traffic must be allowed)
⚠️ Common Failure Point: Network issues cause 40% of implementation delays. Test during peak patient hours, not after-hours when bandwidth is artificially high.
Vendor Onboarding Steps 🔵
Key Contacts to Establish
| Role | Name | Contact | Purpose |
|---|---|---|---|
| OraQ AI Implementation Manager | 🔵 Assigned post-contract | Primary point of contact | |
| OraQ AI Technical Support Lead | 🔵 Assigned post-contract | Escalation for technical issues | |
| OraQ AI Customer Success Manager | 🔵 Assigned post-contract | Ongoing optimization, QBRs | |
| Your Internal Project Lead | _______________ | Single throat to choke | |
| Your IT Lead | _______________ | Technical coordination |
Vendor Onboarding Milestones 🔵
☐ Kickoff call scheduled (within 5 business days of contract execution) ☐ Technical requirements document received from OraQ AI ☐ Enterprise BAA fully executed ☐ Implementation timeline mutually agreed ☐ Test environment credentials received ☐ Training portal access provisioned ☐ Support ticket system access established Estimated time: 3–5 business days
Data/Access Prerequisites
Credentials and Access
☐ Create OraQ AI admin account credentials for central IT team ☐ Establish SSO integration timeline (if using enterprise SSO) ☐ API keys generated for PMS/imaging system integrations ☐ Imaging archive access for historical data analysis (if utilizing retroactive analysis feature) ☐ Test patient accounts created in sandbox environment
Imaging Archive Assessment
☐ Document imaging software vendor and version per location ☐ Identify DICOM vs. proprietary format usage across locations ☐ Assess cloud-stored vs. locally-stored image archives ☐ Determine historical image migration scope (how far back, how many images) ☐ Calculate storage implications of AI annotations and reports
Estimated time: 3–4 hours for documentation; API provisioning varies by PMS vendor
Internal Stakeholder Alignment 🟣
Who Needs to Be Informed
| Stakeholder | Information Needed | Timing |
|---|---|---|
| Board/Investors | AI investment rationale, expected ROI, competitive positioning | Pre-contract or immediately post |
| C-Suite (CEO, CFO, COO) | Budget impact, implementation timeline, resource requirements | Pre-contract |
| Chief Dental Officer | Clinical workflow impact, diagnostic protocols, liability considerations | Pre-contract |
| VP of Operations | Rollout plan, location selection, resource allocation | Week 1 |
| Regional Managers | Timeline for their regions, staff requirements, success metrics | Week 1–2 |
| Location Office Managers | High-level awareness, no action required yet | Week 2 |
| IT Leadership | Technical requirements, integration approach, security review | Week 1 |
Who Needs to Approve 🟣
☐ CFO/Finance: Budget allocation for software licensing, implementation costs, ongoing fees ☐ CDO/Clinical Leadership: Diagnostic protocol changes, clinical workflow approval ☐ Legal/Compliance: BAA execution, liability review, patient consent language ☐ IT Security: Security architecture review, data governance approval ☐ HR (if applicable): Training time allocation, potential workflow changes affecting staff
Estimated time: Stakeholder alignment meetings 4–6 hours; approval cycles 1–2 weeks depending on governance structure
Enterprise-Level Requirements
Network Standards Across Locations
☐ Document current network topology per location ☐ Identify locations requiring network upgrades before deployment ☐ Standardize firewall rules for OraQ AI access across all locations ☐ Establish network monitoring for OraQ AI traffic post-deployment
Hosting Architecture Decision 🟣
| Option | Pros | Cons | Recommendation |
|---|---|---|---|
| Centralized Cloud (OraQ AI hosted) | Fastest deployment, no local infrastructure, automatic updates | Dependent on internet connectivity, per-image processing fees may apply | Recommended for most DSOs |
| Hybrid (Cloud processing, local caching) | Faster local performance, some offline capability | More complex setup, local storage requirements | Consider for high-volume or rural locations |
| On-Premise | Maximum control, no ongoing cloud fees | Significant IT overhead, slower updates, higher upfront cost | Rarely recommended |
🟣 Executive Decision Required: Hosting architecture impacts both upfront costs and ongoing operational model
Identity and Access Management
☐ SSO integration requirements documented (SAML 2.0, OAuth 2.0 supported) ☐ User provisioning workflow defined (central IT vs. location-level creation) ☐ Role-based access control structure established:
- Enterprise Admin: Full system access, all locations, configuration control
- Regional Admin: Access to assigned region's locations, reporting
- Location Admin: Access to single location, user management
- Provider: Clinical access, diagnostic tools, limited reporting
- Staff: View-only or restricted access as defined
☐ Centralized credentialing: provider license verification workflow for AI diagnostic tool access
Baseline Metrics to Capture BEFORE Go-Live ⚠️
⚠️ Critical: Without baseline metrics, ROI measurement is impossible. Capture these metrics for 30–60 days before any location goes live.
Standardized Metrics Across All Locations
| Metric Category | Specific Metric | Collection Method | Target Baseline Period |
|---|---|---|---|
| Diagnostic Efficiency | Average time from image capture to diagnosis documentation | PMS timestamp analysis or time study | 30 days |
| Detection Rates | Pathologies detected per 100 radiographs (by type) | Chart audit sample | 60 days, minimum 200 images per location |
| Case Acceptance | Percentage of diagnosed treatment accepted by patients | PMS reports | 60 days |
| Treatment Value | Average treatment plan value following diagnostic imaging | PMS reports | 60 days |
| Claim Performance | Radiograph-related claim denial rate | Clearinghouse reports | 90 days |
| Provider Variation | Detection rate variance across providers within location | Chart audit | 60 days |
| Patient Throughput | Patients seen per day with radiographs | Scheduling reports | 30 days |
| Retake Rate | Percentage of images requiring retake | Imaging software logs | 30 days |
Baseline Data Collection Protocol
Step 1: Create standardized data collection template (spreadsheet or BI dashboard) Step 2: Assign data collection responsibility per location (office manager recommended) Step 3: Train collectors on consistent methodology Step 4: Conduct weekly validation of incoming data during baseline period Step 5: Calculate location-level and enterprise-level baseline averages
☐ Baseline collection template created ☐ Data collectors identified and trained per location ☐ Collection start date: _______________ ☐ Collection end date: _______________ ☐ Baseline report generated and validated
Estimated time: Template creation 2–3 hours; ongoing collection 30 minutes/week per location
3. Location Readiness Assessment
Scoring Framework
Score each location on the following factors using a 1–5 scale. Sum the scores for a composite readiness score (maximum 25 points).
Factor 1: IT Infrastructure Maturity
| Score | Criteria |
|---|---|
| 5 | Fiber internet (100+ Mbps), workstations <2 years old, current PMS/imaging versions, dedicated IT support |
| 4 | High-speed internet (50+ Mbps), workstations 2–3 years old, PMS/imaging within 1 version of current |
| 3 | Adequate internet (25–50 Mbps), workstations 3–4 years old, PMS/imaging within 2 versions of current |
| 2 | Inconsistent internet, workstations 4–5 years old, outdated PMS/imaging requiring upgrade |
| 1 | Unreliable internet, workstations 5+ years old, PMS/imaging incompatible with OraQ AI |
Factor 2: Staff Tenure and Adaptability
| Score | Criteria |
|---|---|
| 5 | <15% annual turnover, previous successful tech implementations, enthusiastic about new tools |
| 4 | 15–25% turnover, some tech implementation experience, generally receptive to change |
| 3 | 25–35% turnover, mixed tech adoption history, neutral toward change |
| 2 | 35–50% turnover, previous tech implementation struggles, some resistance to change |
| 1 | >50% turnover, failed tech implementations, active resistance to change |
Factor 3: Patient Volume
| Score | Criteria |
|---|---|
| 5 | 40+ patients/day, high radiograph volume—maximum AI impact potential |
| 4 | 30–40 patients/day, solid radiograph volume |
| 3 | 20–30 patients/day, moderate volume |
| 2 | 15–20 patients/day, lower volume (good for pilot due to lower risk) |
| 1 | <15 patients/day, minimal volume (consider delaying deployment) |
Note: For pilot location selection, scores of 2–3 in this category may be preferable to manage risk while validating workflows.
Factor 4: Existing Tech Stack Compatibility
| Score | Criteria |
|---|---|
| 5 | PMS on OraQ AI's certified integration list, imaging system fully compatible, existing cloud infrastructure |
| 4 | PMS integration available but not certified, imaging system compatible, some cloud adoption |
| 3 | PMS integration requires custom work, imaging system compatible with workaround |
| 2 | PMS integration complex, imaging system requires bridge software |
| 1 | PMS/imaging system not compatible, significant technical barriers |
Factor 5: Local Champion Availability
| Score | Criteria |
|---|---|
| 5 | Tech-forward provider AND office manager, both enthusiastic and influential |
| 4 | Tech-forward provider OR office manager committed to championing |
| 3 | Office manager supportive, providers neutral |
| 2 | No clear champion, but no active resistors |
| 1 | Influential resistors present, no champion candidates |
Location Assessment Template
| Location | IT Infrastructure (1-5) | Staff Adaptability (1-5) | Patient Volume (1-5) | Tech Compatibility (1-5) | Local Champion (1-5) | Total Score | Recommended Wave |
|---|---|---|---|---|---|---|---|
| Location A | |||||||
| Location B | |||||||
| Location C | |||||||
| (Continue for all locations) |
Rollout Sequence Recommendations
Wave Assignment by Score
| Composite Score | Recommended Wave | Rationale |
|---|---|---|
| 21–25 | Wave 1 (Pilot) | High readiness, can validate workflows and generate success stories |
| 16–20 | Wave 2 | Strong readiness, benefit from pilot learnings |
| 11–15 | Wave 3 | Moderate readiness, may require additional preparation |
| 6–10 | Wave 4 or Delayed | Significant barriers, address before deployment |
| 1–5 | Remediation Required | Not ready for deployment; create improvement plan |
Special Considerations for Pilot Selection
Beyond raw scores, Wave 1 pilot locations should also meet these criteria:
☐ Geographic accessibility: Can central team easily visit for hands-on support? ☐ Representative mix: Includes at least one location from each region (if applicable) ☐ Practice type diversity: If your DSO includes both GP and specialty locations, pilot should include representative examples ☐ Balanced volume: Not your highest-volume locations (too much risk) or lowest-volume (not representative) ☐ Champion quality: The local champion is not only willing but capable of documenting learnings and presenting to peers
4. Rollout Strategy
Wave Structure Recommendation
Recommended Wave Configuration for 15–50 Location DSO
| Wave | Locations | Duration | Primary Objective |
|---|---|---|---|
| Wave 1 (Pilot) | 2–3 locations | 4 weeks active + 2 weeks buffer | Validate workflows, identify issues, refine training |
| Wave 2 | 5–8 locations | 3–4 weeks active + 1 week buffer | Scale validation, train-the-trainer certification |
| Wave 3 | 8–15 locations | 3–4 weeks active + 1 week buffer | Volume scaling, process optimization |
| Wave 4+ | Remaining locations | 3–4 weeks per wave | Full deployment completion |
Wave 1 Pilot Location Selection Criteria
Required Criteria (must meet all): ☐ Composite readiness score ≥18 ☐ Local champion confirmed and available ☐ No major IT infrastructure concerns ☐ Stable staff (no anticipated turnover during pilot period) ☐ Management supportive and engaged
Preferred Criteria (meet at least 3 of 5): ☐ Geographic proximity to central support team ☐ Medium patient volume (manageable learning curve with meaningful data) ☐ Representative of broader DSO practice mix ☐ Previous successful technology adoption ☐ CDO or regional leader has direct relationship with location
Pilot Location Risk Factors to Avoid: ⚠️ Locations undergoing other major changes (EHR transition, expansion, leadership change) ⚠️ Locations with unresolved operational issues ⚠️ Your flagship or highest-revenue location (protect reputation during learning phase) ⚠️ Locations with known difficult provider dynamics
Wave Timeline Detail
Wave 1 Pilot Timeline (6 weeks total)
| Week | Activities |
|---|---|
| Week 1 | Champion training, system configuration, parallel testing |
| Week 2 | Soft launch with shadow mode (AI runs but doesn't change workflow), staff training |
| Week 3 | Full go-live, daily check-ins, intensive support |
| Week 4 | Stabilization, workflow refinement, metric collection |
| Week 5 (Buffer) | Issue remediation, documentation of learnings |
| Week 6 (Buffer) | Wave 2 preparation, pilot success presentation |
Wave 2+ Timeline (4–5 weeks per wave)
| Week | Activities |
|---|---|
| Week 1 | Champion training (leveraging Wave 1 champions as co-trainers), configuration |
| Week 2 | Staff training, soft launch in shadow mode |
| Week 3 | Full go-live, daily check-ins |
| Week 4 | Stabilization, metric collection, next wave prep |
| Week 5 (Buffer if needed) | Issue remediation before next wave |
Go/No-Go Criteria 🟣
Criteria to Advance from Wave 1 to Wave 2
| Category | Go Criteria | No-Go Triggers |
|---|---|---|
| Technical Stability | <5% system errors/crashes; integration functioning reliably | >10% error rate; integration failures requiring manual workarounds |
| User Adoption | >80% of providers using AI findings in diagnosis documentation | <50% of providers using system; active resistance |
| Workflow Impact | Neutral or positive impact on patient throughput | >15% decrease in patients seen; significant workflow disruption |
| Clinical Acceptance | CDO/clinical leadership approves diagnostic accuracy | Clinical leadership raises safety or accuracy concerns |
| Champion Capacity | Wave 1 champions able to support Wave 2 training | Champions overwhelmed or unavailable |
| Support Scalability | Vendor support responsive (<4hr for critical issues) | Vendor support backlogged; SLAs not met |
🟣 Executive Decision Required: If any No-Go trigger is hit, pause expansion for remediation. VP Operations and CDO must jointly approve resumption.
Conditional Go Scenarios
If Wave 1 succeeds but with identified issues:
- Document issues explicitly
- Create remediation plan with timeline
- Reduce Wave 2 scope (e.g., 3 locations instead of 5) to limit risk exposure
- Increase support intensity for Wave 2
Rollback Plan
Wave-Level Rollback Protocol
Trigger Conditions for Rollback:
- Critical patient safety concern identified
- System unavailability >4 hours during business hours
- Integration failure causing data loss or corruption
30% of providers refuse to continue using system
- CDO withdraws clinical endorsement
Rollback Execution Steps
☐ Immediate (Within 2 hours):
- Notify OraQ AI support of decision to roll back 🔵
- Instruct locations to revert to pre-OraQ workflows
- Disable OraQ AI integration with PMS/imaging system
- Communicate to affected staff via office managers
☐ Short-term (Within 24 hours):
- Document all issues triggering rollback
- Schedule post-mortem with vendor 🔵
- Communicate status to regional managers
- Prepare executive briefing 🟣
☐ Recovery Planning (Within 1 week):
- Root cause analysis complete
- Remediation plan agreed with vendor 🔵
- Go/no-go decision for retry with timeline 🟣
- Staff communication on path forward
Isolation Principle
Rollback at one location should NOT automatically trigger rollback at other locations. Each wave operates semi-independently:
- Wave 1 rollback: Pause all subsequent waves pending investigation
- Wave 2+ location rollback: Continue other locations in wave unless systemic issue identified
- Document whether issue is location-specific or systemic
5. Configuration & Integration (Weeks 2–3)
Practice Management System Integration
Dentrix Enterprise Integration 🔵
| Step | Action | Owner | Time Estimate |
|---|---|---|---|
| 1 | Verify Dentrix version compatibility with OraQ AI | Central IT | 15 min |
| 2 | Request API credentials from Henry Schein/Dentrix | Central IT | 2–5 business days |
| 3 | Provide API credentials to OraQ AI implementation team 🔵 | Central IT | 15 min |
| 4 | OraQ AI configures integration in test environment 🔵 | OraQ AI | 1–2 days |
| 5 | Test patient data synchronization (read-only first) | Central IT + OraQ AI | 2 hours |
| 6 | Test image association and retrieval | Central IT + OraQ AI | 2 hours |
| 7 | Test diagnostic finding write-back to chart | Central IT + Clinical | 2 hours |
| 8 | Validate billing code associations (if applicable) | Billing + OraQ AI | 1 hour |
| 9 | User acceptance testing with pilot location staff | Pilot Champion | 4 hours |
| 10 | Document any Dentrix-specific workflow adaptations | Project Lead | 2 hours |
⚠️ Common Dentrix Issues:
- Multi-location server architecture may require location-specific API configurations
- Some Dentrix add-ons may conflict; document existing integrations before setup
- Image bridging to third-party imaging software may introduce complexity
Eaglesoft Integration 🔵
| Step | Action | Owner | Time Estimate |
|---|---|---|---|
| 1 | Verify Eaglesoft version compatibility with OraQ AI | Central IT | 15 min |
| 2 | Request API access from Patterson Dental | Central IT | 3–7 business days |
| 3 | Document Eaglesoft server configuration per location | Central IT | 2 hours |
| 4 | Provide credentials and configuration to OraQ AI 🔵 | Central IT | 15 min |
| 5 | OraQ AI configures integration 🔵 | OraQ AI | 1–2 days |
| 6 | Test imaging module integration | Central IT + OraQ AI | 2 hours |
| 7 | Test clinical note integration | Central IT + Clinical | 2 hours |
| 8 | Validate across multiple locations in test environment | Central IT | 4 hours |
| 9 | User acceptance testing | Pilot Champion | 4 hours |
⚠️ Common Eaglesoft Issues:
- Patterson's API approval process can be lengthy; start early
- Server-based installations require VPN or direct connectivity considerations
Open Dental Integration 🔵
| Step | Action | Owner | Time Estimate |
|---|---|---|---|
| 1 | Verify Open Dental version (17.1+ typically required) | Central IT | 15 min |
| 2 | Enable API access in Open Dental (Program Links settings) | Central IT | 30 min |
| 3 | Generate API keys within Open Dental | Central IT | 15 min |
| 4 | Provide API keys and connection details to OraQ AI 🔵 | Central IT | 15 min |
| 5 | OraQ AI configures API integration 🔵 | OraQ AI | 1 day |
| 6 | Test data sync and image retrieval | Central IT + OraQ AI | 2 hours |
| 7 | Test finding write-back to treatment plan and chart notes | Central IT + Clinical | 2 hours |
| 8 | Configure user permissions within Open Dental | Central IT | 1 hour |
| 9 | User acceptance testing | Pilot Champion | 4 hours |
Open Dental Advantages: Generally faster integration due to open API architecture
Imaging System Integration 🔵
Integration by Imaging System Type
| Imaging System | Integration Method | Typical Timeline | Notes |
|---|---|---|---|
| Dexis | API integration via DEXIS Integrator | 2–3 days | Widely supported; verify version |
| Planmeca Romexis | DICOM export or API | 3–5 days | Excellent DICOM support |
| Carestream | DICOM or proprietary integration | 3–5 days | May require bridge software |
| Sirona SIDEXIS | DICOM or API | 3–5 days | Check version compatibility |
| XDR Radiology | API integration | 2–3 days | Cloud-native, straightforward |
| Apteryx/XrayVision | API integration | 2–4 days | Common in multi-location DSOs |
| Pearl (existing AI) | Not applicable | — | Discuss coexistence strategy with OraQ AI |
Integration Validation Checklist
☐ Images transfer to OraQ AI within acceptable latency (<10 seconds for intraoral, <30 seconds for panoramic/CBCT) ☐ Image quality preserved (no compression artifacts affecting diagnostic value) ☐ Patient demographics correctly associated ☐ Image type correctly identified (BW, PA, Pano, CBCT) ☐ AI findings can be returned to imaging software or PMS ☐ Historical images accessible (if retroactive analysis enabled) ☐ Multi-location images correctly segregated (no cross-contamination)
Test Environment Setup
Centralized Test Environment (Recommended) 🔵
☐ OraQ AI provisions enterprise sandbox environment 🔵 ☐ Sandbox connected to test instance of PMS (not production) ☐ Sample patient data created (minimum 50 synthetic patients) ☐ Sample images uploaded across all image types (BW, PA, Pano, FMX) ☐ All user roles provisioned in sandbox for testing ☐ Integration points validated in sandbox before production ☐ Central IT validates sandbox performance ☐ Champion users complete sandbox training exercises
Sandbox Test Scenarios:
- New patient image capture and immediate AI analysis
- Historical image batch analysis
- AI finding acceptance and chart documentation
- AI finding rejection and override documentation
- Report generation (patient-facing, clinical)
- Multi-provider workflow (hygienist captures, dentist reviews)
- Error handling (network interruption, server timeout)
Production Validation Per Location
☐ Parallel run: AI runs silently alongside existing workflow for 3–5 days ☐ Compare AI findings to provider diagnoses (blind comparison) ☐ Verify no impact on existing workflow speed ☐ Confirm patient data integrity ☐ Validate location-specific configurations
Data Migration/Historical Image Ingestion 🔵
Migration Scope Decision 🟣
| Option | Description | Effort | Value |
|---|---|---|---|
| Forward-only | AI analyzes only images captured post go-live | Lowest | Fastest time to value; miss historical insights |
| Recent historical (6–12 months) | Retroactively analyze images from past year | Medium | Balance of value and effort |
| Full historical | Analyze all accessible historical images | Highest | Maximum insight; highest storage/processing cost |
🟣 Executive Decision Required: Historical analysis scope impacts costs and timeline
Historical Ingestion Steps (If Applicable) 🔵
☐ Determine image volume per location (total images, images per timeframe) ☐ Estimate processing time and costs with OraQ AI 🔵 ☐ Prioritize locations for historical analysis (high-value patients, recent images first) ☐ Schedule off-hours batch processing to avoid bandwidth impact ☐ Validate historical analysis accuracy with clinical spot-checks ☐ Document any limitations (older image formats, corrupted files)
Estimated time: Planning 2–3 hours; processing varies by volume (typically 1–3 days per location for 12-month history)
Security and HIPAA Compliance Verification
Enterprise HIPAA Checklist 🟣
| Requirement | Verification Step | Owner | Status |
|---|---|---|---|
| Business Associate Agreement | BAA executed with OraQ AI covering all locations | Legal | ☐ |
| Data Encryption - Transit | Verify TLS 1.2+ encryption for all data transmission | IT Security | ☐ |
| Data Encryption - Rest | Verify AES-256 encryption for stored data | IT Security | ☐ |
| Access Controls | Role-based access implemented and tested | IT | ☐ |
| Audit Logging | Verify all PHI access is logged and accessible | IT Security | ☐ |
| Data Retention | Confirm retention policies align with state requirements | Compliance | ☐ |
| Breach Notification | Vendor breach notification process documented | Legal | ☐ |
| Subcontractor Vetting | OraQ AI subcontractors (hosting, etc.) covered under BAA | Legal | ☐ |
| Physical Security | Data center security certifications (SOC 2, etc.) verified | IT Security | ☐ |
| Employee Training | OraQ AI confirms employee HIPAA training | Compliance | ☐ |
Data Governance Requirements
☐ Define data ownership (patient data remains DSO property) ☐ Document data deletion process upon contract termination ☐ Establish de-identification requirements for aggregate analytics ☐ Confirm no data sharing with third parties without consent ☐ Document data residency requirements (US data centers confirmed)
Standardized vs. Location-Specific Configuration
Standardize Centrally (Enterprise Template)
| Configuration Setting | Standard Value | Rationale |
|---|---|---|
| AI sensitivity threshold | Default (recommended by OraQ AI) | Consistency across locations |
| Detection categories enabled | All applicable to practice type | Comprehensive screening |
| Report template | Enterprise-branded template | Brand consistency |
| Alert thresholds | Critical findings highlighted | Patient safety standardization |
| Audit log retention | 7 years | Compliance consistency |
| User role definitions | Standardized role templates | Simplified administration |
| Training completion requirements | Mandatory completion before access | Quality control |
Allow Location-Specific Variation
| Configuration Setting | Variable Options | When to Customize |
|---|---|---|
| Provider display preferences | Layout, color scheme, font size | Individual provider usability needs |
| Specialty-specific modules | Endo, ortho, perio emphasis | Specialty practices |
| Alert notification preferences | On-screen, SMS, email | Provider preference |
| Secondary reviewer workflow | Required vs. optional | Based on location protocols |
AI-generated implementation guide based on public vendor information. Verify specifics directly with OraQ AI.