Skip to content

Platform

Modules a customer buys, over services every module builds on.

Three layers, and the distinction between them is what keeps a monolith modular. A business module may depend on a platform service; a platform service may never depend on a business module — and the build fails if one ever does.

Platform services

What every module builds on.

Mandatory and shared. These are the parts a module never has to solve for itself, which is why the modules stay small enough to reason about.

  • Identity and access

    Authorization is decided by a policy engine rather than by permission strings scattered through the code — at the route, at the record and at the list. Clinical detail is its own grant, and a company-wide reader sees the case without seeing the diagnosis.

  • Audit

    Every mutating request, its actor and its outcome, stored per company with a correlation id that ties a user action to every log line it produced.

  • Document management

    Upload, download and delete, anchored to a case, in object storage. Generated documents — guarantees, invoices, statements — go through the same store and the same table as uploaded ones.

  • Domain events

    Modules talk through published facts and never by importing each other. A settlement being confirmed is a fact the claim subscribes to, which is why the claim cannot be told it was paid by anything other than a payment.

  • Scheduler

    Job schedules registered once and run in a dedicated worker, fanned out per company, with a per-company run ledger and a health endpoint. A run is recorded against the period it was for, so a restart cannot lose a schedule and two replicas cannot run one twice.

  • Module registry

    Every business module is switched on or off per company. A company that does not do reimbursements does not see the screens, and does not pay for them.

  • Realtime

    Presence, typing indicators and live message delivery over a persistent connection, so the internal desk conversation behaves like one.

  • Notifications

    In-app notification delivered off the back of a domain event — an assignment notifies the person who received it without the assigning code knowing anything about notifications.

Architecture

Decisions we would defend in a review.

None of this is visible from a demo, and all of it decides what the platform will still be able to do in three years.

The security model in full
  • One database per company

    Not a tenant column — a physically separate Postgres database per customer, created at onboarding. A control-plane catalog knows which companies exist and where their data lives, and holds no business data at all. Every feature query runs against one company's database because there is no other database in scope.

  • A modular monolith, kept modular by a test

    Modules communicate through domain events and published facades. A build fails on a boundary violation, a circular dependency, or a controller that does not declare which module owns it. It is a test rather than a paragraph in a document, because that rule decays the moment it lives only in prose.

  • Money is a decimal, end to end

    Amounts are computed in fixed-precision decimal and formatted once at the edge. No floating point anywhere on a financial path.

  • Durable background work

    Domain events and scheduled work run through a persistent queue in a separate worker process, so a restart in the middle of a payment run loses nothing.

  • Deliberately modest infrastructure

    The platform runs on a single compute instance with no orchestrator until there is a second instance to justify one. The cost of running it is a number, not a mystery, and it is small.

See it against one of your own files.

The fastest way to judge CareTrack is to walk a real case through it — intake, guarantee, charges, adjudication, settlement, statement. Bring one and we will do exactly that.

Or email contact@sthiramtechnologies.com