Health memory apps are where email was in 1990 — data locked in silos, no portability, no standard. The world needs its IMAP moment for personal health data.
In the early 1990s, email was locked in silos. Your messages lived inside whichever application you used — Lotus Notes, CompuServe, early Outlook. If you switched apps, you left your mail behind. If the company went under, your history was gone. Every system was an island.
Then came IMAP — the Internet Message Access Protocol. A single open standard that separated your mail from any particular application. Suddenly your messages lived in a canonical format, accessible to any client that spoke the protocol. Switch from Outlook to Thunderbird? Your mail came with you. The app became interchangeable. Your data became yours.
Several organizations work on health data interoperability, but none focus on the patient as the primary actor — the person who owns and carries their lifelong health memory.
| Organization | What they do | What's missing |
|---|---|---|
| HL7 / FHIR | Defines the global standard for health data exchange between provider systems (hospitals, EHRs, labs) | Designed for institutions exchanging data, not individuals owning it. No personal health diary model. No encryption or consent standard. |
| CommonWell Health Alliance | Promotes health data sharing between provider networks in the US | Provider-to-provider only. Patient is a passive recipient, not the primary data owner. |
| The Sequoia Project | Health information exchange policy and governance in the US | Policy-focused, US-centric, no standard for personal apps or patient-held records. |
| Apple Health / Google Health | Aggregate health data on your device from wearables and apps | Proprietary. Locked to a platform. No narrative diary model. No open export standard. Apple Health data cannot move to Android. |
| W3C Solid / Inrupt | Personal data pods — you own a URL where your data lives, apps get permission to read/write it | General-purpose, not health-specific. No clinical vocabulary. Technically promising but adoption is near-zero. |
| Patient advocacy groups | Disease-specific communities (e.g. PatientsLikeMe) that help patients share experiences | Siloed by condition. Typically require surrendering your data to a company. Not portable. |
Like IMAP defined six things that made email portable (server protocol, message format, folder structure, authentication, status flags, multi-client sync), a Health Memory Association would standardize six layers:
date, narrative (free text), severity (0–10 numeric), body_location, context (activity, environment). Plus optional structured extensions for vitals, medications, photos, family history. Every compliant app must be able to export and import this model.
.mbox for email. Export from J4H, import into any future HMA-certified app. No data left behind.
| Email (solved) | Health Memory (unsolved) |
|---|---|
| Mail locked in Lotus Notes, AOL, CompuServe — no portability | Diary locked in J4H, Apple Health, Fitbit — no portability |
| Switch email clients, lose your history | Switch health apps, lose your history |
| Provider shuts down, mail gone | App shuts down, health data gone |
| IMAP: standard protocol — mail lives in a canonical format, any client can access it | HMA format: standard schema — health memory lives in a canonical format, any certified app can access it |
| SMTP for sending, IMAP for reading — app-agnostic | FHIR for provider exchange, HMA format for personal archive — app-agnostic |
| S/MIME and PGP for email encryption — open standards | OpenPGP + AES-GCM for health data encryption — already proven |
| You can use Gmail, Outlook, Thunderbird interchangeably — your mail is always there | You should be able to use any certified health memory app — your history is always there |
| Solved in 1996 by RFC 2060 | Not yet solved. No RFC. No association. No standard. The gap waiting to be filled. |
The model already exists in adjacent domains. The Internet Engineering Task Force (IETF) standardizes internet protocols. The World Wide Web Consortium (W3C) standardizes web formats. PCI-DSS certifies payment security. The HMA would follow a similar governance model but focused on a specific domain.
J4H was not designed to implement the HMA standard — the HMA doesn't exist yet. But looking at what J4H already does, it maps remarkably closely to what the standard would require.
| HMA Layer | J4H Today | Status |
|---|---|---|
| 1. Data Model | date, narrative (content), severity (pain_level 0–10), location, patient context | ✓ Core fields present |
| 2. Portability Format | OpenPGP .asc export of JSON entries — importable, readable by any PGP tool forever | ✓ Open format, durable |
| 3. Encryption Standard | AES-256-GCM client-side + OpenPGP .asc export. PBKDF2 key derivation. | ✓ Matches HMA baseline |
| 4. Identity Protocol | Currently a shared passcode (8903) — not a personal cryptographic identity | ⚠ Needs per-user keypair |
| 5. Consent API | FHIR integration exists — structured provider exchange is already the architecture | ⚠ Needs formal consent token model |
| 6. Certification | N/A — the certifying body does not yet exist | — Would certify on day one |
A reference implementation matters for standards adoption. When IETF published IMAP RFC 2060, the University of Washington's c-client library served as the reference implementation that other developers could study and verify their work against. J4H could play that role for the HMA standard — open source, fully documented, and already in production.
IMAP did not make email better. It made email free — free from any single vendor, free to move, free to persist across decades. No one company controls your inbox today because of a decision made in 1996 to publish an open standard.
A Health Memory Association exists to make that same decision for health data. Not to build the best health app. To make the data free.
Your health history belongs to you. It should follow you through every app, every device, every country, every decade — as naturally and reliably as your email does today.