Skip to content

Healthcare SaaS · Case study

Turning 245D compliance from a paper chase into a system

MyCareTrail helps Minnesota 245D home and community-based service providers run client intake, staff compliance, and signed documentation in one place, instead of paper files, spreadsheets, and calendar reminders.

MyCareTrail landing page: the operating system for 245D home care providers, with a client-intake timeline.
Industry
Healthcare SaaS · Minnesota 245D HCBS
Engagement
End-to-end product: architecture, build, delivery
Platform
.NET 10 modular monolith · Next.js · Flutter mobile
Status
Live in production

The problem

Licensed 245D providers serve people with disabilities and older adults, and every client and worker comes with a calendar of deadlines: 24-hour, 72-hour, 30-day, 90-day, six-month and annual requirements. Most small and mid-size agencies tracked all of it with paper files, shared drives, spreadsheets and sticky notes.

That approach carries real risk. A missed deadline can mean audit findings, corrective action plans, or worse, and the admin hours spent chasing documents grow with every client an agency takes on.

What we built

  • Client intake with a 245D compliance checklist and a timeline that tracks each deadline by support level.
  • Worker compliance: background-study gating, training and orientation deadlines, and a built-in course library whose completions count toward a worker's requirements.
  • 245D forms that are filled in on screen, generated as PDFs, signed in the app, and filed to the client's record.
  • AI-assisted intake that reads a county support plan or service authorization letter, extracts every authorized service, and drafts the client profile for staff to review.
  • A one-click export of a client's complete record for audits, organized by requirement.
  • Self-service sign-up for agencies, subscription billing, and a companion iOS and Android app.

Architecture decisions

MyCareTrail is a modular monolith on .NET 10: identity, care operations, documents, billing, notifications and messaging are separate modules with their own data contexts, talking only through shared contracts. It deploys as one service, which keeps operations simple for a young product, while the boundaries are already in place if a module ever needs to stand alone.

Every agency's data is isolated at the data layer, not just in the UI. Each query is scoped to its agency automatically, every save is checked against the agency that owns the record, and staff below admin level only see the clients assigned to them. When a check can't confirm access, it denies it.

Cross-agency access isn't prevented by a screen hiding a button. The data layer refuses the query.

Signed documents carry a certificate whose private key lives in Azure Key Vault and never leaves it. Agencies accept a Business Associate Agreement when they register, and AI features that touch client information can be switched off per environment until the right agreements are in place.

Shipping safely

The product runs on Azure, with the API on App Service, Azure SQL, Blob Storage and Key Vault. Releases go out through GitHub Actions and only deploy when the automated test suite passes; production swaps in behind a health check. The tests are deliberately focused on the rules that are expensive to get wrong: document generation and signing, permission and status handling, and database migrations.

What's next

With intake, staff compliance and documentation live, the roadmap turns to Medicaid billing: submitting claims through MN-ITS from the same records providers already keep, so the work that's documented is the work that gets paid.

Have a project like this?

We help teams architect, build, and ship software that keeps running. Let's talk about what you're building.

Start a conversation