Flex Dental Solutions
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
Flex Dental Solutions — Implementation Playbook (DSO)
Flex Dental Solutions Implementation Playbook
Patient Communication AI for Dental Service Organizations
1. Executive Summary
What Flex Dental Solutions Does
Flex Dental Solutions is an AI-powered patient communication platform that automates appointment reminders, recall campaigns, two-way texting, online scheduling, and patient engagement workflows. The system leverages natural language processing to understand patient responses, route inquiries intelligently, and reduce the manual communication burden on front desk staff while increasing patient response rates and schedule utilization.
Why DSOs Specifically Benefit from AI-Powered Patient Communication
Patient communication represents one of the highest-leverage opportunities for operational standardization at scale. DSOs managing 15–50 locations face a compounding problem: inconsistent communication practices across sites create unpredictable no-show rates, recall leakage, and front desk inefficiencies that multiply across the portfolio. AI-powered communication tools deliver three distinct scale advantages:
Standardization Without Micromanagement: Deploy consistent messaging protocols, response timing, and escalation logic across all locations without requiring regional managers to police individual front desk behavior.
Data Aggregation for Pattern Recognition: Centralized analytics reveal which locations, providers, or patient segments have communication breakdowns—enabling targeted interventions rather than blanket policy changes.
Marginal Cost Economics: The cost-per-message of AI communication drops as volume increases. A 40-location DSO with 200,000 active patients achieves communication unit economics impossible for independent practices.
Expected Timeline: Decision to Full Deployment
| Phase | Duration | Milestone |
|---|---|---|
| Pre-Implementation | Weeks 1–2 | Technical readiness confirmed, stakeholders aligned |
| Pilot Wave (3 locations) | Weeks 3–6 | Proof of concept validated, playbook refined |
| Wave 2 (8–10 locations) | Weeks 7–12 | Scaled deployment model proven |
| Wave 3 (Remaining locations) | Weeks 13–20 | Full portfolio deployment |
| Optimization | Weeks 21–26 | ROI validation, workflow refinement |
Total Timeline: 5–6 months from contract signature to full deployment with optimized workflows.
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware Requirements
☐ Workstations: Windows 10+ or macOS 11+, minimum 8GB RAM, modern browser (Chrome, Edge, Firefox) ☐ Network: Minimum 25 Mbps upload/download per location for real-time messaging ☐ Mobile devices: iOS 14+ or Android 10+ for staff mobile app access (optional but recommended) ☐ Headsets with noise-canceling microphones for any voice-enabled features
Software Requirements
☐ Practice Management System (PMS): Current supported version of Dentrix, Eaglesoft, or Open Dental ☐ Web browser: Chrome (recommended), Edge, or Firefox—latest version ☐ Email client access for administrative notifications
Network Requirements ⚠️
☐ Firewall configuration to whitelist Flex Dental Solutions IP ranges and domains ☐ SSL/TLS 1.2+ for all data transmission ☐ Outbound ports 443 (HTTPS) and 587 (SMTP) open ☐ Verify SMS/MMS can be sent and received at all locations (carrier restrictions)
Integration Requirements
☐ PMS API access credentials or database connection method ☐ Current PMS version documented (some integrations require specific versions) ☐ Existing patient communication tool inventory (what's being replaced/retired)
Vendor Onboarding Steps 🔵
| Step | Owner | Timeline | Deliverable |
|---|---|---|---|
| ☐ Execute BAA and service agreement | Legal + Vendor | Day 1–3 | Signed agreements |
| ☐ Receive technical onboarding packet | Vendor | Day 3–5 | Integration documentation |
| ☐ Schedule kickoff call with implementation team | VP Ops + Vendor | Day 5 | Kickoff meeting scheduled |
| ☐ Assign dedicated Flex account manager | Vendor | Day 5 | Named contact + escalation path |
| ☐ Establish support channel access | IT + Vendor | Day 7 | Support portal logins, SLA documentation |
| ☐ Schedule technical integration workshop | IT + Vendor | Day 7–10 | 2-hour workshop completed |
Key Vendor Contacts to Establish
- Implementation Manager: Primary point of contact during deployment
- Technical Integration Specialist: For API/database connection issues
- Customer Success Manager: For post-deployment optimization
- Support Escalation Contact: Named individual for Severity 1 issues
Data/Access Prerequisites ⚠️
Practice Management System Access
☐ API keys or database credentials for each PMS instance ☐ Read access to: patient demographics, appointment schedules, treatment history, recall data ☐ Write access to: appointment notes, communication logs (if bi-directional sync required) ☐ Test patient records created in sandbox environment
Phone/SMS Infrastructure
☐ Inventory of current phone numbers per location (main line, texting lines) ☐ Decision: Port existing numbers to Flex or use new Flex-provisioned numbers 🟣 ☐ Carrier documentation for number porting (if applicable) ☐ Current texting platform contract terms and cancellation timelines
Historical Data
☐ Patient communication history export (last 12 months) ☐ No-show/cancellation data by location ☐ Recall campaign performance history ☐ Current template library for SMS, email, and phone scripts
Internal Stakeholder Alignment Map 🟣
| Stakeholder Level | Role | Involvement Type | Key Concerns to Address |
|---|---|---|---|
| Board/Investors | Oversight | Inform | ROI timeline, HIPAA compliance, competitive positioning |
| C-Suite (CEO, CFO, CDO) | Decision | Approve | Total cost of ownership, strategic fit, risk profile |
| VP of Operations | Owner | Lead | Implementation complexity, staff adoption, operational impact |
| Chief Dental Officer | Clinical Sponsor | Advise | Patient experience, clinical workflow impact, provider adoption |
| IT Director/Manager | Technical Lead | Execute | Integration complexity, security, ongoing maintenance |
| Regional Managers | Cascade | Manage | Location-level readiness, staff resistance, timeline pressure |
| Office Managers | Location Champion | Execute | Daily workflow changes, training burden, patient response |
| Providers | End Users | Adopt | Time investment, patient relationship impact |
| Front Desk Staff | End Users | Adopt | Workflow changes, job security concerns, learning curve |
Approval Requirements by Decision Type
| Decision | Approver | Timeline |
|---|---|---|
| Contract signature | CFO + CEO | Pre-implementation |
| Data sharing agreement (BAA) | Legal + HIPAA Officer | Pre-implementation |
| Network configuration changes | IT Director | Week 1 |
| Phone number porting | VP Ops | Week 1 |
| Pilot location selection | VP Ops + Regional Managers | Week 1 |
| Go-live authorization per wave | VP Ops | Per wave |
| Full rollout continuation | C-Suite | After Wave 1 |
Enterprise-Level Requirements
Network Standards Across Locations
☐ Document minimum bandwidth requirements and verify each location meets standard ☐ Standardize firewall rules across all locations (provide IT with configuration template) ☐ Ensure consistent DNS configuration for Flex domain access ☐ Verify VPN access for central IT to troubleshoot location-specific issues
Hosting Architecture Decision 🟣
| Option | Pros | Cons | Recommendation |
|---|---|---|---|
| Centralized Cloud (Flex-hosted) | Single point of management, automatic updates, reduced IT burden | Dependency on vendor uptime, less customization | ✅ Recommended for most DSOs |
| Hybrid (Flex cloud + local caching) | Faster response times, some offline capability | More complex architecture, higher maintenance | Consider for locations with unreliable internet |
Single Sign-On (SSO) Requirements
☐ Confirm Flex supports SAML 2.0 or OAuth 2.0 ☐ Provide Identity Provider (IdP) metadata to Flex ☐ Define role-based access control (RBAC) groups:
- Central Admin (full access, all locations)
- Regional Manager (read/write, assigned region)
- Office Manager (read/write, single location)
- Front Desk (limited access, single location)
- Provider (read-only dashboards, single location)
Centralized Credentialing
☐ Define user provisioning workflow (who creates accounts, who approves) ☐ Establish account deactivation process for terminated employees ☐ Document password policy alignment with organizational standards ☐ Configure automatic session timeout (recommended: 30 minutes)
Baseline Metrics Capture ⚠️
Critical: These metrics MUST be captured before go-live to enable ROI measurement.
Metrics to Standardize Across All Locations
| Metric Category | Specific Metrics | Data Source | Measurement Period |
|---|---|---|---|
| Schedule Utilization | Chair utilization rate, no-show rate, same-day cancellation rate, open appointment slots | PMS reports | Trailing 90 days |
| Patient Communication | Outbound message volume, response rate, average response time, staff time on communication tasks | Current system + time studies | Trailing 30 days |
| Recall Performance | Recall campaign response rate, reactivation rate, recall leakage (patients overdue for hygiene) | PMS + current comm system | Trailing 12 months |
| Front Desk Efficiency | Inbound call volume, calls per FTE, average call duration, calls abandoned | Phone system reports | Trailing 30 days |
| Revenue Indicators | Production per chair hour, collections rate, new patient acquisition cost | PMS + financial systems | Trailing 90 days |
Standardization Protocol for Cross-Location Comparison
☐ Define consistent calculation methodology for each metric (document formulas) ☐ Identify and exclude anomalous data (locations under renovation, recent acquisitions) ☐ Normalize for patient volume differences (metrics should be per-patient or percentage-based) ☐ Create baseline data collection template for regional managers to complete ☐ Set deadline for baseline data submission: End of Week 1 ☐ Central team validates data consistency before proceeding to implementation
Baseline Data Collection Template
Location: _________________ | Reporting Period: _________________
| Metric | Current Value | Data Source | Notes |
|---|---|---|---|
| No-show rate | ___% | ||
| Same-day cancellation rate | ___% | ||
| Recall response rate | ___% | ||
| Average patient response time | ___ hours | ||
| Front desk FTEs dedicated to communication | ___ | ||
| Outbound messages per day | ___ | ||
| Inbound calls per day | ___ | ||
| Recall patients overdue >6 months | ___ |
3. Location Readiness Assessment
Readiness Scoring Framework
Score each factor 1–5 for every location using the criteria below. Produce a composite readiness score to determine rollout sequence.
Factor 1: IT Infrastructure Maturity
| Score | Criteria |
|---|---|
| 5 | Fiber internet (100+ Mbps), hardware <2 years old, current PMS version, no known IT issues |
| 4 | Broadband (50+ Mbps), hardware <3 years old, PMS within one version of current |
| 3 | Broadband (25+ Mbps), hardware <4 years old, PMS supported but not current |
| 2 | DSL or unreliable connection, hardware >4 years old, PMS version requires upgrade |
| 1 | Known connectivity issues, outdated hardware, unsupported PMS version |
Factor 2: Staff Tenure and Adaptability
| Score | Criteria |
|---|---|
| 5 | Staff turnover <15%, previous successful tech implementations, documented training history |
| 4 | Staff turnover 15–25%, neutral tech adoption history, stable office manager |
| 3 | Staff turnover 25–35%, mixed tech adoption history, office manager tenure >1 year |
| 2 | Staff turnover 35–50%, previous tech implementation challenges, recent OM turnover |
| 1 | Staff turnover >50%, documented resistance to change, no stable leadership |
Factor 3: Patient Volume
| Score | Criteria | Strategic Consideration |
|---|---|---|
| 5 | High volume (>3,000 active patients) | Highest ROI potential, but higher risk if issues occur |
| 4 | Above average (2,000–3,000 active patients) | Good balance of impact and risk |
| 3 | Average (1,000–2,000 active patients) | Ideal for pilot—representative but manageable |
| 2 | Below average (500–1,000 active patients) | Lower impact but also lower risk |
| 1 | Low volume (<500 active patients) | Limited ROI, consider for late waves |
Factor 4: Existing Tech Stack Compatibility
| Score | Criteria |
|---|---|
| 5 | PMS and imaging fully compatible, existing integrations with similar tools, clean data |
| 4 | PMS compatible, minor integration work required, data quality acceptable |
| 3 | PMS compatible with workarounds, moderate data cleanup needed |
| 2 | PMS compatibility requires upgrade, significant data cleanup, multiple conflicting systems |
| 1 | Incompatible PMS, requires replacement before Flex implementation |
Factor 5: Local Champion Availability
| Score | Criteria |
|---|---|
| 5 | Tech-forward provider AND office manager, both committed to championing rollout |
| 4 | Strong office manager champion, providers neutral but cooperative |
| 3 | Office manager willing but not enthusiastic, no provider champion identified |
| 2 | No clear champion, but no active resistance |
| 1 | Potential resistance from leadership, no champion, competing priorities |
Composite Score Calculation
Weighted Scoring Formula:
| Factor | Weight | Rationale |
|---|---|---|
| IT Infrastructure | 25% | Technical failure stops deployment |
| Staff Tenure/Adaptability | 25% | Staff resistance is #1 failure mode |
| Patient Volume | 15% | Impacts ROI but not success probability |
| Tech Stack Compatibility | 20% | Integration issues delay timeline |
| Local Champion | 15% | Critical for adoption but can be developed |
Composite Score = (IT × 0.25) + (Staff × 0.25) + (Volume × 0.15) + (Tech × 0.20) + (Champion × 0.15)
Readiness Tiers and Rollout Assignment
| Composite Score | Tier | Rollout Assignment |
|---|---|---|
| 4.0–5.0 | Tier 1 – High Readiness | Wave 1 Pilot Candidates |
| 3.0–3.9 | Tier 2 – Moderate Readiness | Wave 2 |
| 2.0–2.9 | Tier 3 – Needs Preparation | Wave 3 (with remediation) |
| <2.0 | Tier 4 – Not Ready | Defer until readiness improves |
Location Assessment Template
| Location | IT (1-5) | Staff (1-5) | Volume (1-5) | Tech (1-5) | Champion (1-5) | Composite | Tier |
|---|---|---|---|---|---|---|---|
| Location A | |||||||
| Location B | |||||||
| Location C | |||||||
| ... |
Rollout Sequence Recommendations
Wave 1 Pilot Selection Criteria
Select 2–3 locations that meet ALL of the following:
- ☐ Composite score ≥4.0 (high readiness)
- ☐ Geographic diversity (different regions if applicable)
- ☐ PMS diversity (at least 2 different PMS platforms if used across portfolio)
- ☐ Committed local champion identified by name
- ☐ Regional manager engagement confirmed
- ☐ Not facing competing major initiatives (renovation, merger, leadership change)
Pilot Location Selection Matrix
| Candidate | Composite Score | Geography | PMS | Champion Name | RM Support | Other Initiatives | Select? |
|---|---|---|---|---|---|---|---|
4. Rollout Strategy
Wave Structure for DSO Deployment
Recommended Wave Architecture
| Wave | Locations | Duration | Purpose |
|---|---|---|---|
| Wave 1: Pilot | 2–3 locations | 4 weeks | Validate integration, refine training, identify failure modes |
| Wave 2: Controlled Expansion | 8–10 locations | 6 weeks | Test scalability, refine champion model, stress-test support |
| Wave 3: Full Deployment | Remaining locations | 8–10 weeks | Execute proven playbook at scale |
Wave 1: Pilot Locations (Weeks 3–6)
Selection Criteria:
- Highest readiness scores (Tier 1)
- Geographic and PMS diversity
- Regional manager with bandwidth to provide close support
- Locations that represent portfolio (not outliers)
Pilot Objectives:
- Validate technical integration with each PMS variant
- Refine training materials based on real staff feedback
- Identify common configuration adjustments needed
- Measure early impact on key metrics
- Document troubleshooting playbook for common issues
- Test escalation paths and vendor support responsiveness
Timeline:
| Week | Activities |
|---|---|
| Week 3 | Complete integration and configuration, train champions |
| Week 4 | Champion-led staff training, soft launch (parallel run) |
| Week 5 | Go-live, daily check-ins, real-time issue resolution |
| Week 6 | Stabilization, lessons learned documentation, go/no-go for Wave 2 |
Wave 2: Controlled Expansion (Weeks 7–12)
Selection Criteria:
- Tier 1 and strong Tier 2 locations
- Priority to locations with common PMS (leverage Wave 1 learnings)
- Batch locations within same region for efficient champion support
Expansion Objectives:
- Test champion-led training at scale
- Validate central support can handle concurrent issues
- Refine standardized configuration template
- Build internal case studies for remaining locations
Timeline:
| Week | Activities |
|---|---|
| Week 7 | Integration and configuration for Wave 2 locations |
| Week 8 | Champion certification, training material distribution |
| Week 9 | Staff training (champions deliver) |
| Week 10 | Soft launch, parallel run |
| Week 11 | Go-live, daily check-ins |
| Week 12 | Stabilization, Wave 2 retrospective, go/no-go for Wave 3 |
Wave 3: Full Deployment (Weeks 13–20)
Approach:
- Deploy in 2–3 sub-waves if remaining locations exceed 15
- Address Tier 3 locations that required remediation
- Leverage experienced champions to support neighboring locations
Timeline:
| Week | Activities |
|---|---|
| Weeks 13–14 | Integration and configuration for Wave 3 locations |
| Weeks 15–16 | Champion certification and training delivery |
| Weeks 17–18 | Go-live (staggered across sub-waves) |
| Weeks 19–20 | Stabilization, full portfolio operational |
Go/No-Go Criteria Between Waves 🟣
Criteria for Advancing from Pilot to Wave 2
| Category | Go Criteria | No-Go Triggers |
|---|---|---|
| Technical | Integration stable for 7+ consecutive days, <5 Severity 2+ incidents per location | Unresolved integration failures, data sync issues >24 hours |
| Adoption | >80% of staff completed training, daily active usage by front desk | <70% training completion, active staff resistance |
| Metrics | Measurable improvement OR no degradation in key metrics | Significant increase in no-show rate, patient complaints about communication |
| Support | Vendor response time within SLA, internal escalation path functional | Vendor unresponsive, issues taking >48 hours to resolve |
| Champion | Champions confident to train others, documented learnings | Champions requesting delay, unresolved workflow questions |
Decision Process:
- Regional managers provide location-level recommendation
- VP Ops synthesizes and presents recommendation to C-suite
- 🟣 Final go/no-go decision by VP Ops with CDO concurrence
Rollback Plan ⚠️
Rollback Triggers
- Critical integration failure affecting patient care or safety
- Data sync failure causing appointment errors
- Widespread staff inability to perform core functions
- Patient complaints exceeding defined threshold
- Vendor support failure (no response to Severity 1 within SLA)
Rollback Procedure
| Step | Action | Owner | Timeline |
|---|---|---|---|
| 1 | Document trigger event and decision rationale | Location Champion | Immediate |
| 2 | Notify central IT and vendor support | Location Champion | Within 1 hour |
| 3 | Disable Flex patient-facing communications | Central IT | Within 2 hours |
| 4 | Activate backup communication workflow | Office Manager | Within 2 hours |
| 5 | Notify regional manager and VP Ops | Location Champion | Within 4 hours |
| 6 | Communicate to staff: return to previous workflow | Office Manager | Same day |
| 7 | Root cause analysis with vendor | Central IT + Vendor | Within 48 hours |
| 8 | Remediation plan before re-launch | VP Ops approval | Before retry |
Backup Communication Workflow
☐ Document current (pre-Flex) communication workflow before pilot launch ☐ Maintain access to previous communication platform during pilot period ☐ Train staff on "emergency revert" procedure ☐ Test rollback procedure in one pilot location before go-live
Isolation Protocol
- Rollback decision at one location does NOT trigger automatic rollback at others
- Central team assesses whether root cause is location-specific or systemic
- 🟣 Portfolio-wide pause requires VP Ops + CDO decision
5. Configuration & Integration (Weeks 2–3)
Practice Management System Integration
Dentrix Integration 🔵
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | ☐ Verify Dentrix version compatibility (G7.3+ recommended) | IT | 15 min |
| 2 | ☐ Request Dentrix API credentials from Henry Schein | IT | 2–5 days |
| 3 | ☐ Install Flex Dentrix Connector service on server | IT + Vendor | 1 hour |
| 4 | ☐ Configure database connection string | IT + Vendor | 30 min |
| 5 | ☐ Map Dentrix fields to Flex patient record fields | IT + Vendor | 1 hour |
| 6 | ☐ Configure appointment type mappings | Office Manager + Vendor | 1 hour |
| 7 | ☐ Enable real-time sync for appointments, patient updates | IT + Vendor | 30 min |
| 8 | ☐ Test sync with 10 test patient records | IT | 30 min |
| 9 | ☐ Validate appointment changes sync within 2 minutes | IT | 30 min |
| 10 | ☐ Run full patient data sync (initial load) | IT + Vendor | 2–4 hours |
⚠️ Common Dentrix Failure Points:
- Outdated Dentrix version requiring upgrade before integration
- Database permissions not correctly configured
- Firewall blocking connector service communication
- Multi-location Dentrix Enterprise requiring different configuration
Eaglesoft Integration 🔵
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | ☐ Verify Eaglesoft version (21.0+ recommended) | IT | 15 min |
| 2 | ☐ Enable Eaglesoft API access in system settings | IT | 15 min |
| 3 | ☐ Generate API key within Eaglesoft | IT | 15 min |
| 4 | ☐ Provide API key to Flex implementation team | IT | 10 min |
| 5 | ☐ Configure Flex Eaglesoft integration settings | Vendor | 30 min |
| 6 | ☐ Map provider codes and appointment types | Office Manager + Vendor | 1 hour |
| 7 | ☐ Test bidirectional sync with test records | IT | 30 min |
| 8 | ☐ Run initial patient data sync | IT + Vendor | 2–4 hours |
⚠️ Common Eaglesoft Failure Points:
- API rate limits causing sync delays at high-volume practices
- Special characters in patient names causing parsing errors
- Appointment status codes not mapping correctly
Open Dental Integration 🔵
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | ☐ Verify Open Dental version (22.1+ recommended) | IT | 15 min |
| 2 | ☐ Enable API in Open Dental (Setup → Misc Setup) | IT | 15 min |
| 3 | ☐ Create API user with appropriate permissions | IT | 15 min |
| 4 | ☐ Generate API keys (customer key + developer key from Flex) | IT + Vendor | 30 min |
| 5 | ☐ Configure Flex with Open Dental API endpoint | Vendor | 15 min |
| 6 | ☐ Map operatories, providers, and appointment types | Office Manager + Vendor | 1 hour |
| 7 | ☐ Test patient sync with sample records | IT | 30 min |
| 8 | ☐ Verify real-time appointment updates | IT | 30 min |
| 9 | ☐ Run full patient database sync | IT + Vendor | 2–4 hours |
⚠️ Common Open Dental Failure Points:
- Self-hosted databases behind firewalls requiring tunnel configuration
- Customer key generation requires Open Dental support involvement
- Webhook configuration for real-time updates often misconfigured
Test Environment Setup and Validation
Test Environment Checklist
☐ Create isolated test environment (or use vendor-provided sandbox) ☐ Load representative sample of patient data (de-identified if possible) ☐ Configure test phone numbers that do NOT reach real patients ☐ Create test user accounts for each role type ☐ Document test scenarios covering critical workflows
Validation Test Suite
| Test Case | Expected Outcome | Pass/Fail |
|---|---|---|
| Patient record syncs from PMS to Flex | Patient appears in Flex within 2 minutes | ☐ |
| Appointment created in PMS syncs to Flex | Appointment appears with correct date, provider, type | ☐ |
| Appointment rescheduled in PMS updates Flex | Updated time reflected within 2 minutes | ☐ |
| Appointment reminder sent from Flex | SMS delivered to test phone | ☐ |
| Patient confirms via SMS | Confirmation logged in Flex and synced to PMS | ☐ |
| Patient requests reschedule via SMS | Request routed to front desk queue | ☐ |
| Recall campaign triggered | Eligible patients receive recall message | ☐ |
| Patient responds with "STOP" | Opt-out logged, no further messages sent | ☐ |
| Front desk user logs in via SSO | Correct role and location access | ☐ |
| Communication log viewable in Flex | Full message history for patient accessible | ☐ |
Data Migration and Historical Data Ingestion
Data Migration Scope Decision 🟣
| Data Type | Migrate? | Rationale |
|---|---|---|
| Patient demographics | Yes (automatic via integration) | Required for messaging |
| Appointment history (future) | Yes (automatic via integration) | Required for reminders |
| Appointment history (past) | Optional | Useful for analytics, not required |
| Previous communication history | Recommended | Provides context for patient interactions |
| Patient communication preferences | Required | Respects prior opt-outs |
| Prior opt-outs (STOP requests) | Critical | Legal requirement—do not message opted-out patients |
Historical Communication Data Ingestion 🔵
| Step | Action | Owner | Est. Time |
|---|---|---|---|
| 1 | ☐ Export communication history from previous system | IT | 2–4 hours |
| 2 | ☐ Export opt-out list from previous system | IT | 1 hour |
| 3 | ☐ Provide export files to Flex in required format | IT | 30 min |
| 4 | ☐ Flex imports historical data and opt-outs | Vendor | 1–2 days |
| 5 | ☐ Validate opt-out list imported correctly | IT + Compliance | 2 hours |
| 6 | ☐ Spot-check 10 patient records for historical accuracy | IT | 1 hour |
⚠️ Critical: Verify ALL opt-outs are imported before sending any messages. Sending to opted-out patients violates TCPA and creates legal liability.
Security and HIPAA Compliance Verification
Enterprise-Level HIPAA Checklist
| Requirement | Verification Method | Status |
|---|---|---|
| ☐ BAA executed with Flex Dental Solutions | Legal review + signature | |
| ☐ Flex SOC 2 Type II report reviewed | Vendor provides report | |
| ☐ Data encryption at rest (AES-256 or equivalent) | Vendor documentation | |
| ☐ Data encryption in transit (TLS 1.2+) | Vendor documentation | |
| ☐ Access controls configured (RBAC) | IT validation | |
| ☐ Audit logging enabled | Vendor confirmation | |
| ☐ Audit log retention meets requirements (6 years) | Vendor documentation | |
| ☐ Data backup and disaster recovery plan documented | Vendor documentation | |
| ☐ Breach notification procedures documented | Vendor + Legal | |
| ☐ Minimum necessary PHI principle applied | Configuration review | |
| ☐ Patient authorization for electronic communication | Practice workflow review | |
| ☐ Employee HIPAA training updated for new system | HR/Compliance |
Data Governance Requirements
☐ Define data retention policy for communication records ☐ Document who can access patient communication history (role-based) ☐ Establish process for patient data deletion requests ☐ Configure automatic data purge (if required by policy) ☐ Document data flow: PMS → Flex → Patient device
DSO-Specific Configuration
Standardized Configuration Template
The following settings should be identical across all locations to ensure consistent patient experience and enable meaningful cross-location analytics:
| Configuration Element | Standard Setting | Rationale |
|---|---|---|
| Appointment reminder timing | 72 hours, 24 hours, 2 hours before | Patient expectations consistent |
| Recall campaign timing | 2 weeks before due, 1 week after due, 1 month after due | Standardized recall workflow |
| Message templates (wording) | Centrally approved templates only | Brand consistency, compliance |
| Response routing logic | Reschedule requests → queue, emergencies → escalate | Predictable patient experience |
| Opt-out handling | Immediate removal, confirmation message | Legal |
AI-generated implementation guide based on public vendor information. Verify specifics directly with Flex Dental Solutions.