Docs / Canonical data model
IMPLEMENTED — SOURCE VALIDATION CONTINUES BY VENDOR
⏱️ 2 min read · 319 words
Canonical data model
The canonical model creates a vendor-neutral boundary between source systems and DenialOS workflows.
Minimum objects
- PatientReference
- Encounter
- Provider
- Facility
- Coverage
- Payer
- Authorization
- Claim
- ClaimLine
- Diagnosis
- Procedure
- ClinicalDocument
- Remittance
- Denial
- Outcome.
Not every object has equal source coverage in every connector.
Required lineage
Persisted source-backed canonical objects preserve:
| Attribute | Purpose |
|---|---|
| organization | tenant boundary |
| client | customer/client boundary |
| connection | exact integration source |
| vendor | source vendor |
| source system | upstream system identifier |
| source ID | source record identity |
| source version | source version ordering |
| source hash | payload identity/collision detection |
| observed timestamp | when DenialOS saw it |
| effective timestamp | source-effective time when available |
| provenance | where the record came from |
| authorization context | access basis |
Version semantics
Identical ID/version/hash is idempotent. Same ID/version with a different hash is a collision. Newer versions can supersede prior state; older versions are retained as stale rather than becoming the active record.
Canonical event boundary
After successful canonical persistence, the ingestion path may emit a canonical event for downstream workflow processing. The denial domain consumes canonicalized facts rather than vendor-specific payload structures.