A 45–60 day pilot architecture for smarter staffing, accurate billing, and measurable savings at Niles.
Dockerty operates 9 elder care buildings in Michigan on a $20M annual labor base. Staffing decisions are made by feel. Care-level billing is assessed subjectively. Three data systems — ECP, Inspiren, and Easy Shifts — have never been synthesized into a single decision surface. This proposal lays out a three-module platform that addresses all three problems in a 45–60 day pilot at the Niles building, using data Dockerty already owns.
The Problem
Each problem is solvable today, with data Dockerty already has. They compound each other: staffing guesswork drives up labor cost; subjective billing leaves revenue uncollected; data silos make both invisible.
01
Shift coverage is estimated without reference to resident acuity data, creating unnecessary overtime and agency-nurse spend that isn’t visible until payroll closes.
02
Care-level billing is based on subjective assessment, not documented delivery. Revenue is left on the table every billing cycle when care hours exceed the billed level.
03
ECP, Inspiren, and Easy Shifts each hold a piece of the picture. None of them talk to each other. The decision layer runs entirely on institutional memory.
The Vision
The Director of Nursing at Niles opens her morning tablet view. It shows three things: which residents’ acuity shifted overnight, how that changes today’s care demand across the two wings, and which residents are delivering more care than their current billing level reflects. She makes one staffing swap, flags two residents for billing review, and walks into morning huddle with a data-backed plan instead of a clipboard estimate. Within 60 days of go-live, the executive director can see an unambiguous expense line moving downward on overtime and agency costs — not a spreadsheet estimate, but the actual ledger.
The Platform
Each module is independently deployable and designed so every recommendation traces to named residents and named data points. A DON who can’t explain a recommendation will ignore it — so every suggestion carries its source.
Compares ECP care plan data against current billed care levels. Flags every resident whose documented care delivery justifies a higher billing rate — before each scheduled level-of-care review.
Weekly report surfaced to Carolyn (Director of Clinical Services) listing flagged residents with supporting data. Carolyn reviews each flag and owns the sign-off decision. No billing change is recommended without her approval.
Builds a daily acuity score per resident from care plan and sensor data. Rolls it up to the wing and shift level. Compares it against the scheduled staffing in Easy Shifts to surface coverage gaps before they become incidents.
AL and MC scored separately. MC adds wandering events, behavioral data, and sleep disruption.
Gives the executive director a weekly view of actual vs. recommended staffing, overtime percentage, agency spend, and variance to budget — with a pre-registered methodology for attributing savings to the platform.
ED weekly cost/coverage report: actual vs. recommended staffing, OT%, agency spend, week-over-week trends, and variance to budget. Savings are calculated against a named pre-pilot baseline period, not reverse-engineered from results.
Financial Case
Two separate revenue lines, measured independently. Labor savings from acuity-matched scheduling; billing recovery from documented care vs. billed level. Both are calculable from data Dockerty already holds.
| Scenario | Annual Reduction |
|---|---|
| Conservative (15% OT/agency reduction) | $45K–$94K |
| Base case (25% reduction) | $75K–$156K |
| Upside (35% + agency consolidation) | $105K–$219K |
Residents whose documented care hours exceed their billed care level represent recoverable revenue every billing cycle. Module 1 surfaces these residents to Carolyn before each level-of-care review.
Measured separately from labor savings. Does not require Module 2 to be live.
Savings and recovery figures are illustrative ranges based on typical elder care facility benchmarks applied to the Niles building census. Actual results depend on Inspiren export format confirmation, baseline measurement period, and Carolyn’s clinical review cadence. Both lines are calculated against a pre-registered baseline — not reverse-engineered from results.
Build Timeline
Modules overlap intentionally. Module 1 is ECP-only and can launch while Inspiren export format is being confirmed, removing the single biggest dependency risk.
ECP OAuth integration. ADL charting frequency extraction. Billing comparison logic against current care levels. Carolyn’s review workflow. First billing flags surfaced for review.
Acuity scoring model (ECP-first, Inspiren added when format confirmed). DON dashboard. Override workflow. Append-only audit table. Wing-level demand vs. schedule gap detection.
Payroll and Easy Shifts integration. Baseline period measurement registered. ED weekly cost/coverage report. Savings attribution framework initialized.
Carolyn onboarding complete. First full billing review cycle. Executive director reviews first cost/coverage report. Pre-registered success criteria evaluated. Go/no-go for Niles continuation and multi-building plan.
Data Architecture
No new sensors. No new charting requirements. Three existing systems, connected for the first time, into a PostgreSQL data warehouse with role-bound access and HIPAA-compliant data handling.
Integration 1
OAuth 2.0 integration via Tim’s IT team. Daily sync of ADL charting frequencies, care plan task minutes, billed care levels, and resident census. First data source to connect — no external dependency.
Integration 2
Event export integration: resident sensor events and staff beacon entries by wing and shift.
Gate: Export format must be confirmed via Tim’s biweekly Inspiren vendor calls before this integration begins. Module 2 v1 launches on ECP-only data. Inspiren becomes a precision enhancement, not a launch dependency.
Integration 3
API or export integration (format TBD). Reads scheduled staffing by shift and role, actual hours, OT flags, and agency entries. Required for Module 3; Module 1 and 2 can go live independently.
Access model: Role-bound views — DON sees acuity scores and staffing recommendations. Carolyn sees billing flags. Executive director sees labor analytics. Admin sees system configuration. No cross-role data bleed.
HIPAA: All PHI stays within Dockerty’s BAA-covered data plane. BAA required with any cloud vendor before data flows. Audit log is append-only, hash-chained, 7-year retention.
How We Build It
These aren’t values statements. They are architectural decisions encoded into the system from day one.
No recommendation may plausibly degrade resident care. Staffing optimization is always downstream of matching care to need. The model never recommends below the applicable regulatory floor for any configuration.
ECP, Inspiren, and Easy Shifts are the substrate. The system synthesizes what Dockerty already has. No new charting requirements, no new sensors, no new staff behaviors required.
Objective documentation of care delivery vs. billed level is findable in data Tim already owns and is verifiable by Carolyn in under an hour per flagged resident. Module 1 can generate ROI before Module 2 is even built.
A DON who can’t explain why the system recommended 0.7 more aide-hours will ignore it. Every recommendation traces to named residents and named data points. The override mechanism is first-class, not an afterthought.
The sellable artifact is a finance-grade audit trail proving savings occurred — not the model. The attribution methodology is pre-registered before the pilot starts. The trail is built from day 1, not constructed at the end.
Next Steps
Four decisions required before code is written. None of them are complex. Three are data access gates; one is a clinical workflow decision.
Three data connections must clear before code starts:
Carolyn (Director of Clinical Services) must be onboarded as the clinical validator before Module 1 goes live. Her workflow is the final gate on every billing recommendation — no flag reaches anyone else without her review.
Onboarding plan: no more than 5 flagged residents per week in the first two weeks. Frequency increases as confidence in the system builds. Carolyn’s bandwidth is a system constraint, not an afterthought.
Three things pre-registered before build starts:
BAA chain must be established with ECP, Inspiren, and the cloud host before any PHI flows. BAA paperwork should begin in parallel with data access gate work — not after.
Michigan regulatory framework per building should be confirmed with legal/compliance before go-live. Dockerty’s buildings operate under Homes for the Aged and Adult Foster Care licensing; the applicable staffing floors differ from Skilled Nursing Facility requirements and must be encoded correctly in Module 2’s recommendation logic.