Smilepass
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
Smilepass — Implementation Playbook (DSO)
Smilepass Implementation Playbook for DSOs
Data & Infrastructure | AI-Powered Patient Identification and Data Management
1. Executive Summary
What Smilepass Does
Smilepass is an AI-powered facial recognition and biometric patient identification platform that eliminates manual check-in processes, reduces identity errors, and creates a seamless patient intake experience. The system captures and verifies patient identity through facial biometrics, integrating directly with practice management systems to auto-populate patient records, streamline form completion, and enhance data integrity across your organization.
Why DSOs Specifically Benefit from This Category of AI
Scale Advantages:
- Standardized patient identification eliminates the variability of manual check-in processes across 15–50+ locations, reducing identity mismatches that compound at scale
- Centralized biometric database enables patients to check in seamlessly at any location in your network—a significant competitive advantage for multi-location DSOs
- Aggregate data quality improvements compound: cleaner patient records mean better analytics, more accurate reporting, and stronger payer relationships
Operational Standardization:
- Uniform intake experience across all locations strengthens brand consistency
- Eliminates location-specific workarounds that create compliance gaps
- Standardized identity verification reduces fraud risk and duplicate record creation
Data Aggregation Benefits:
- Cross-location patient tracking becomes automatic, enabling true network-wide patient journey analytics
- Centralized identity management reduces IT overhead versus managing disparate systems
- Clean, verified patient data improves downstream AI applications (treatment planning, revenue cycle, recalls)
Expected Timeline: Decision to Full Deployment
| Phase | Timeline | Milestone |
|---|---|---|
| Pre-Implementation | Weeks 1–2 | Infrastructure assessment, contracts, baseline metrics |
| Pilot Wave (3–5 locations) | Weeks 3–6 | First locations live, initial learning capture |
| Wave 2 Expansion (8–12 locations) | Weeks 7–12 | Refined playbook deployed |
| Wave 3+ Full Deployment | Weeks 13–20 | All remaining locations live |
| Optimization & Stabilization | Weeks 20–26 | Full ROI measurement, process refinement |
Total Timeline: 5–6 months for a 30-location DSO, with faster deployment possible for organizations with mature IT infrastructure and strong change management capabilities.
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware Requirements
☐ Front desk workstation specifications: Minimum Intel i5 (or equivalent), 8GB RAM, Windows 10/11 or macOS 11+ ☐ Camera hardware: USB 3.0 webcam with minimum 1080p resolution and IR capability for low-light environments (vendor will specify approved models) ☐ Tablet option: If using patient-facing tablets, iPad (6th gen+) or approved Android devices ☐ Network connectivity: Minimum 25 Mbps download/10 Mbps upload per location; latency <100ms to cloud services
Software Requirements
☐ Practice management system version compatibility: Verify current PMS versions across all locations against Smilepass compatibility matrix ☐ Browser requirements: Chrome 90+, Edge 90+, Safari 14+ (for web-based dashboard access) ☐ Operating system patches: All workstations current on security updates
Network Requirements
☐ Firewall configuration: Whitelist Smilepass cloud endpoints (specific IPs/domains provided during onboarding) ☐ SSL/TLS: Ensure TLS 1.2+ is enabled on all network traffic ☐ VPN considerations: If locations use VPN to central systems, verify bandwidth capacity for biometric data transmission
🔵 Vendor Onboarding Steps
| Step | Action | Owner | Timeline |
|---|---|---|---|
| 1 | Execute Master Services Agreement and BAA | Legal/Vendor | Day 1–3 |
| 2 | Complete enterprise onboarding questionnaire | IT Lead/Vendor | Day 2–4 |
| 3 | Establish vendor key contacts (implementation lead, technical support, account executive) | Operations | Day 3 |
| 4 | Schedule kickoff call with full implementation team | Project Manager | Day 4–5 |
| 5 | Receive and distribute technical documentation package | IT Lead | Day 5–7 |
| 6 | Establish support ticketing access for IT team | IT Lead/Vendor | Day 7 |
Key Vendor Contacts to Establish
- Implementation Manager: Primary contact for rollout coordination
- Technical Integration Specialist: API configuration and PMS integration support
- Customer Success Manager: Post-launch optimization and escalation
- 24/7 Support Line: For go-live and critical issues
Data/Access Prerequisites
☐ PMS API credentials: Obtain API keys or integration credentials for each PMS instance ☐ Admin access to PMS: Ensure IT or designated staff have admin-level access for configuration ☐ Patient data export capabilities: Verify ability to export patient demographic data for initial seeding (if required) ☐ SSO integration prerequisites: If using enterprise SSO, gather IdP metadata and configuration requirements ☐ User provisioning list: Compile list of all users who will need Smilepass access, by role and location
🟣 Internal Stakeholder Alignment
Approval Required From:
| Stakeholder | Approval Needed For | Timeline |
|---|---|---|
| CEO/Board | Capital expenditure, strategic initiative approval | Week 1 |
| Chief Dental Officer | Clinical workflow changes, provider communication | Week 1 |
| VP of Operations | Implementation timeline, resource allocation | Week 1 |
| CFO | Budget approval, ROI framework | Week 1 |
| Compliance/Legal | BAA review, privacy policy updates | Week 1 |
| IT Director | Technical architecture approval, security review | Week 1–2 |
Informed (Not Approving):
| Stakeholder | Information Needed | When |
|---|---|---|
| Regional Managers | Rollout schedule, location selection rationale | Week 2 |
| Office Managers | Timeline for their location, resource requirements | Week 2 |
| Providers | High-level benefits, what to expect | Week 2 |
| HR | Training requirements, potential job description updates | Week 2 |
Stakeholder Alignment Map
┌─────────────────────────────┐
│ BOARD / INVESTORS │
│ Strategic approval, ROI │
└─────────────┬───────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ CEO │ │ CFO │ │ CDO │
│ Executive │ │ Budget │ │ Clinical │
│ Sponsor │ │ Owner │ │ Approval │
└─────┬─────┘ └───────────┘ └─────┬─────┘
│ │
└───────────────────┬───────────────────────────┘
│
┌─────────┴─────────┐
│ VP OPERATIONS │
│ Project Sponsor │
└─────────┬─────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ Regional │ │ IT │ │ Training │
│ Managers │ │ Director │ │ Lead │
│ (Cascade) │ │ (Tech) │ │ (Rollout) │
└─────┬─────┘ └───────────┘ └───────────┘
│
┌─────┴─────────────────────────────────────┐
│ │
┌──┴───┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│Office│ │Providers│ │ Front │ │Clinical │
│Mgrs │ │ │ │ Desk │ │ Staff │
└──────┘ └─────────┘ └─────────┘ └─────────┘
⚠️ Baseline Metrics to Capture BEFORE Go-Live
Critical: Standardize measurement methodology across ALL locations before collecting baselines. Inconsistent measurement makes cross-location comparison impossible.
Patient Experience Metrics
| Metric | How to Measure | Standardization Note |
|---|---|---|
| Average check-in time | Time from patient arrival to seated in operatory | Use PMS timestamps; define "arrival" consistently (door entry vs. front desk acknowledgment) |
| Patient wait time complaints | Count of documented complaints per 100 patients | Create standard complaint logging protocol |
| Patient satisfaction (check-in) | NPS or survey score specific to check-in | Deploy identical 2-question survey across all locations |
Operational Metrics
| Metric | How to Measure | Standardization Note |
|---|---|---|
| Identity verification errors | Count of chart pulls for wrong patient, misfiled documents | Audit 1 week of charts at each location using same criteria |
| Duplicate patient records created (monthly) | PMS duplicate detection report | Run same duplicate-finding algorithm at each location |
| Front desk labor hours on check-in | Time study or estimation by office manager | Use standardized time-motion study protocol |
| Forms completion rate at arrival | % of patients with all required forms complete before appointment | Define required forms list consistently |
Data Integrity Metrics
| Metric | How to Measure | Standardization Note |
|---|---|---|
| Patient demographic accuracy | Audit sample for errors (wrong DOB, address, insurance) | Sample 50 records per location, same audit checklist |
| Insurance verification accuracy | % of claims rejected for patient info errors | Pull from clearinghouse or PMS rejection reports |
Financial Metrics
| Metric | How to Measure | Standardization Note |
|---|---|---|
| Claims rejected for patient ID issues | Filter rejection codes related to patient identification | Standardize rejection code categorization |
| No-show rate | PMS no-show report | Ensure consistent definition of "no-show" vs. "late cancel" |
Enterprise-Level Requirements
Network Standards Across Locations
☐ Minimum bandwidth: Document current bandwidth at each location; flag any below 25/10 Mbps ☐ Network segmentation: Determine if biometric data should travel on dedicated VLAN ☐ Firewall rule standardization: Create master firewall rule template for all locations
Centralized vs. Location-Level Hosting Decision
🟣 Executive Decision Required:
| Option | Pros | Cons | Recommendation |
|---|---|---|---|
| Centralized (Cloud) | Single data repository, easier patient cross-location lookup, simplified compliance | Requires reliable internet at all locations, latency concerns | Recommended for most DSOs |
| Hybrid | Local processing with cloud sync, works offline | More complex architecture, higher IT burden | Consider only if locations have unreliable connectivity |
SSO Integration
☐ Identity provider: Confirm IdP (Okta, Azure AD, Google Workspace, etc.) ☐ SAML/OIDC configuration: Gather technical requirements from IT ☐ Role mapping: Define how PMS roles map to Smilepass permission levels ☐ Provisioning/deprovisioning: Establish automated user management workflow
Centralized Credentialing
☐ Provider credentialing data: Determine if provider profiles in Smilepass need credentialing verification ☐ Access control matrix: Define who can access what data across the enterprise ☐ Audit logging requirements: Confirm audit trail meets compliance requirements
3. Location Readiness Assessment
Scoring Framework
Score each location on the following factors (1–5 scale), then calculate a composite readiness score.
Factor 1: IT Infrastructure Maturity (Weight: 25%)
| Score | Criteria |
|---|---|
| 5 | Network >100 Mbps, all workstations <2 years old, latest PMS version, previous successful tech rollouts |
| 4 | Network 50–100 Mbps, workstations 2–3 years old, PMS within one version of current, one successful rollout |
| 3 | Network 25–50 Mbps, workstations 3–4 years old, PMS within two versions, mixed rollout history |
| 2 | Network 10–25 Mbps, workstations 4–5 years old, outdated PMS, prior rollout struggles |
| 1 | Network <10 Mbps, workstations >5 years old, significantly outdated PMS, no tech rollout experience |
Factor 2: Staff Tenure and Adaptability (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | <10% annual turnover, documented tech comfort, recent training completion >90%, positive attitude toward change |
| 4 | 10–15% turnover, moderate tech comfort, training completion 80–90%, generally receptive to change |
| 3 | 15–25% turnover, mixed tech comfort, training completion 70–80%, neutral toward change |
| 2 | 25–35% turnover, low tech comfort, training completion 50–70%, some resistance to change |
| 1 | >35% turnover, tech-averse culture, training completion <50%, active resistance to change |
Factor 3: Patient Volume (Weight: 20%)
| Score | Criteria | Note |
|---|---|---|
| 5 | 80–120 patients/day | High impact, high visibility, but not overwhelming |
| 4 | 60–80 patients/day | Strong impact with manageable volume |
| 3 | 40–60 patients/day | Moderate volume, good for learning |
| 2 | 120–150 patients/day | Very high volume increases risk |
| 1 | <40 OR >150 patients/day | Too low for meaningful data OR too high risk for pilot |
Factor 4: Existing Tech Stack Compatibility (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | PMS with native Smilepass integration, digital imaging already deployed, existing API integrations successful |
| 4 | PMS with documented Smilepass compatibility, modern imaging, some API experience |
| 3 | PMS on compatibility list but not native, standard imaging, limited integration experience |
| 2 | PMS requires custom integration work, older imaging system, no API experience |
| 1 | PMS not on compatibility list OR requires significant infrastructure upgrades |
Factor 5: Local Champion Availability (Weight: 15%)
| Score | Criteria |
|---|---|
| 5 | Identified tech-forward provider AND office manager, both enthusiastic, prior champion experience |
| 4 | Strong office manager champion with provider support OR tech-forward provider with competent OM |
| 3 | Willing office manager, neutral provider, no prior champion experience |
| 2 | No clear champion, but no active resistance |
| 1 | No champion available OR key staff actively resistant |
Composite Score Calculation
Formula:
Composite Score = (IT × 0.25) + (Staff × 0.20) + (Volume × 0.20) + (Tech Stack × 0.20) + (Champion × 0.15)
Score Interpretation
| Composite Score | Readiness Tier | Rollout Recommendation |
|---|---|---|
| 4.0–5.0 | Tier 1 (High Readiness) | Wave 1 pilot candidate |
| 3.0–3.9 | Tier 2 (Moderate Readiness) | Wave 2 candidate |
| 2.0–2.9 | Tier 3 (Low Readiness) | Wave 3 candidate, requires remediation |
| <2.0 | Tier 4 (Not Ready) | Defer until specific issues resolved |
Sample Location Readiness Scorecard
| Location | IT (25%) | Staff (20%) | Volume (20%) | Tech (20%) | Champion (15%) | Composite | Tier |
|---|---|---|---|---|---|---|---|
| Downtown Main | 5 | 4 | 4 | 5 | 5 | 4.55 | 1 |
| Suburban North | 4 | 4 | 5 | 4 | 4 | 4.20 | 1 |
| Eastside Family | 4 | 3 | 3 | 4 | 5 | 3.75 | 2 |
| Westside Ortho | 3 | 4 | 3 | 3 | 3 | 3.20 | 2 |
| Rural Clinic A | 2 | 3 | 2 | 2 | 2 | 2.25 | 3 |
Rollout Sequence Recommendation
Based on readiness scores, we recommend the following wave structure:
Wave 1 (Pilot): 3–5 Highest-Scoring Locations
Selection Criteria:
- Composite score ≥4.0
- Geographic diversity (don't cluster all pilots in one region)
- Include at least one high-volume and one moderate-volume location
- Strong champion presence
- Representative of your portfolio (if you have specialty practices, include at least one)
Wave 2 (Early Expansion): Next 5–8 Locations
- Composite score 3.5–4.0
- Locations that can benefit from Wave 1 learnings
- Include locations in same region as Wave 1 successes (peer influence)
Wave 3+ (Broad Deployment): Remaining Locations
- Deploy in regional clusters to maximize training efficiency
- Address remediation items for Tier 3 locations before deployment
- Consider deferring Tier 4 locations until fundamental issues resolved
4. Rollout Strategy
Recommended Wave Structure
Wave 1: Pilot (3–5 Locations)
Duration: 4 weeks Purpose: Validate integration, refine training, capture learnings, prove ROI
Wave 2: Early Expansion (8–12 Locations)
Duration: 4–5 weeks Purpose: Scale with refined playbook, stress-test support model
Wave 3+: Broad Deployment (Remaining Locations)
Duration: 4–6 weeks per wave of 10–15 locations Purpose: Efficient rollout using proven processes
Wave 1 Pilot Location Selection
Required Criteria
☐ Composite readiness score ≥4.0 ☐ Identified and confirmed local champion (office manager + provider buy-in) ☐ No major planned disruptions (renovations, key staff departures, PMS migration) ☐ Stable patient volume (avoid seasonal lows)
Preferred Criteria
☐ Geographic proximity to headquarters or regional support hub (enables faster on-site support) ☐ History of successful technology adoption ☐ Office manager with bandwidth to participate in feedback loops ☐ Mix of patient demographics representative of overall portfolio
Risk Factors to Avoid in Wave 1
⚠️ Brand-new locations (<6 months operating) ⚠️ Locations undergoing leadership transition ⚠️ Highest-volume flagship locations (too much risk if issues arise) ⚠️ Locations with known staff morale issues
🟣 Recommended Wave 1 Selection Process
- Generate readiness scores for all locations
- Filter to Tier 1 locations (score ≥4.0)
- Apply required and preferred criteria
- Regional managers validate selections with local context
- Executive sponsor approves final pilot location list
Timeline Per Wave
Wave 1 Detailed Timeline
| Week | Activities |
|---|---|
| Week 1 | Champion training, hardware deployment, test environment setup |
| Week 2 | Integration testing, staff training, parallel workflow planning |
| Week 3 | Go-live, intensive support, daily check-ins |
| Week 4 | Stabilization, initial metrics capture, learning documentation |
Wave 2+ Timeline (Per Wave)
| Week | Activities |
|---|---|
| Week 1 | Champion certification, hardware/configuration deployment |
| Week 2 | Staff training (delivered by local champions), final testing |
| Week 3 | Staggered go-live (3–4 locations Mon, 3–4 Wed, remaining Fri) |
| Week 4–5 | Stabilization, metrics review, refinement |
Buffer Between Waves
Minimum 1-week buffer between waves to:
- Complete learning documentation from prior wave
- Update training materials based on feedback
- Address any systemic issues before scaling
- Allow central team recovery time
Go/No-Go Criteria for Wave Advancement
Criteria to Advance from Wave 1 to Wave 2
| Category | Go Criteria | No-Go Triggers |
|---|---|---|
| Technical | Integration stable for 5+ consecutive days, <2 hours cumulative downtime | >8 hours downtime, data integrity issues, security concerns |
| Adoption | >80% of check-ins using Smilepass, <10% staff bypass rate | <50% adoption, widespread staff resistance |
| Patient Experience | No patient complaints requiring escalation, wait times stable or improved | Multiple patient complaints, increased wait times |
| Operational | Check-in time reduced or stable, no increase in identity errors | Significant increase in errors, workflow disruption |
| Support Load | Issues resolving within expected timeframes, no critical open tickets | Backlog of unresolved issues, vendor support overwhelmed |
🟣 Go/No-Go Decision Process
- Local champions complete Wave assessment checklist (Day 21)
- Central project team reviews metrics and feedback (Day 22–23)
- Project team recommendation submitted to VP of Operations (Day 24)
- VP of Operations makes Go/No-Go decision (Day 25)
- Decision communicated to all stakeholders (Day 26)
⚠️ Rollback Plan
If a wave fails to meet Go criteria, execute the following rollback protocol:
Immediate Actions (Within 24 Hours)
☐ Pause all planned go-lives for subsequent locations in current wave ☐ Document specific failure points with as much detail as possible ☐ Notify vendor of issues and engage escalated support ☐ Communication cascade: VP Ops → Regional Managers → Affected Office Managers ☐ Revert to previous workflow at affected locations if patient experience is degraded
Assessment Period (48–72 Hours)
☐ Root cause analysis with vendor technical team ☐ Determine if issue is:
- Location-specific (proceed with other locations, remediate affected location)
- Systemic (full pause until resolved)
- Training-related (enhanced training, then retry)
- Integration-related (technical fix required)
Recovery Path
☐ Vendor provides remediation plan with timeline ☐ Test fix in controlled environment ☐ Pilot remediation at single affected location ☐ Resume wave if successful, with extended monitoring
Protecting Other Locations
- Locations already live in prior waves continue operating normally
- Do not deploy to new locations until root cause resolved
- Increased monitoring at all live locations during investigation
5. Configuration & Integration (Weeks 2–3)
Step-by-Step PMS Integration
🔵 Dentrix Integration
| Step | Action | Owner | ⚠️ Notes |
|---|---|---|---|
| 1 | Verify Dentrix version compatibility (G7.3+ recommended) | IT | Older versions may require upgrade |
| 2 | Install Dentrix API connector module | Vendor/IT | Requires after-hours install; plan for 30-min downtime |
| 3 | Configure API credentials in Smilepass admin portal | IT/Vendor | Use service account, not individual user credentials |
| 4 | Map Dentrix patient fields to Smilepass fields | IT/Vendor | Standard mapping provided; custom fields require config |
| 5 | Configure bi-directional sync settings | IT/Vendor | Determine real-time vs. batch sync |
| 6 | Test patient lookup from Smilepass | IT | Use test patients first |
| 7 | Test demographic write-back to Dentrix | IT | ⚠️ Critical: Verify no data overwrites |
| 8 | Validate insurance verification integration | IT/Vendor | If using integrated eligibility |
| 9 | Production go-live configuration | IT/Vendor | Switch from test to production mode |
🔵 Eaglesoft Integration
| Step | Action | Owner | ⚠️ Notes |
|---|---|---|---|
| 1 | Verify Eaglesoft version (21.00+ recommended) | IT | Contact Patterson support if unsure |
| 2 | Enable Eaglesoft API access in system settings | IT | Requires admin credentials |
| 3 | Install Smilepass integration agent on Eaglesoft server | IT/Vendor | Server reboot may be required |
| 4 | Configure API endpoint in Smilepass portal | IT/Vendor | Requires server IP/port information |
| 5 | Test connectivity and authentication | IT | Use vendor diagnostic tool |
| 6 | Configure patient data field mapping | IT/Vendor | Document any custom mappings |
| 7 | Test patient search and retrieval | IT | Verify photo attachment capabilities |
| 8 | Configure appointment status updates | IT/Vendor | Sync check-in status to Eaglesoft |
| 9 | Production deployment | IT/Vendor | Test during low-volume period first |
🔵 Open Dental Integration
| Step | Action | Owner | ⚠️ Notes |
|---|---|---|---|
| 1 | Verify Open Dental version (22.1+ recommended for full API) | IT | Open Dental updates frequently |
| 2 | Generate API key in Open Dental (Setup → API) | IT | Use dedicated API user account |
| 3 | Configure API endpoint in Smilepass | IT/Vendor | Enter API key and server URL |
| 4 | Enable required API permissions | IT | Patient read/write, appointment access |
| 5 | Test patient lookup and creation | IT | Open Dental has native duplicate detection |
| 6 | Configure patient photo storage location | IT/Vendor | Verify photo path accessibility |
| 7 | Test full workflow: lookup → check-in → appointment update | IT | Document any errors |
| 8 | Production go-live | IT/Vendor | Monitor API logs first 48 hours |
Imaging System Integration (If Applicable)
If Smilepass connects to imaging systems for photo management:
☐ Verify imaging system compatibility (Dexis, Carestream, Schick, etc.) ☐ Configure image import path or API connection ☐ Map patient identifiers between systems ☐ Test image capture and storage ☐ Verify DICOM compliance if applicable ☐ Test retrieval of patient photos for verification
Test Environment Setup
Centralized Test Environment (Recommended)
🔵 Request test environment from Smilepass that mirrors production configuration
| Component | Configuration |
|---|---|
| Test tenant | Separate from production, vendor-provisioned |
| Test patient data | Synthetic data only—no real PHI |
| Test PMS instance | Sandbox or copy of production (with PHI scrubbed) |
| Test hardware | At least 1 camera + workstation at central location |
Test Validation Checklist
☐ User authentication (SSO and direct login) ☐ Patient search functionality ☐ New patient enrollment workflow ☐ Returning patient identification ☐ Check-in process completion ☐ Data sync to PMS (bi-directional) ☐ Photo capture and storage ☐ Report generation ☐ Offline mode (if applicable) ☐ Performance under simulated load
Data Migration / Historical Data Ingestion
Patient Photo Migration (If Applicable)
☐ Inventory existing patient photos in PMS or imaging system ☐ 🔵 Determine if historical photo import is supported/recommended ☐ Assess photo quality—low-quality images may not work for biometric matching ☐ Define inclusion criteria (active patients only? Seen in last 2 years?) ☐ ⚠️ Privacy review: Ensure consent covers biometric use (see compliance section) ☐ Execute batch import during off-hours ☐ Validate import completeness and accuracy
🟣 Historical Data Decision Point
Question: Should you pre-load existing patient photos, or start fresh with new biometric enrollments?
| Option | Pros | Cons | Recommendation |
|---|---|---|---|
| Pre-load existing photos | Immediate recognition for returning patients | Photo quality may vary, consent may need updating, longer setup | Only if photos are recent and high-quality |
| Fresh enrollment | Clean data, explicit consent, better photo quality | Returning patients must re-enroll initially | Recommended for most DSOs |
Security and HIPAA Compliance Verification
Enterprise-Level HIPAA Checklist
☐ Business Associate Agreement (BAA) executed and filed ☐ Data encryption: Verify encryption at rest (AES-256) and in transit (TLS 1.2+) ☐ Access controls: Role-based access implemented, least-privilege principle applied ☐ Audit logging: All access to PHI logged with user, timestamp, action ☐ Data retention policy: Align Smilepass retention with organizational policy ☐ Data deletion procedures: Verify ability to delete patient data upon request ☐ Breach notification: Confirm vendor's breach notification procedures and timelines ☐ Biometric data handling: Verify compliance with state biometric privacy laws (BIPA in Illinois, CCPA in California, etc.) ☐ Subprocessor list: Review Smilepass subprocessors and ensure BAA coverage
⚠️ State-Specific Biometric Privacy Requirements
Several states have specific requirements for biometric data:
| State | Law | Key Requirements |
|---|---|---|
| Illinois | BIPA | Written consent, retention/destruction policy, no sale of data |
| Texas | CUBI | No sale, informed consent, reasonable security |
| Washington | HB 1493 | Notice required, no commercial purposes without consent |
| California | CCPA/CPRA | Biometrics as sensitive personal information, enhanced rights |
☐ Legal review of consent forms for all locations in applicable states ☐ Update patient intake forms with biometric consent language ☐ Document retention and destruction policy for biometric data
Enterprise Configuration Framework
Standardized Configuration Template
Apply identically across ALL locations:
| Setting | Standard Value | Rationale |
|---|---|---|
| Session timeout | 15 minutes | Security compliance |
| Photo quality threshold | 85% confidence minimum | Accuracy vs. convenience balance |
| Failed match threshold | 3 attempts before manual override | Security vs. workflow |
| Data retention period | 7 years or per legal requirement | Regulatory compliance |
| Audit log retention | 7 years | HIPAA requirement |
| Default language | English (with Spanish available) | Adjust based on patient demographics |
| Offline mode | Enabled with 4-hour cache | Business continuity |
| Escalation alerts | Email to Office Manager + Regional Manager | Timely issue awareness |
Location-Specific Configuration
Can vary by location:
| Setting | Variation Allowed | Examples |
|---|---|---|
| Operating hours | Per location schedule | Different weekend hours |
| Provider list | Per location roster |
AI-generated implementation guide based on public vendor information. Verify specifics directly with Smilepass.