Longitudinal record v2
Give every mera.health patient a single, deduplicated, always-current clinical history — regardless of how many providers or labs have contributed records.
Every patient using mera.health today has fragmented medical records: one app shows labs from one provider, another holds notes from a different one, and the patient themselves often can’t remember what was prescribed six months ago. Longitudinal record v2 fixes this by merging every connected data source into one coherent, FHIR-normalized timeline that both patients and their care team can trust.
The v1 record model stored raw documents without deduplication or normalization. It became unmanageable when patients connected multiple sources for the same condition: identical lab results appeared three times, medication lists diverged, and clinicians stopped trusting the data. V2 is a ground-up replacement.
Problem
Patients connect an average of 2.3 data sources at signup. By month three that number rises to 3.8. Without deduplication, the same lab result or medication entry appears multiple times across different source views. Clinicians reviewing the record waste time reconciling duplicates, and patients feel confused when they see conflicting values for the same test.
The current system has no concept of a canonical patient record. Each data source writes independently; there is no merge layer. The result is a collection of silos wearing a single UI.
Goals
- Single canonical timeline. One merged, chronologically ordered view of all clinical events — observations, medications, encounters, documents — regardless of source.
- Automatic deduplication. Records from different connectors that describe the same clinical event are detected and collapsed, retaining the most recent version.
- FHIR R4 normalization. Every stored record conforms to a validated FHIR R4 profile, enabling interoperability with downstream tools and future export flows.
- Provenance preserved. The merge does not discard origin information. Every record knows which connector produced it and when it was ingested.
- Near-real-time freshness. New records from connected sources appear in the patient timeline within 60 seconds of the connector event being received.
Non-goals
- Clinical decision support. This PRD is about storing and presenting records — not interpreting them. Alerts, risk scores, and care gap detection are out of scope.
- Patient-authored records. Patients manually entering data (symptoms, mood, weight) use a separate write path. V2 does not touch that path.
- Billing or claims data. Insurance claims and EOBs are a different record class. They may be unified in a future initiative.
- Multi-patient merge. Family accounts and caregiver views are not in scope for v2.
Success metrics
| Metric | Baseline (v1) | Target (v2) |
|---|---|---|
| Duplicate record rate (same patient, same event) | 34% | < 2% |
| Records visible within 60s of ingestion | 61% | > 95% |
| Clinician trust score (internal NPS) | 38 | > 70 |
| Time to reconcile a medication list (care team) | 8 min | < 2 min |
| FHIR conformance validation pass rate | n/a | 100% |
A 6-week pilot with 200 patients and two EHR connectors hit a 1.4% duplicate rate and 97% within-60s freshness. The architecture described in the record ingestion doc is the approach being scaled.
Key product decisions
Deduplication is automatic, not manual. Patients and clinicians do not review merge candidates. The system makes the call based on a fingerprint (resource type + clinical code + effective date window). This trades a small risk of incorrect merges for a dramatically simpler UX — and the audit log always preserves the raw inputs.
The patient sees the canonical view; connectors are a detail. The UI surfaces one medication list, one lab history, one encounter list. Source attribution is available on drill-down but is not the primary organizing principle.
FHIR R4 is the internal canonical format. This is a forward-looking bet: as patients gain rights to export their records (21st Century Cures Act), having FHIR R4 as the native format eliminates a translation layer at export time.
Open questions
- What is the right duplicate-window for lab results with sub-minute timestamps from the same lab system? The current 24h window may be too loose.
- Should the UI show a “last synced from X” indicator per connector, or is that too much noise for patients?
See the 2026 records roadmap for the delivery phasing and the record ingestion architecture for the technical implementation.