Quick snapshot to get us started

• Which value-based programs are you currently participating in? Options: Medicare Shared Savings Program, Medicare Advantage risk contract, Commercial risk arrangements, Medicaid managed care, Other / mixed
• Tell me briefly how your team currently uses provider-level performance reports Options: For physician coaching, For executive reporting, For contract reconciliation, For care management prioritization, We do not use them regularly
• In a typical quarter, where do the claims and cost files you rely on originate from Options: Payer feeds/clearinghouse, Internal billing system, Third-party aggregator, EHR cost module, Health information exchange
• How quickly after the service date do you usually receive final paid claims for analysis Options: Under 30 days, 30 to 60 days, 61 to 120 days, Over 120 days
• Describe one recent provider-level performance conversation that felt unhelpful, and why
• Would you commit to a short pilot within six weeks if provider-level attribution met your tolerance Options: Yes, Maybe, need procurement signoff, No, not at this time

Where your numbers actually come from

• If your current attribution rules shifted tomorrow, which providers would show the biggest reported change in responsibility
• Walk me through the exact files and systems a typical monthly data load includes, for example claim type, credentialed roster, or cost files
• Which payer or clearinghouse feeds currently supply the largest share of your claims volume Options: Commercial payers, Medicare FFS, Medicare Advantage, Medicaid, Multiple small payers
• How many calendar days of lag do you typically see between a service date and a paid claim arriving to your analytic environment Options: <30 days, 30-60 days, 61-120 days, >120 days
• Tell me an example of a provider-level result that surprised your clinical team and what investigation followed

The single target that makes or breaks your year

• Name the one clinical or financial target that, if missed, would immediately jeopardize shared savings or trigger contract penalties this year
• What time horizon do you use to evaluate that target, 6 months, 12 months, or a full contract year Options: 6 months, 12 months, Contract year, Other
• Who in your organization owns that metric day to day, and who has quarterly signoff authority Options: Medical director, VP population health, CFO, Quality director, Other
• Describe how that target maps to any contract benchmarks or externally reported measures we must align to
• Assuming a pilot demonstrates a 3 to 5 percent reduction in total cost of care for the eligible population, what decision would that trigger Options: Enterprise rollout, Expanded pilot, Negotiate commercial terms, No action

Who moves first when the data looks different

• Who will have final authority to act on provider-level insights and reassign resources if performance deviates Options: Medical director, CFO, VP population health, Quality committee, Other
• List the operational owners we should coordinate with during deployment, for example data engineers, privacy, or care management Options: Data engineering, IT/security, Compliance/privacy, Care management, Practice leadership, Finance
• Approximately how many physician leaders will need a tailored view versus one shared dashboard Options: 1-3, 4-10, 11-25, 26+
• Recall a past project where clinician engagement lagged, why did leaders hold back and how was it addressed
• Should a provider publicly dispute an attribution assignment, who is enabled to respond and what authority do they have Options: Medical director, Site chief, Compliance/legal, Finance, Other
• Would a requirement for custom attribution logic by specialty stop the project from moving forward Options: Yes, Maybe, depending on cost, No

What breaks first when we try to scale

• Name the single constraint that would stop the project immediately, for example legal hold, no data access, or executive veto Options: Data access or ownership, Legal/privacy approval, No executive sponsorship, IT capacity, Other
• When you reconcile expected versus actual total cost, what explains the largest share of discrepancies Options: Claim lag, Attribution differences, Coding variation, Missing cost data, Other
• Explain the legal or privacy reviews required to share patient-level claims and whether your team has a standard authorization template Options: Formal DUA required, Standardized BAAs in place, Needs legal review case by case, Other
• List the technical blockers you have faced on past integrations, for example missing API endpoints, rate limits, or vendor maintenance windows
• In practice which role first flags a data quality issue and how quickly can that person act to pause an import if needed Options: Data engineer, within hours, Analytics lead, within 24 hours, Compliance, within days, No clear owner

Other paths you're weighing

• What alternatives are you actively evaluating, including staying with the incumbent, an internal build, or analytics tied to your EHR Options: Incumbent analytics vendor, Internal build, EHR vendor analytics, Large cloud analytics partner, Consulting engagement, Do nothing
• Under what circumstances would you choose to keep your current approach rather than change Options: If costs are lower, If attribution matches our rules, If data latency improves, If internal team commits to build
• Are any internal teams actively proposing an internal solution, and if so which groups and who would lead that effort
• Rank the following decision factors for vendor versus internal build, cost, time to value, clinical credibility, and ongoing support Options: Cost, Time to value, Clinical credibility, Support and SLAs
• Assuming the pilot meets your performance threshold, how quickly could procurement and contracting move to final approval Options: Immediately, 2-4 weeks, 4-8 weeks, 2-3 months, >3 months

Can your systems and teams meet the timeline

• Start by telling me whether your core data sources expose APIs or if we will need periodic file extracts Options: APIs available, Periodic file extracts only, Hybrid
• Please select the primary systems we must integrate, choose all that apply Options: Claims clearinghouse, EHR, Practice management, Finance/billing, HIE, Other
• Explain who owns each integration, do you have named technical contacts and can they provide credentials within a six week window Options: Yes, contacts and credentials available, Contacts available but credentials delayed, No clear technical owner
• When prior integrations stalled, how much engineering time did you typically allocate to troubleshooting in the first 30 days Options: <40 hours, 40-160 hours, 160-400 hours, >400 hours
• Are there internal compliance steps or committee approvals that routinely delay data access and what is their typical lead time Options: Privacy committee, 2-6 weeks, Legal review, 2-8 weeks, Executive signoff, 1-4 weeks, No routine delays
• Setting a go-live target 12 weeks from integration start, identify the single constraint that would make that infeasible

If the numbers check out, how do we cross the finish line

• Suppose the pilot meets your defined target, what final gate would still block a rapid purchase decision Options: Procurement red tape, Legal/contract terms, Executive funding, Clinician acceptance, Other
• Provide the measurable acceptance criteria you will require for a pilot to be considered successful Options: Attribution accuracy threshold, Data latency threshold, Clinical signoff on dashboards, Minimum financial delta, User adoption rate
• Select your earliest realistic procurement timeline once the pilot is successful Options: Immediately, 2-4 weeks, 4-8 weeks, 2-3 months, >3 months
• Identify the roles that must sign the final statement of work for enterprise rollout Options: CFO, Medical director, CIO/IT, Legal, Procurement
• Confirm which single metric will trigger an enterprise rollout if the pilot succeeds Options: >=3% total cost of care reduction, Improvement on specified quality measure, Provider-level engagement threshold met, Other
• Outline your preferred cadence for post-deployment reviews and who should attend each review

• Solution Experience Session — Provider-Level Insights

• Confirm the current state and its cost
• You confirm the current_state sentence accurately reflects your operational pain and its cost.
• Provide a 3-month sample of claims, clinical, and cost files plus the list of providers and the two use-cases you want validated.
• Agree acceptance criteria for provider-level insights
• You confirm the demonstrated conversion of your scenario produces provider-level outputs that would eliminate the identification gap and support physician action.
• Seller to run a full conversion of the provided sample months and deliver provider-level scorecards and a comparison to your current reports before the follow-up session.
• Run your scenario end-to-end
• Provide current attribution rules and any existing provider directories or mapping files to validate provider assignment.
• You agree on the measurable acceptance criteria and the remaining evidence needed to proceed to scope and deployment planning.
• Identify two physician leaders who will review and validate the scorecards in the follow-up review.
• Validate attribution and provider mapping
• Show physician-facing drill-downs and scorecards
• Confirm this matches what you described needing

• Solution Experience Session — Provider-Level Insights
• Solution Experience Deck
• Solution Experience Brief

• meeting
• slides
• document

• Claims Data Ingestion and Normalization
• EHR Clinical Data Integration
• Cost and Charge Data Mapping
• Contract Benchmark and Target Configuration
• Provider Attribution Alignment and Reconciliation
• Provider-Level Performance Scorecards
• Total Cost of Care Analytics Setup
• Care Gap Identification and Quality Measure Engine
• Risk Adjustment and HCC Optimization
• Shared Savings Modeling and Forecasting
• Provider Drilldown Dashboards and Root-Cause Views
• Training for Physician Leaders and Finance Teams
• Data Export, API and Reporting Integration

Claims Data Ingestion and Normalization

• Provide the file formats and transport methods you will deliver for claims (for example: EDI 837P/837I, 835 remittance, flat CSV via SFTP, secure API).
• List the payer sources and payer IDs you expect to include in initial ingestion (Medicare Part A, Medicare Part B, Medicare Advantage plan IDs, commercial payers, Medicaid plan IDs).
• Identify the typical claims latency you observe (days from service date to claim availability) and average monthly claim volume by payer for a 12-month period.
• Specify required normalization outputs we must produce for downstream modules (for example: standardized ICD-10 primary diagnosis, CPT/HCPCS crosswalk, normalized place-of-service, and NPI-to-TIN provider mapping).
• Estimate the expected match rate between incoming claims and your beneficiary master index using current identifiers (NPI, member ID, DOB); indicate target acceptance threshold as a percentage. Options: Less than 80%, 80-90%, 90-95%, 95%+
• What measurable acceptance criteria will validate successful claims ingestion and normalization (examples: >=95% valid ICD-10 presence, <=2% file parsing errors, monthly ingestion completed within X hours)?

EHR Clinical Data Integration

• Describe the clinical sources you want integrated (specify EHR name generically as your current EHR, and indicate whether you will provide FHIR APIs, CCD/CCDA exports, or HL7 v2 feeds). Options: FHIR API, CCD / CCDA, HL7 v2 messages, Flat exports (CSV/XML)
• Provide typical clinical document types to include (for example: problem list, medication list, encounter notes, vitals, laboratory results), and indicate which are mandatory for measures you prioritize.
• Confirm whether you can supply a patient-provider attribution roster from the EHR (panel lists, assigned PCP lists) and the file format for that roster. Options: Yes - CSV roster, Yes - API roster, No
• Identify any structured data barriers in the EHR (for example: key fields stored only in free-text encounter notes, scanned documents, or external vendor modules).
• Which clinical terminologies must we support and reconcile (for example: LOINC for labs, SNOMED CT for problems, RxNorm for medications)? Options: LOINC, SNOMED CT, RxNorm, Other
• Specify expected cadence for clinical extracts or API access (for example: daily incremental FHIR pulls, weekly bulk CCD), and any maintenance windows that constrain access. Options: Daily, Weekly, Monthly, On-demand / API

Cost and Charge Data Mapping

• State the cost sources available (for example: internal cost accounting exports, chargemaster/charge description master, cost-to-charge ratios tied to UB-04/837I).
• Identify the preferred unit of cost analysis you need (for example: allowed amount per line item, paid amount by claim, cost-to-charge adjusted cost per encounter). Options: Allowed amount, Paid amount, Cost-to-charge adjusted cost, Custom metric
• Describe any existing mappings between billing codes and cost centers (for example: CPT-to-department, revenue code mappings) and provide sample mapping files if available.
• Which timeframe should be used to normalize historical charge and cost data for inflation or contract-year alignment (for example: calendar year, contract year, rolling 12 months)? Options: Calendar year, Contract year, Rolling 12 months, Custom
• Indicate whether you require line-level cost allocation (facility + professional split) and the target granularity (per claim line, per encounter, per beneficiary-month). Options: Per claim line, Per encounter, Per beneficiary-month, Not required
• Specify SLAs for cost data reconciliation with finance (for example: monthly reconciliation within X business days, variance tolerance % for cost-to-charge ratios).

Contract Benchmark and Target Configuration

• Provide the contract benchmark artifacts you will supply (for example: CMS benchmark files, signed contract spreadsheet, target risk corridor parameters, discount rates).
• Identify the benchmark methodology in your contract that we must implement (for example: regional blend, historical trending with trend factors, minimum savings rate, quality thresholds).
• State any fixed commercial terms that constrain modeling options (for example: minimum annual commitment, upside-only vs upside/downside, reconciliation frequency).
• Which performance periods and cohort windows should the platform use for baseline and performance comparisons (for example: contract year, rolling 12 months, lookback period of X months)? Options: Contract year, Rolling 12 months, Custom lookback
• Specify required benchmark outputs for finance and contract reviews (for example: benchmark per beneficiary per year, expected savings by TIN, monthly variance reports).
• Identify any out-of-scope assumptions for fixed-fee engagements (for example: we will not re-negotiate payer contracts, we will not perform claims appeals or payer-level reprocessing).

Provider Attribution Alignment and Reconciliation

• Provide the attribution rules specified in your contract (for example: plurality of primary care visits, retrospective monthly attribution, prospective assignment rules) and the source of truth roster if any.
• Identify the provider identifiers you require for attribution alignment (for example: NPI, TIN, group NPI, provider specialty codes) and confirm any non-standard mappings.
• Which reconciliation tolerance will you accept between our attribution outputs and your internal panel lists (for example: +/- 2% monthly variance, or absolute difference in assigned beneficiaries)? Options: <=1% variance, <=2% variance, <=5% variance, Other
• Describe the cadence and artifact you will use to reconcile attribution (for example: monthly CSV roster, quarterly provider review meeting, signed reconciliation spreadsheet).
• Identify primary owners on your side for attribution disputes and final roster approval (job titles or roles, not personal names).
• What evidence will validate attribution reconciliation for sign-off (for example: reconciled roster with provider initials, variance report under threshold, audit log of claim-to-provider mappings)?

Provider-Level Performance Scorecards

• Specify the provider-level metrics you need on scorecards (for example: HEDIS measure rates, readmission rate per 1,000, per-member-per-month cost, risk-adjusted utilization by service line).
• Identify the display granularity required (for example: NPI-level, clinic-level rolled up to TIN, specialty-level aggregates). Options: NPI-level, Clinic-level, TIN-level, Specialty-level
• Describe the comparative benchmarks to show on scorecards (for example: internal historical baseline, peer group percentile, CMS regional benchmark, contract target).
• Which drillpath actions should be available from a scorecard item (for example: link to claims list, patient roster, encounter-level detail, suggested interventions)? Options: Claims list, Patient roster, Encounter detail, Suggested interventions
• Indicate the refresh cadence expected for scorecards (for example: monthly after claims close, weekly for near-real-time clinical data) and acceptable staleness. Options: Daily, Weekly, Monthly, Quarterly
• How will you verify provider leaders accept the scorecards as authoritative (for example: documented sign-off by medical director, completion of a scorecard review checklist)?

Total Cost of Care Analytics Setup

• State the population cohort definitions to use for total cost of care (for example: attributed beneficiaries per contract, risk strata, commercial vs Medicare Advantage cohorts).
• Identify the cost attribution rules you prefer for shared services or global budgets (for example: distributed by encounter, apportioned by RVU, or excluded entirely). Options: Apportioned by encounter, Distributed by RVU, Excluded, Custom rule
• Specify risk adjustment approach to apply for TCOC (for example: CMS-HCC model version, internal risk scores, no adjustment) and provide any required coefficient files. Options: CMS-HCC v24, CMS-HCC v23, Internal risk score, No adjustment
• Describe required TCOC outputs for finance and clinical teams (for example: PB PY cost, monthly trend by cohort, cost-driver waterfall by clinical condition).
• Identify any specific service lines to exclude or treat separately in TCOC (for example: dialysis, transplants, out-of-network catastrophic claims).
• Estimate historical period to include for baseline TCOC modeling (for example: prior 12 months, prior 24 months) and whether to apply seasonal smoothing. Options: Prior 12 months, Prior 24 months, Custom

Care Gap Identification and Quality Measure Engine

• Which quality measure sets must the engine support (for example: HEDIS, CMS measure specs, state Medicaid measures) and list specific measures of priority. Options: HEDIS / NCQA, CMS measures, State Medicaid measures, Custom measures
• Provide the data sources required for gap detection (for example: claims CPT/HCPCS codes, lab LOINC results from EHR, immunization registries) and indicate availability.
• Specify the logic versioning and audit requirements for measure definitions (for example: maintain HEDIS spec version history, audit trail of measure calculation changes). Options: Maintain version history, No versioning required, Custom audit needs
• Indicate preferred output for care gap workflows (for example: patient lists for care managers, provider inbox alerts, automated outreach export). Options: Patient lists, Provider alerts, Outreach export, Other
• Identify tolerance for false positives in gap detection and any required manual validation steps before outreach (for example: manual chart review for 10% sample).
• Describe whether the measure engine should produce denominator exclusion audits and provide the artifacts used to justify exclusions (for example: clinical notes, lab values, prior authorization records). Options: Yes, No

Risk Adjustment and HCC Optimization

• Which diagnosis coding sources will be used for HCC capture (for example: inpatient claims ICD-10, outpatient claims, problem list in EHR) and their expected completeness?
• Specify the CMS-HCC model version to target for optimization and whether prospective or concurrent modeling is required. Options: Latest CMS-HCC, Previous CMS-HCC, Concurrent model, Prospective model
• Identify workflows you expect for clinical documentation improvement (for example: chart retrieval lists, priority diagnosis lists, provider outreach templates).
• Provide acceptance thresholds for coding completeness improvements (for example: increase captured HCC-coded beneficiaries by X% within 6 months).
• Indicate whether the team requires supporting audit files for risk adjustment submissions and the preferred file format (CSV, PDF supporting documentation). Options: CSV, PDF, Both
• Estimate the expected annual uplift in risk score you consider realistic from optimization activities, if available. Options: <1%, 1-3%, 3-5%, 5%+

Shared Savings Modeling and Forecasting

• Describe the profit-and-loss view needed for shared savings (for example: monthly realized savings, forecasted run-rate, reconciliation schedules).
• Identify modeling levers you want configurable (for example: trend factors, stop-loss thresholds, minimum savings rate, risk corridors).
• Specify forecast horizon and refresh cadence (for example: 12-month rolling forecast updated monthly, quarter-ahead scenario planning). Options: 12-month rolling, Quarterly, Monthly, Custom
• State any required sensitivity outputs for finance review (for example: best/worst case scenarios, impact by service line, provider-level forecast variance).
• Indicate which internal finance artifacts will be used to validate forecasts (for example: GL extracts, monthly claim payouts, reinsurance invoices).
• Specify required export formats for modeling outputs used in your board or payer reporting (for example: Excel workbooks with assumptions sheet, PDF executive summary). Options: Excel workbook, PDF summary, CSV exports, All of the above

• Subscription Agreement (Order Form)
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Data Processing Agreement / HIPAA Business Associate Addendum (DPA / BAA)
• Data Access & Use Authorization
• Service Level Agreement (SLA)
• Deployment Timeline & Responsibility Schedule
• Acceptance Criteria & Data Validation Plan

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Ongoing Quarterly Success Review

• Create prioritized backlog entries for agreed enhancements and estimate delivery windows for the next quarter.
• Open issues are triaged with owners and next verification steps scheduled.
• All connectors are verified live or have a documented remediation plan and target resolution date.
• Re-confirm success criteria and ownership
• A documented acceptance decision for each numeric criterion recorded in Solution Scope is captured in the project record.
• For any unmet criteria, a timebound remediation and revalidation plan is agreed and scheduled.
• All parties agree on the evidence package that constitutes a revalidation for conditional items.
• Publish the formal acceptance decision and attach the evidence package used for the decision to the shared workspace.
• Create remediation tasks for any failed criteria with verification steps and target dates for revalidation.
• If signatory capture is required, collect the named signatory and store the signed acceptance record in the project folder.
• Trend review for outcome metrics
• Quarterly trend direction for the named outcome metrics is documented and any deviations have assigned corrective actions.
• High-priority defects and enhancement requests are triaged and scheduled or assigned to a backlog sprint.
• A short list of adoption or training actions is agreed for the next quarter to improve dashboard use by physician leaders.
• Publish the quarterly performance summary with trend charts and open-ticket status for stakeholder review.
• Schedule identified training sessions and publish attendee objectives and materials in advance.
• Named owners confirmed for each acceptance criterion recorded in Solution Scope.
• Publish the go-live health check summary including connector status and open issues for asynchronous review.
• Run end-to-end sample data ingestion check and post results to the shared workspace within 48 hours.
• Schedule the next data validation run and user adoption checkpoint before the first measurement meeting.
• Present first measurement data
• Stakeholders accept the first-period measurement and its data provenance as sufficient for diagnosis.
• A concise remediation plan is agreed for any metric gaps, with resolution dates that align to the acceptance gate timeline.
• Confirmation that attribution logic and claims lag are understood and documented for ongoing measurement.
• Produce a measurement packet including raw data extracts, attribution logs, and the calculation workbook for the presented metrics.
• Execute agreed data-quality fixes and schedule a re-run of the measurement within the agreed remediation window.
• Document any changes to attribution rules and publish the updated rule set for buyer review before the acceptance gate.
• Restate acceptance criteria and numeric targets
• Deployment and connector validation
• Open issues and ticket burn-down
• Data provenance and attribution review
• Present outcome data versus each criterion
• Document pass or fail per criterion and capture decision
• Enhancement requests and backlog prioritization
• Root-cause diagnosis for gaps
• Early adoption signals and usage review
• Open issues and blocker triage
• Agree remediation plan for any failed or conditional criteria
• Adoption and training needs
• Agree corrective actions and timeline to acceptance gate
• Agree immediate remediation actions