Oktopeak
Home / Case Studies / Senior Living Placement

[ HEALTHCARE ]

[ AUDIT TRAIL ]

Senior Living Placement
Case Lifecycle Platform

A full-stack case lifecycle system for senior living placement coordinators. Residents are tracked from their source facility into Assisted Living or Independent Living, with every status change enforced by the server and recorded in an audit event.

STATUS Delivered
PLACEMENT TYPES AL + IL
STACK Node.js + PostgreSQL
Placement Coordinator · Case List
Placement coordinator case list showing demo cases with lifecycle status, priority, and days open

7

Lifecycle states, enforced server-side

5

Touchpoint types logged (call, text, email, tour, document)

14 days

Aging threshold for stale-case alerts

0

Ways to edit or delete a logged touchpoint

[ THE CHALLENGE ]

Placement ran without
a lifecycle

A senior living placement operator was moving residents through their pipeline with nothing enforcing the sequence and nothing recording who changed what.

No enforced workflow

Cases moved between statuses without validation or guardrails. Nothing stopped a case from skipping the stages in between.

Scattered touchpoints

Calls, emails, tours, and documents lived across separate systems. Reconstructing what was said to a family meant checking several places.

No audit trail for status changes

Once a case moved, there was no record of who moved it or why. Tracing a placement decision after the fact was impossible.

No visibility into aging cases

Residents sat in the pipeline with no alert. Nobody knew which stage was the bottleneck until someone went looking.

Manual reporting

Case distribution, bottleneck stages, and stale cases were compiled by hand instead of read off the system.

Compliance risk

Healthcare placement requires traceable decision history. Without one, the operator was carrying that exposure on every case.

[ THE SOLUTION ]

One lifecycle, enforced by the server

We built the placement pipeline as a state machine that lives in one place on the server, a communication log that can only be appended to, and a metrics layer that reads case age off the record instead of off a spreadsheet.

Case Detail · Status
Case detail view showing the current lifecycle status, the next allowed transition, and a blocked-transition error for a demo case
A case cannot skip or jump states — invalid transitions return a clear error (demo data).

01

State machine enforcement

A case cannot skip or jump states. The transition map is defined once, server-side, and checked on every status change.

  • Transition logic in one location, not duplicated across layers
  • Invalid transitions return a clear error response
  • Terminal states cannot transition further
  • Every accepted transition writes an audit event
Case Detail · Communication Log
Append-only touchpoint timeline for a demo case, showing calls, texts, emails, and tours logged in order
Every touchpoint is written once and kept — no edit path, no delete path (demo data).

02

Append-only communication log

Every touchpoint with a resident or family is written once and kept. Nothing in the history can be rewritten later.

  • Calls, texts, emails, tours, and documents in one timeline
  • Immutable once created, no edit and no delete path
  • Timestamped and attached to the case
  • Full history visible on the case detail view
Reports · Aging & Distribution
Aging-aware reporting dashboard showing demo case distribution by stage, average case age, and a stale-case alert list
Case distribution, average age, and the stale-case alert list, read live off the data (demo data).

03

Aging-aware reporting

Case distribution, bottleneck stages, and stale cases are read live off the data instead of assembled by hand.

  • Case counts per lifecycle stage
  • Average age across open cases
  • Alert list for open cases older than 14 days
  • Filter by status, priority, and target type; search by resident

[ SEE IT WORK ]

A case, start to finish

One flow, one recording: a case comes in, moves through review to placement, and the audit trail shows exactly who moved it and why.

Coming soon

Case lifecycle walkthrough

Intake → review → placement, with every transition and touchpoint recorded. Full video in progress.

[ THE LIFECYCLE ]

From intake to placement, in order

Seven states, one legal path between each pair. A case that has not had options sent cannot have a tour scheduled, and a placed case cannot be reopened by a status edit.

NEW

Case created with resident, source facility, target type (AL or IL), and priority. Moves to review only.

IN_REVIEW

Coordinator assesses fit. From here the case can be waitlisted, sent options, or closed as lost.

WAITLISTED

No capacity at the target yet. The case can still move to options sent or be closed as lost.

OPTIONS_SENT

Communities presented to the family. Next legal step is a scheduled tour, or closed as lost.

TOUR_SCHEDULED

Tour booked at a target community. Resolves to placed or closed as lost.

PLACED

Resident moved into the community. Terminal state, no further transitions accepted.

CLOSED_LOST

Case ended without a placement. Terminal state, and the reason is on the audit record.

AGING WATCH

Any open case past 14 days surfaces in the alert list, whichever stage it is sitting in.

[ TRACEABILITY ]

Who moved the case,
and why

Healthcare placement needs a defensible decision history. Every status change on this system writes a structured audit event, so the record of a resident's path exists whether or not anyone thought to write it down.

These are the same patterns behind a records system for a care setting. If you need software like this, built for your care setting, that work lives under custom EHR development, and the wider vertical is on our healthcare page.

Structured audit events

Each status change records from status, to status, who changed it, and the stated reason, as structured JSON attached to the case.

Auto-generated, not optional

The audit event is written by the transition itself. A coordinator cannot move a case and skip the record.

Immutable touchpoints

The communication history is append-only, so the record of what was said to a family cannot be revised after the fact.

Honest case age

Open case age is measured from creation, closed case age from closure. Unrelated edits do not make a stale case look fresh.

Full history on one view

The case detail view returns the case with its touchpoints and its audit events together, so the whole path reads in one place.

Tested behavior

Tests assert that invalid transitions are rejected, that valid ones write the right audit metadata, and that the aging math is correct.

[ TECH STACK ]

Node.jsExpress / FastifyPostgreSQLReactREST APIServer-side state machine

[ DELIVERED ]

What the operator got

Capabilities in the delivered system, described as built. This is the closest thing we have shipped to a records system for a care setting: lifecycle, audit trail, and compliance-grade traceability around a resident.

Enforced

Case lifecycle

A case can only follow a legal path through the pipeline. Skipping stages returns an error instead of a silent status write.

Append-only

Communication history

Calls, texts, emails, tours, and documents recorded against the case and kept as written. No edit path, no delete path.

Traceable

Every status change

Structured audit events carry from status, to status, who changed it, and why, generated automatically by the transition.

Live

Metrics and alerts

Case distribution per stage, average age of open cases, and a standing list of anything open past the aging threshold.

★★★★★

“Everything was done professionally, with efficient and fast communication, unconditional availability, kindness and professionalism.”

Goran Dojčinović

Lawyer, Dojčinović Law Office

Client review · related engagement · Verified review · Clutch, 5.0

[ FAQ ]

Senior Living Placement — frequently asked

This platform's lifecycle engine, audit trail, and reporting layer were delivered as a focused build. Timeline depends on scope — a narrower first release (one facility type, fewer touchpoint types) moves faster than the full system described here.
It depends on scope, so there's no fixed number here — every engagement is priced per operator after we understand the pipeline and reporting needs. Scoped and quoted before any work starts.
Role-based access, a server-enforced state machine so status can't be edited outside the defined transitions, and an append-only audit log of every change. Security and traceability were constraints from the first sprint, not added later.
You do — full source, no licensing fees, no vendor lock-in.
Yes. This build covers AL and IL placement with a 7-state lifecycle, but plenty of engagements start with one placement type or a shorter pipeline and expand once it's proven out.

Still have questions?

Talk with a friendly expert

[ MORE CASE STUDIES ]

See what else we've built

View all case studies

[ GET STARTED ]

Running placements, residents, or care records on spreadsheets?

We build lifecycle systems for care settings: enforced workflow, immutable history, and an audit trail that holds up when someone asks how a decision was made.

Talk with a friendly expert