The event catalog, the API, and what happens when we fall behind.
Attergo is an event-sourced system with a public canonical model. If you are evaluating whether to build against us, start with the catalog and the failure semantics.
Canonical entities
| Entity | Identified by | Emitted on |
|---|---|---|
| Fill | Tenant, location, internal reference | Data entry, status change, complete, cancel |
| Claim | Fill, payer, sequence | Submit, adjudicate, reverse, remit |
| Encounter | Tenant, patient reference, service date | Document, sign, submit, adjudicate |
| Product | NDC-11 | Inventory receipt, cost update |
| Plan | BIN, PCN, group | First adjudication against the plan |
| Prescriber | NPI | First fill, registry refresh |
| Evidence bundle | Fill | Continuously, as sources arrive |
Guarantees
At-least-once delivery
Consumers must be idempotent. Every event carries a stable id and a monotonic sequence per entity.
Ordering per entity
Global ordering is not guaranteed. Ordering within one fill or claim is.
Replay on request
Any window can be re-emitted from the archive without contacting the source system.
Explicit staleness
Derived figures carry the timestamp of the last event they included. A lagging figure says so.
Connect one store. We will tell you what the month cost you.
Read-only credentials you can revoke. We come back with the fills that went out under cost, the services you could have billed, and the fills an auditor would ask about.