Kleer
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
Kleer — Implementation Playbook (DSO)
Kleer Implementation Playbook for DSOs
Membership & Patient Financing Platform
Prepared for: VPs of Operations, Chief Dental Officers, and Regional Managers
Organization Size: 15–50 Locations
Version: 2024.1
1. Executive Summary
What Kleer Does
Kleer is a cloud-based membership plan platform that enables dental organizations to create, manage, and scale in-house subscription plans for uninsured and underinsured patients. The platform automates member enrollment, recurring payment processing, plan administration, and enterprise-wide analytics—eliminating the administrative burden of managing disparate spreadsheet-based membership programs across locations.
Why DSOs Benefit from Membership Plan Technology at Scale
Network Effects & Standardization: DSOs operating 15–50 locations face a fragmented reality—each practice may have developed its own informal "discount plan" with inconsistent pricing, varying terms, and manual tracking. Kleer enables enterprise-wide standardization while allowing market-appropriate customization, creating a unified patient financing strategy that scales.
Data Aggregation & Portfolio Intelligence: Centralized membership data across all locations provides unprecedented visibility into patient conversion patterns, plan utilization rates, revenue predictability, and regional market dynamics. This aggregated intelligence supports strategic decisions about pricing, plan design, and market positioning that individual practices cannot access independently.
Revenue Predictability & Valuation Impact: Membership revenue represents recurring, predictable cash flow—a metric that directly impacts DSO valuation multiples. A well-implemented membership program can shift a meaningful percentage of revenue from episodic fee-for-service to subscription-based, improving financial forecasting and enterprise value.
Operational Leverage: Automating membership administration at scale eliminates redundant processes across locations, reduces billing staff workload, and creates a consistent patient experience that strengthens brand cohesion across your portfolio.
Expected Timeline: Decision to Full Deployment
| Phase | Duration | Cumulative |
|---|---|---|
| Pre-Implementation & Planning | 2 weeks | Week 2 |
| Wave 1 Pilot (2–3 locations) | 4 weeks | Week 6 |
| Wave 1 Assessment & Optimization | 2 weeks | Week 8 |
| Wave 2 Expansion (5–8 locations) | 4 weeks | Week 12 |
| Wave 2 Assessment | 2 weeks | Week 14 |
| Wave 3 Full Deployment (remaining) | 4–6 weeks | Week 18–20 |
| Stabilization & Optimization | 4 weeks | Week 22–24 |
Total Timeline: 5–6 months from contract signature to full deployment across all locations, with measurable ROI data available by Week 12.
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware
☐ Verify front desk workstations meet minimum specifications: Windows 10+ or macOS 10.14+, 8GB RAM, modern browser (Chrome 90+, Edge 90+, Safari 14+)
☐ Confirm patient-facing areas have tablets or kiosks for self-enrollment (optional but recommended)
☐ Ensure card readers are EMV-compliant for in-office payment collection (if not using Kleer's integrated payment processing)
Software
☐ Document current PMS version at each location (Dentrix, Eaglesoft, Open Dental, or other)
☐ ⚠️ Verify PMS versions are within Kleer's supported range—outdated versions are the #1 integration failure point
☐ Confirm browser versions across all workstations meet requirements
☐ Identify any existing membership tracking software or spreadsheets that will be deprecated
Network
☐ Verify minimum internet speeds: 25 Mbps download / 10 Mbps upload per location
☐ Confirm firewall rules allow outbound HTTPS traffic to Kleer's cloud services (*.kleer.com)
☐ Test network stability during peak patient hours at each location
Integrations
☐ 🔵 Request integration documentation from Kleer for your specific PMS platforms
☐ Identify any custom PMS configurations that may affect integration
☐ Document current payment processing providers at each location
Vendor Onboarding Steps
| Step | Owner | Timeline | Kleer Contact |
|---|---|---|---|
| 🔵 Execute enterprise agreement and BAA | Legal/Compliance | Day 1–3 | Account Executive |
| 🔵 Complete enterprise onboarding questionnaire | VP Operations | Day 2–4 | Implementation Manager |
| 🔵 Schedule kickoff call with implementation team | VP Operations | Day 3–5 | Implementation Manager |
| 🔵 Establish dedicated Slack/Teams channel with Kleer support | IT Lead | Day 5 | Customer Success Manager |
| 🔵 Confirm enterprise support tier and SLA terms | IT Lead | Day 5–7 | Customer Success Manager |
| 🔵 Receive API credentials and sandbox access | IT Lead | Day 7–10 | Technical Support |
Key Contacts to Establish
- Implementation Manager: Primary point of contact during deployment
- Customer Success Manager: Ongoing relationship owner post-deployment
- Technical Support Lead: Escalation path for integration issues
- Enterprise Account Executive: Strategic relationship and contract matters
Data/Access Prerequisites
☐ Compile list of all locations with addresses, NPI numbers, and tax IDs
☐ 🔵 Provide Kleer with PMS admin credentials or create dedicated integration user accounts
☐ Generate API keys from PMS systems (if applicable for your PMS version)
☐ Export current membership patient lists from existing tracking systems (spreadsheets, legacy software)
☐ 🔵 Provide Kleer with access to patient demographic data for migration (format: CSV with specified fields)
☐ Document current fee schedules at each location
☐ Compile provider NPIs and license numbers for all participating dentists
Enterprise-Level Requirements
Network Standards Across Locations
☐ 🟣 Decide: Centralized IT management or location-level IT autonomy
☐ Document network configuration standards that must apply to all locations
☐ Create network requirements checklist for locations not yet compliant
Hosting Architecture
☐ Kleer is cloud-hosted (SaaS)—no on-premise hosting required
☐ 🟣 Confirm data residency requirements are met (Kleer uses US-based AWS infrastructure)
Single Sign-On (SSO)
☐ 🟣 Decide: Implement SSO integration or use Kleer's native authentication
☐ If SSO: Confirm identity provider (Okta, Azure AD, Google Workspace)
☐ 🔵 If SSO: Request SSO configuration guide from Kleer and estimate 1–2 week setup
Centralized Credentialing
☐ Create master user role matrix (Enterprise Admin, Regional Manager, Location Admin, Provider, Front Desk)
☐ Define permission levels for each role
☐ Establish user provisioning/deprovisioning workflow aligned with HR onboarding
Internal Stakeholder Alignment
Stakeholder Alignment Map
| Stakeholder Level | Who | Role in Implementation | Communication Needs | Approval Required |
|---|---|---|---|---|
| Board/Investors | Board members, PE partners | Strategic oversight | Quarterly updates, ROI projections | 🟣 Budget approval, strategic alignment |
| C-Suite | CEO, CFO, CDO, VP Ops | Executive sponsorship, resource allocation | Weekly status during rollout | 🟣 Go/no-go decisions, policy changes |
| Regional Managers | Regional Directors | Cascade communication, local accountability | Bi-weekly briefings | Wave sequencing input |
| Location Office Managers | Practice Managers | Day-to-day implementation leads | Training, daily check-ins during go-live | Scheduling, staff coordination |
| Providers | Dentists, Hygienists | Clinical adoption, patient conversations | Training, clinical workflow impact | Treatment plan integration approach |
| Front Desk Staff | Patient coordinators, billing | Primary system users | Hands-on training, cheat sheets | None (inform only) |
Required Approvals Before Proceeding
☐ 🟣 Budget approval for Kleer enterprise subscription and implementation costs
☐ 🟣 Executive sponsor designated (recommend VP Operations or CDO)
☐ 🟣 Approval of membership plan pricing strategy (standardized vs. market-adjusted)
☐ 🟣 Approval of patient communication approach and marketing materials
☐ 🟣 Sign-off on data migration scope and timeline
Baseline Metrics to Capture Before Go-Live
⚠️ Critical: Standardize measurement methodology across all locations BEFORE deployment to enable valid cross-location comparison
Revenue & Financial Metrics
| Metric | Definition | Collection Method | Target Baseline Period |
|---|---|---|---|
| Uninsured patient percentage | % of active patients with no dental insurance | PMS report | Trailing 12 months |
| Uninsured patient revenue | Total revenue from uninsured patients | PMS financial report | Trailing 12 months |
| Average revenue per uninsured patient | Total uninsured revenue / # uninsured patients | Calculated | Trailing 12 months |
| Existing membership revenue | Revenue from any current discount/membership plans | Manual or legacy system | Trailing 12 months |
| Revenue predictability score | % of monthly revenue from recurring sources | Calculated | Current state |
Patient Behavior Metrics
| Metric | Definition | Collection Method | Target Baseline Period |
|---|---|---|---|
| Case acceptance rate (uninsured) | % of presented treatment accepted by uninsured patients | PMS treatment tracker | Trailing 6 months |
| Uninsured patient retention rate | % of uninsured patients returning within 18 months | PMS patient activity | Trailing 18 months |
| New patient conversion (uninsured) | % of new uninsured patients who complete treatment | PMS patient journey | Trailing 12 months |
| Reactivation rate | % of lapsed uninsured patients returning | PMS patient activity | Trailing 12 months |
Operational Metrics
| Metric | Definition | Collection Method | Target Baseline Period |
|---|---|---|---|
| Time to enroll (if existing plans) | Average minutes to enroll a patient in current plan | Time study or estimate | Current process |
| Billing staff hours on membership admin | Hours/week spent managing current plans | Staff survey | Current state |
| Payment collection rate | % of billed amount collected from uninsured patients | PMS A/R report | Trailing 12 months |
| Days to payment (uninsured) | Average days from service to payment | PMS A/R aging | Trailing 6 months |
Standardization Protocol
☐ Create baseline metric definitions document and distribute to all location managers
☐ Designate one analyst to extract baseline data from all locations (ensure consistency)
☐ Use identical date ranges for all locations
☐ Document any data quality issues or exceptions by location
☐ Store baseline data in central repository (shared drive, data warehouse) with version control
Estimated time for baseline data collection: 3–5 days with centralized analyst support
3. Location Readiness Assessment
Scoring Framework
Rate each location 1–5 on the following factors, where 1 = significant barriers and 5 = fully ready.
Factor 1: IT Infrastructure Maturity (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | Network speed >50 Mbps, all workstations <3 years old, PMS current version, previous successful integrations |
| 4 | Network speed 25–50 Mbps, workstations <5 years old, PMS within one version of current |
| 3 | Network speed 15–25 Mbps, mixed workstation age, PMS 2+ versions behind but supported |
| 2 | Network speed 10–15 Mbps, workstations >5 years old, PMS version may require upgrade |
| 1 | Network issues, outdated hardware, PMS version not supported, significant technical debt |
Factor 2: Staff Tenure and Adaptability (Weight: 25%)
| Score | Criteria |
|---|---|
| 5 | Average tenure >3 years, turnover <15%, history of successful tech adoption, proactive learning culture |
| 4 | Average tenure 2–3 years, turnover 15–25%, generally positive tech adoption history |
| 3 | Average tenure 1–2 years, turnover 25–35%, mixed tech adoption experience |
| 2 | Average tenure <1 year, turnover 35–50%, some resistance to previous tech changes |
| 1 | High turnover >50%, recent significant staff changes, known resistance to technology |
Factor 3: Patient Volume (Weight: 15%)
| Score | Criteria | Impact Note |
|---|---|---|
| 5 | 150–200 patients/week | High impact potential, manageable complexity |
| 4 | 200–250 patients/week | Strong impact potential, moderate complexity |
| 3 | 100–150 patients/week | Moderate impact, lower risk |
| 2 | 250+ patients/week | Highest impact but highest risk—consider for Wave 2+ |
| 1 | <100 patients/week | Lower ROI priority, may defer to later waves |
Factor 4: Existing Tech Stack Compatibility (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | PMS with proven Kleer integration, standard configuration, no conflicting software |
| 4 | Supported PMS, minor customizations, no major conflicts |
| 3 | Supported PMS with moderate customizations requiring configuration adjustments |
| 2 | PMS supported but with known integration challenges, or legacy systems requiring workarounds |
| 1 | Unsupported PMS version, significant custom development required, or incompatible parallel systems |
Factor 5: Local Champion Availability (Weight: 20%)
| Score | Criteria |
|---|---|
| 5 | Identified tech-forward office manager + provider champion, both committed |
| 4 | Strong office manager champion with provider support |
| 3 | Willing office manager, neutral provider |
| 2 | No clear champion but no active opposition |
| 1 | No champion identified, or known skeptics in leadership positions |
Composite Readiness Score Calculation
Formula: (IT × 0.20) + (Staff × 0.25) + (Volume × 0.15) + (Tech Stack × 0.20) + (Champion × 0.20) = Readiness Score
Score Interpretation
| Composite Score | Readiness Tier | Rollout Recommendation |
|---|---|---|
| 4.0–5.0 | Tier 1: High Readiness | Wave 1 pilot candidates |
| 3.0–3.9 | Tier 2: Moderate Readiness | Wave 2 candidates |
| 2.0–2.9 | Tier 3: Requires Preparation | Wave 3 with remediation plan |
| <2.0 | Tier 4: Not Ready | Defer until prerequisites addressed |
Sample Assessment Matrix
| Location | IT (×0.20) | Staff (×0.25) | Volume (×0.15) | Tech (×0.20) | Champion (×0.20) | Composite | Tier |
|---|---|---|---|---|---|---|---|
| Metro East | 4 (0.80) | 5 (1.25) | 4 (0.60) | 4 (0.80) | 5 (1.00) | 4.45 | Tier 1 |
| Suburban North | 5 (1.00) | 4 (1.00) | 3 (0.45) | 5 (1.00) | 4 (0.80) | 4.25 | Tier 1 |
| Downtown Central | 3 (0.60) | 3 (0.75) | 5 (0.75) | 4 (0.80) | 3 (0.60) | 3.50 | Tier 2 |
| Rural West | 2 (0.40) | 4 (1.00) | 2 (0.30) | 3 (0.60) | 2 (0.40) | 2.70 | Tier 3 |
Rollout Sequence Recommendations
Wave 1 Pilot Selection (2–3 locations)
Select locations that score Tier 1 AND meet these additional criteria:
- ☐ Geographic diversity (if applicable) to test regional variations
- ☐ Represent different PMS platforms in your portfolio (if multiple)
- ☐ Include at least one location with existing informal membership plan (migration learning)
- ☐ Include at least one location with no prior membership program (greenfield learning)
- ☐ Avoid your highest-revenue location (manage risk while learning)
Pre-Wave Remediation for Lower-Scoring Locations
For locations scoring <3.0, create remediation plans before their scheduled wave:
| Issue | Remediation | Timeline |
|---|---|---|
| IT Infrastructure <3 | Network upgrade, hardware refresh, PMS update | 2–4 weeks |
| Staff Adaptability <3 | Additional training, change management intervention | 2–3 weeks |
| No Champion <3 | Recruit and prepare champion, or assign regional support | 2 weeks |
| Tech Compatibility <2 | PMS upgrade or 🔵 vendor consultation on workaround | 3–6 weeks |
4. Rollout Strategy
Wave Structure Overview
| Wave | Locations | Selection Criteria | Timeline |
|---|---|---|---|
| Wave 1 (Pilot) | 2–3 | Tier 1 readiness, strategic diversity, strong champions | Weeks 3–6 |
| Wave 2 (Expansion) | 5–8 | Tier 1–2 readiness, incorporates Wave 1 learnings | Weeks 9–12 |
| Wave 3 (Scale) | 5–10 | Tier 2–3, remediation complete | Weeks 15–18 |
| Wave 4 (Completion) | Remaining | All remaining locations | Weeks 19–22 |
Adjust wave sizes based on total location count. For 15 locations, 3 waves may suffice. For 50 locations, 4–5 waves recommended.
Wave 1: Pilot Selection Criteria
Must-Have Criteria
☐ Composite readiness score ≥4.0
☐ Identified and committed local champion
☐ Office manager willing to provide detailed feedback
☐ No major competing initiatives during pilot period
☐ Executive sponsor has visited location within last 6 months (relationship exists)
Nice-to-Have Criteria
☐ Represents a common location profile in your portfolio
☐ Reasonable proximity to corporate/regional office for in-person support
☐ Existing informal membership plan to test migration workflows
☐ Provider who can speak credibly to other providers about the experience
Timeline Per Wave
Wave 1 Detailed Timeline (Weeks 3–6)
| Week | Activities |
|---|---|
| Week 3 | 🔵 Configuration and integration setup, champion training, test transactions |
| Week 4 | Staff training at pilot locations, patient communication materials deployed |
| Week 5 | Go-live at pilot locations, daily check-ins, real-time issue resolution |
| Week 6 | Stabilization, collect feedback, document learnings |
Buffer Period (Weeks 7–8)
- Compile Wave 1 learnings document
- Refine training materials based on feedback
- Adjust configuration template if needed
- 🟣 Conduct go/no-go review for Wave 2
Wave 2+ Timeline Template
Each subsequent wave follows a compressed 4-week cycle:
- Week 1: Configuration, integration, champion training
- Week 2: Staff training, final preparations
- Week 3: Go-live, intensive support
- Week 4: Stabilization, feedback collection
Go/No-Go Criteria Between Waves
Criteria to Advance to Next Wave
| Category | Green (Proceed) | Yellow (Proceed with Caution) | Red (Do Not Proceed) |
|---|---|---|---|
| Technical Stability | <2 critical issues, all resolved within 24 hours | 2–5 critical issues, resolved within 48 hours | >5 critical issues OR unresolved after 72 hours |
| Staff Adoption | >80% of staff report comfort with basic workflows | 60–80% report comfort | <60% report comfort |
| Patient Enrollment | >50% of target enrollments achieved | 25–50% of target achieved | <25% of target achieved |
| Champion Confidence | Champions request acceleration | Champions neutral | Champions recommend delay |
| Financial Performance | Revenue tracking within 10% of projections | Within 25% of projections | >25% variance from projections |
🟣 Decision Protocol
- All Green: Proceed to next wave on schedule
- Any Yellow: Proceed with documented remediation plan
- Any Red: Pause deployment, conduct root cause analysis, present findings to executive sponsor
Rollback Plan
Trigger Conditions for Rollback
- Critical system failure affecting patient care or payment processing
- Data integrity issues (incorrect patient records, payment errors)
- Widespread staff inability to perform basic functions after training
- Security incident or compliance violation
- Executive sponsor directive
Rollback Procedure by Severity
Level 1: Temporary Pause (24–72 hours)
- Disable new enrollment functionality
- Continue processing existing member payments
- Revert to manual tracking for new enrollments
- 🔵 Engage Kleer support for expedited resolution
- Do not advance to next wave until resolved
Level 2: Partial Rollback (Single Location)
- Disable Kleer at affected location only
- Revert to pre-Kleer enrollment process
- Manually export any enrolled members to tracking spreadsheet
- Continue deployment at other Wave locations
- Root cause analysis within 1 week
Level 3: Full Wave Rollback
- Disable Kleer at all Wave locations
- Export all enrollment data to CSV
- Revert all locations to manual processes
- 🟣 Executive briefing within 24 hours
- 🔵 Escalate to Kleer executive contact
- Develop remediation plan before resuming
Isolation Protocol
⚠️ Critical: Waves operate independently. A failure in Wave 2 should not require rollback of stable Wave 1 locations. Ensure:
- Each wave has independent configuration instances during go-live
- Wave 1 locations are stable for 2+ weeks before Wave 2 begins
- Data flows are validated before cross-wave dependencies are created
5. Configuration & Integration (Weeks 2–3)
Practice Management System Integration
Dentrix Integration
Prerequisites:
☐ Dentrix version G6.2 or higher (⚠️ earlier versions have limited API support)
☐ Dentrix Enterprise Server if using multi-location Dentrix
☐ Local admin credentials for Dentrix workstation
Step-by-Step Integration:
- ☐ 🔵 Request Kleer-Dentrix integration package from Kleer implementation manager
- ☐ Verify Dentrix version: Help → About Dentrix → Confirm version number
- ☐ Create dedicated Kleer user account in Dentrix with appropriate permissions
- ☐ Enable Dentrix API access: Office Manager → Preferences → API Settings
- ☐ ⚠️ Export current patient list for migration: File → Export → Patient Demographics
- ☐ 🔵 Provide export file to Kleer in specified format
- ☐ 🔵 Kleer configures integration and provides test credentials
- ☐ Test patient lookup: search for test patient in Kleer, verify data matches Dentrix
- ☐ Test enrollment workflow: enroll test patient, verify record updates in Dentrix
- ☐ Test payment processing: process test payment, verify transaction logged correctly
Estimated Time: 2–4 hours per location (with IT support)
Eaglesoft Integration
Prerequisites:
☐ Eaglesoft version 21.0 or higher
☐ Eaglesoft server accessible from Kleer (cloud connectivity)
☐ Database admin credentials
Step-by-Step Integration:
- ☐ 🔵 Request Kleer-Eaglesoft integration documentation
- ☐ Verify Eaglesoft version: Help → About
- ☐ Enable eCentral services if not already active (required for cloud integrations)
- ☐ Create API user in Eaglesoft: Setup → Security → Add User → API Access
- ☐ Configure firewall to allow Kleer API connections (🔵 Kleer provides IP whitelist)
- ☐ ⚠️ Export patient data: Reports → Patient → Demographics Export
- ☐ 🔵 Submit patient data to Kleer for migration
- ☐ 🔵 Kleer completes configuration and activates integration
- ☐ Validate bidirectional sync: create test patient, verify appears in both systems
- ☐ Test full enrollment-to-payment workflow with test data
Estimated Time: 3–5 hours per location
Open Dental Integration
Prerequisites:
☐ Open Dental version 21.1 or higher
☐ Customer API key from Open Dental (requires active support plan)
☐ Server access for API configuration
Step-by-Step Integration:
- ☐ 🔵 Request Open Dental integration guide from Kleer
- ☐ Generate Open Dental API key: Setup → Program Links → API → Generate Key
- ☐ 🔵 Provide API key to Kleer implementation team
- ☐ Configure Open Dental Program Link: Setup → Program Links → Add → Kleer
- ☐ 🔵 Kleer configures webhook endpoints for real-time sync
- ☐ Export historical patient data: Reports → Standard → Patient List
- ☐ 🔵 Submit export for migration
- ☐ Test integration: create test enrollment, verify patient record updates
- ☐ Validate fee schedule sync (if using Kleer's fee schedule management)
- ☐ Test reporting integration: verify Kleer data appears in Open Dental reports
Estimated Time: 2–3 hours per location (Open Dental typically has smoothest integration)
Test Environment Setup and Validation
Centralized Test Environment (Recommended for DSO)
☐ 🔵 Request dedicated Kleer sandbox environment for enterprise testing
☐ Configure sandbox with standardized configuration template
☐ Create test patient records representing common scenarios:
- New patient, no prior history
- Existing patient with treatment history
- Patient with prior membership (migration test)
- Patient with family members (family plan test)
Validation Checklist
| Test Scenario | Expected Outcome | Pass/Fail |
|---|---|---|
| New member enrollment | Patient enrolled, confirmation email sent, record synced to PMS | ☐ |
| Monthly payment processing | Payment charged on scheduled date, receipt generated | ☐ |
| Failed payment retry | System retries per configured schedule, alerts staff | ☐ |
| Member cancellation | Membership ended, cancellation confirmation sent | ☐ |
| Treatment discount application | Correct discount applied per plan terms | ☐ |
| Plan renewal | Annual renewal processed automatically | ☐ |
| Multi-location member transfer | Member can use benefits at any participating location | ☐ |
| Report generation | All standard reports generate accurately | ☐ |
⚠️ Do not proceed to production go-live until all test scenarios pass.
Data Migration Steps
Current Membership Data Migration
If your locations have existing informal membership programs:
- ☐ Compile all existing member lists from each location (spreadsheets, legacy software)
- ☐ Standardize data format per Kleer's migration template:
- Patient name, DOB, contact info
- Current plan type and pricing
- Enrollment date and renewal date
- Payment method (if stored)
- ☐ 🔵 Submit migration files to Kleer at least 2 weeks before go-live
- ☐ ⚠️ Reconcile member counts: source system count must match Kleer import count
- ☐ Communicate with migrated members about new system (payment method re-entry may be required)
- ☐ Test migrated member workflows before go-live
Historical Patient Data for Analytics
- ☐ Export relevant patient demographic data from PMS (last 24 months)
- ☐ 🔵 Confirm data fields with Kleer to support analytics and targeting features
- ☐ Establish data refresh cadence (real-time sync vs. nightly batch)
Security and HIPAA Compliance Verification
Enterprise-Level HIPAA Checklist
| Requirement | Verification Method | Status |
|---|---|---|
| 🔵 Business Associate Agreement (BAA) executed | Legal confirmation | ☐ |
| Data encryption in transit (TLS 1.2+) | 🔵 Kleer SOC 2 report review | ☐ |
| Data encryption at rest (AES-256) | 🔵 Kleer SOC 2 report review | ☐ |
| Access controls and audit logging | 🔵 Kleer security documentation | ☐ |
| Breach notification procedures defined | BAA terms confirmation | ☐ |
| Data retention and deletion policies | 🔵 Kleer data governance documentation | ☐ |
| Minimum necessary access enforced | User role configuration review | ☐ |
| Staff HIPAA training completed | Internal training records | ☐ |
Access Control Configuration
☐ 🟣 Define data access policy: who can see PHI at which levels
☐ Configure role-based access in Kleer matching policy:
- Enterprise Admin: full access all locations
- Regional Manager: access to assigned region only
- Location Admin: access to single location only
- Provider: patient-level access, own patients only
- Front Desk: enrollment and basic member management
☐ Enable audit logging for all PHI access
☐ Configure automatic session timeout (recommended: 15 minutes)
☐ Implement IP restrictions if required by organizational policy
Configuration Standardization
Standardized Configuration Template (Apply to ALL Locations)
| Setting | Standard Value | Rationale |
|---|---|---|
| Payment retry schedule | 3 attempts over 7 days | Balances recovery with patient experience |
| Failed payment notifications | Day 1, Day 3, Day 7 | Standardized communication |
| Auto-renewal | Enabled by default | Maximizes retention |
| Renewal reminder | 30 days before expiration | Consistent member experience |
| Cancellation policy | 30-day notice required | Standardized terms |
| Family plan maximum | 4 members per account | Consistent offering |
| Corporate branding | Kleer co-branded with DSO logo | Brand consistency |
| Receipt format | Standardized template | Professional consistency |
Location-Specific Configuration (May Vary)
| Setting | Why It May Vary |
|---|---|
| Plan pricing | Market-adjusted pricing by region |
| Fee schedule discounts | Tied to local UCR rates |
| Plan names | May need local market testing |
| Provider associations | Based on local staffing |
| Office hours for support | Time zone differences |
| Local marketing materials | Regional compliance requirements |
6. Team Training Plan
Train-the-Trainer Model
Champion Selection Criteria
☐ Tenure >1 year at location
☐ Successfully adopted previous technology implementations
☐
AI-generated implementation guide based on public vendor information. Verify specifics directly with Kleer.