How does SeniorCRE run the SNF triple-check meeting so claims go out clean the first time?
Roadmap — not built
The platform does not yet ship a dedicated module for this workflow. The “How the platform is designed to run it” description below reflects designed-and-planned behavior, not currently shipping code. Outcome figures are modeled targets.
Design target · Expected outcome
90 min meeting → 30 min; higher clean-claim rate
Design target modeled from workflow design. No operator community has been measured, no approved Evidence Record supports it, and business outcomes remain contributory — figures are targets, not results. See Industry Findings for methodology.
Incumbents this workflow touches
Proposed in-platform scope: Paper triple-check binder · Cross-team email thread before billing window closes
Roadmap integration targets (not live): HL7 v2 / FHIR R4 clinical feeds · Flat-file EHR extracts
The operator may retain existing systems or select SeniorCRE for defined functions. Alongside existing systems, this workflow would depend on approved source access, implementation and operator acceptance. Named vendor integrations are roadmap targets, not completed connections.
The problem
Triple-check is the weekly ritual every SNF business office runs before Medicare and managed-care claims drop. On a fragmented stack, the MDS coordinator, the biller, and the DON each bring their own spreadsheet, the meeting takes 90 minutes, and the team still discovers a missing physician certification two days after the claim has been submitted.
How the platform is designed to run it
Triple-check runs from one screen. Each claim in the upcoming bill cycle shows the supporting MDS (with lock status and ARD), the HIPPS code with PDPM component breakdown, the physician certification and recertification, the orders on file, the eligibility verification result, and the documented therapy minutes. Exceptions surface as actionable tasks — missing recert, expired auth, eligibility-and-billing mismatch — owned by name before the meeting starts. The meeting becomes review, not discovery.
Proposed operating behavior, not a live deployment. Source access, implementation and operator acceptance must be established before this workflow can operate in a community.
On the shift (illustrative)
Illustrative example on synthetic data. Names, figures, and events are not from any operator community.
Wednesday at 10 a.m. the business office, the MDS coordinator, and the DON open the triple-check screen together. Twenty-three Medicare and Medicare-Advantage claims are queued for the Friday drop. Each row shows the MDS lock status, the HIPPS code with the PT/OT/SLP/NTA components, the physician cert status, the eligibility check, and the therapy minutes. Three exceptions surface: a missing recert on one resident, an authorization expiring before the date of service on another, and a HIPPS-vs-supporting-documentation variance on a third. Each is a named task that closes before the claim drops. The meeting ends in 30 minutes.
Design target
Triple-check meetings compress from 90 minutes to 30. Clean-claim rate at submission improves, and the denials that previously came back two weeks later for missing documentation drop because the documentation gap was caught before the claim left the building.
Design target only: not measured or validated in any community. Actual results require an operator baseline and pilot acceptance.
What goes wrong without it
On a fragmented stack the same meeting runs 90 minutes and still misses things. The MDS coordinator brings one spreadsheet, the biller brings another, and the DON has the certs in a separate folder. The missing recert is discovered the day after the claim is denied. The HIPPS variance is discovered three weeks later when the 835 lands at a different rate than expected. Each missed catch is a denial that takes 45 days to rework — and a recurring revenue leak nobody attributes to triple-check.
Sources for baselines cited above
Industry benchmarks referenced in the problem statement or outcome come from these third parties. SeniorCRE figures are labeled with their evidence class — modeled from workflow design and benchmarks, not yet measured in a customer community.
- CMS — SNF PDPM and payment policy manual
Centers for Medicare & Medicaid Services
Show me the evidence
Operators do not buy claims. They buy proof. If anything on this page reads as aspirational, ask us to walk you through exactly what is built, what is designed, and what is not yet in production in any community.
Where this connects in the platform
Every financial workflow runs on the same record. These are the feature pages, head-to-head comparisons, and pillar articles that go deeper on the surfaces this workflow touches.
Feature surfaces
Compared head-to-head
Regulatory and accounting references
Financial workflows on this page reflect CMS PDPM and PDGM payment rules, GAAP revenue recognition (ASC 606), and the state Medicaid case-mix programs that drive reimbursement.
- Patient Driven Payment Model (PDPM) — SNF Payment Methodology
CMS
Component scoring (PT, OT, SLP, Nursing, NTA) and the variable per-diem adjustments that drive Part A revenue.
- Medicaid Case-Mix Reimbursement — RUG-IV and successor systems
Medicaid.gov
State-level case-mix methodology overview; each state files its own State Plan Amendment with rate calculation detail.
- ASC 606 — Revenue from Contracts with Customers
FASB
The GAAP standard for revenue recognition; governs how room-and-board, ancillary, and Medicaid revenue is recognized over the resident stay.
- OIG Compliance Program Guidance for Nursing Facilities
HHS OIG
Federal expectations for billing integrity programs — drives audit-log requirements and segregation of duties around claims.