Single Source Of Truth
A single source of truth means one system is treated as the authoritative record for a specific data element, such as a medication list, a lab result, or a consent status. The goal is not to store everything in one database; the goal is to prevent conflicting versions from being treated as equally correct. In health contexts, “truth” also includes timing: when a value was recorded, by whom, and under what clinical or administrative context.
Practical example: a patient portal shows a medication list. If the portal reads from a pharmacy feed, while clinicians edit a separate copy in an EHR note, the two lists can drift. Users then see changes that look real but are actually updates from different pipelines. A single source of truth approach assigns one system as authoritative for each item and defines how other systems should mirror it.
Ownership matters because data has different lifecycles. A lab result has an origin event (specimen collected, analyzed, reported). A care plan has a revision history. A billing code has a different governance model than a clinical note. When teams treat all of these as the same kind of data, they end up with the wrong “truth” in the wrong place.
Main Problems And Pain Points
People often get the “single source” idea backwards. They assume it means one storage location for everything, then they force unrelated data into one schema. That creates brittle workflows and makes audits harder, because the system that stores the data may not match the system that generated it.
Another common failure mode is silent overwrites. A background job syncs data every hour, but it does not track which fields changed or whether the incoming update is newer than the local value. The result is a medication dose that flips back to an older value after a late-arriving feed. This shows up as “it changed again” messages, and it rarely has a clear user-facing explanation.
Dependencies also complicate the picture. Health data often flows through multiple layers: identity management (who the user is), authorization (what they can see), data ingestion (how values arrive), normalization (how formats match), and reporting (how values are queried). If any layer lacks consistent rules, the system that looks authoritative in one report becomes questionable in another.
Supporting technologies include audit logging, versioning, and data lineage. Audit logs record actions, but they do not automatically resolve conflicts. Versioning helps, but only if the system defines a conflict policy. Data lineage tools can show where values came from, yet they do not prevent a downstream system from treating a stale copy as current.
A small aside from implementation work: I have seen teams label a dataset “master” while still allowing edits in two places. In one project, the “master” table had a last_updated timestamp, but the UI wrote to a different table, so the timestamp lied. That mismatch is the kind of detail that breaks trust.
Solutions And Advice
Assign Authority By Data Type
Start by listing the data elements you care about and assign an authoritative owner for each. Medication lists, allergies, diagnoses, lab results, and consent records each have different origins and update rules. For each element, document: the source system that generates it, the update frequency, the allowed edit locations, and the conflict policy when two sources disagree.
Use a simple matrix: rows are data elements, columns are systems (EHR, lab interface, patient portal, billing system, data warehouse). Mark one system as authoritative per element. If you need a warehouse for analytics, treat it as a consumer that refreshes from authoritative sources rather than a place where clinicians “fix” records.
Realistic outcome: teams that define authority per element usually reduce “which list is correct?” tickets. The number varies by organization, but a common target is cutting duplicate reporting discrepancies by half within a few release cycles, because fewer people chase conflicting versions.
Use Versioning And Lineage
Authority needs evidence. Store version metadata alongside values: recorded_at, effective_at, source_system, and actor (user/service account). For clinical values, effective_at matters because a value can be recorded later than it applies. For example, a lab result might be reported after specimen collection, and the “effective” date may affect clinical timelines.
Lineage can be lightweight. A field-level lineage record that says “this value came from feed X, message id Y, ingested at Z” is often enough to debug issues. Many teams use ETL tools and message brokers that already track identifiers; in one setup using Apache Kafka, the message key and offset helped trace duplicates during a sync incident (Kafka version 3.6.x in that case).
Conflict policy should be explicit. Common policies include “newer effective_at wins,” “authoritative system overwrites non-authoritative copies,” or “manual review for mismatched fields.” Automated overwrites without a policy create the appearance of correctness while hiding data drift.
Design Sync With Guardrails
Mirroring data to other systems should be read-only for authoritative fields. If a downstream system must display editable fields, separate the editable draft from the authoritative record. Then promote changes through a controlled workflow that writes back to the authoritative system.
Guardrails include idempotency keys (so retries do not create duplicates), schema validation (so malformed data does not overwrite good data), and rate limits (so a feed outage does not flood the system with stale retries). A practical metric is “time-to-consistency”: how long after an authoritative update the mirrored systems reflect the change. Many organizations aim for minutes to hours depending on the data type, rather than assuming instant propagation.
One mild frustration I have heard repeatedly: teams set sync jobs to run every 5 minutes, then discover the feed sometimes arrives late. Without effective_at handling, the job “corrects” the record back to an older state. The fix is not faster syncing; the fix is correct ordering and conflict rules.
Audit Access And Retention
Single source of truth also includes who can read and who can write. Use role-based access control and enforce it at the data layer, not only in the UI. For health data, audit logs should capture read access as well as write access when required by policy, because “who saw what” matters for compliance and incident response.
Retention rules vary by jurisdiction and data type. In the United States, HIPAA requires safeguards for protected health information, and state laws may add requirements. For general data governance, define retention windows for raw ingested feeds versus normalized records. Raw feeds can be useful for debugging, but they may carry more sensitive content than the normalized model.
Outcome target: audit trails should support a complete reconstruction of “what changed, when, and from where” for a specific record within a reasonable investigation window. Many teams measure this by running tabletop exercises during onboarding of new systems.
Case Examples
Medication List Drift
A clinic uses an EHR as the authoritative source for medications. The patient portal also shows medications and receives updates from a pharmacy integration. During a weekend, the pharmacy feed sends an update with an older effective date for one drug. The portal sync job overwrites the portal’s copy using ingestion time rather than effective_at, so the displayed dose reverts for two days.
The clinic resolves the issue by adding a conflict policy: portal mirrors only when incoming effective_at is newer than the stored effective_at. They also mark the portal medication view as read-only for authoritative fields and route edits through the EHR workflow. After the change, the portal still updates quickly, but it stops “undoing” newer clinical entries.
Consent Status Conflicts
A health plan shares consent status with a third-party analytics vendor. The consent record is stored in a consent management system, while a data warehouse stores a derived “marketing eligibility” flag. A reporting dashboard shows inconsistent eligibility counts because the warehouse refresh runs nightly, while the consent system updates in real time.
The team assigns authority for consent status to the consent management system and treats the warehouse flag as a derived dataset with a clear refresh timestamp. They update the dashboard to display “as of” time and to filter out records older than the last refresh. The counts become consistent with the consent system, and the discrepancy becomes a known lag rather than a mystery.
Comparison Table Or Checklist
Use this checklist to decide where data should live and what should be authoritative.
| Decision Point | Good Sign | Risk If Wrong | What To Do Next |
|---|---|---|---|
| Authority assignment | One system owns each data element | Conflicting values treated as equal | Create an authority matrix per element |
| Update ordering | effective_at drives conflict resolution | Late feeds overwrite newer facts | Add effective_at checks and idempotency |
| Lineage | Source ids and ingestion metadata stored | Hard-to-debug “why did it change?” | Record source_system, message id, and timestamps |
| Access governance | Write access restricted to authority | Unauthorized edits create silent drift | Enforce RBAC at the data layer and audit reads/writes |
| Derived datasets | Dashboards show “as of” refresh time | Users assume real-time accuracy | Label lag and filter by freshness windows |
Common Mistakes
One mistake is treating “single source of truth” as a branding phrase rather than a governance model. If multiple teams can edit the same fields in different systems, the organization has multiple truths, even if one system is labeled “master.”
Another mistake is ignoring derived data. A data warehouse can be accurate for analytics while still being wrong for clinical decisions if it refreshes late or applies transformations that change meaning. Derived flags need documentation for definitions, refresh cadence, and known lag.
Teams also underestimate the role of identifiers. When systems use different patient identifiers or drug codes, merges fail quietly. The result looks like missing records or duplicate entries, and the “truth” becomes a guess. Using consistent identifiers and validating joins during ingestion reduces this risk.
Finally, some organizations skip conflict testing. A staging environment with perfect timing hides late-arrival problems. Testing should include out-of-order events, duplicate messages, and partial feed failures. In one incident review dated 2024-11, the root cause was a retry mechanism that re-sent the same payload after a network glitch, and the sync job lacked idempotency checks.
FAQ
What Counts As A Single Source?
A single source is the authoritative record for a specific data element, not necessarily one database for everything. Authority depends on origin, edit permissions, and conflict rules.
Should The Data Warehouse Be Authoritative?
Often the warehouse is a consumer for analytics, while the authoritative record stays in the operational system that generates the data. If the warehouse is authoritative, it must support write workflows, audit trails, and conflict resolution.
How Do We Handle Conflicting Updates?
Define a conflict policy using effective_at and source priority, then enforce it during sync. Store version metadata so you can explain which update won and why.
What Metadata Makes “Truth” Auditable?
Use recorded_at, effective_at, source_system, actor, and identifiers for the originating event or message. These fields support debugging and compliance investigations.
How Long Can Mirrored Data Lag?
Lag depends on data type and risk tolerance. Dashboards should show an “as of” timestamp, and workflows that require current values should read from the authoritative system or use freshness thresholds.
Author's Insight
Single source of truth is a governance pattern, not a storage choice. The most reliable designs assign authority per data element, attach version metadata, and enforce conflict policies during synchronization. When teams treat derived datasets as if they were authoritative, users lose trust because “correctness” becomes time-dependent. Evidence-based practice focuses on auditability, lineage, and test cases for late-arrival and duplicate events, since these are common real failure modes.
Key Takeaways
- Assign authority per data element, then restrict write access to the authoritative system for those fields.
- Use effective_at-driven conflict resolution and store version metadata for audit and debugging.
- Mirror data with guardrails like idempotency and schema validation, and label derived data with refresh “as of” times.
- Test out-of-order events and duplicates in staging so late feeds do not overwrite newer facts.
