Architecture
Ordinis is built around a simple premise: in clinical operations, the system must be trustworthy by default. That means explicit data boundaries, deterministic accounting, and an offline-first posture that treats network access as optional—not assumed.
1) Ledger truth as a first principle
Financial reality is not a report. It is a sequence of events. Ordinis represents financial movement as a ledger of discrete, timestamped entries rather than as UI-level totals that can drift over time.
A ledger model makes the system easier to audit, easier to reconcile, and harder to lie to—accidentally or otherwise.
- Events are authoritative. Reports are derived.
- Reconciliation is explicit. Adjustments are recorded as events, not silent overwrites.
- Totals are computed. They are never stored as the primary truth.
2) Offline-first, with explicit sync boundaries
Ordinis treats connectivity as a convenience. The working set of data is available locally and remains usable when the network is unavailable, slow, or inconsistent.
Synchronization is a controlled process with clear rules: what syncs, when it syncs, and how conflicts are resolved. The goal is stability—not magical, silent background behavior.
- Local durability: the clinic can operate without an always-on cloud.
- Bounded sync windows: prioritize operationally relevant time ranges.
- Conflict surfaces: where collisions occur, they are exposed for explicit resolution.
3) Deterministic accounting and reporting
“Looks right” is not a standard. Ordinis aims for deterministic outputs from deterministic inputs: the same data produces the same results, every time.
| Area | Approach |
|---|---|
| Reporting | Derived from ledger events with transparent formulas. |
| Adjustments | Recorded as new events rather than overwriting prior truth. |
| Snapshots | Stored only as signed/approved checkpoints when needed. |
The goal is not to avoid complexity. The goal is to contain it and make it observable.
4) Separation of realities: projection vs. record
Ordinis separates what has happened from what might happen. Projections are useful, but they must never contaminate the record.
- The record is composed of signed clinical notes, posted charges, payments, adjustments, and reconciled events.
- The projection is a forward-looking model that can be tuned, rerun, and improved without rewriting history.
This is the operational equivalent of dev/prod discipline: experiment without breaking trust.
5) Explicit boundaries: dev vs. production posture
Ordinis assumes that production data is authoritative and must be treated with care. Development work should be isolated from production environments, with clear guardrails to prevent accidental writes.
- Environment segregation (dev/stage/prod) is treated as a design requirement.
- Migration paths are additive and reversible where possible.
- Auditing is built into data change surfaces.
6) Data model discipline: fewer primitives, more clarity
Systems become fragile when every screen invents its own meaning. Ordinis favors a small number of stable primitives—patients, encounters, charges, payments, adjustments, and ledger events—then derives the rest.
// Conceptual example (illustrative)
// Reports read from events; they do not define truth.
ledger_event {
id
occurred_at
type: "charge_posted" | "payment_received" | "adjustment_applied" | ...
entity_type: "encounter" | "claim" | "statement" | ...
entity_id
amount
metadata
}
The implementation details vary by subsystem, but the posture is consistent: record events, derive meaning, and keep the rules observable.
7) What this architecture is trying to prevent
Most operational pain comes from quiet drift: data that changes without anyone noticing, totals that don't reconcile, systems that only work when the internet behaves, and workflows that optimize for billing throughput while degrading clinical reality.
- Silent overwrites and hidden recalculations
- Report-first accounting that can’t be audited
- Cloud dependency as a single point of failure
- “Magic sync” that hides conflict until it becomes a loss
In plain language
Ordinis is not trying to be loud. It is trying to be correct.
If you are tired of system churn—migrations, UI rewrites, vendor pivots, and “new” features that feel like instability—Ordinis is built to wait. Quietly. Reliably.