Paper 019: Health Context Tokens — A User-Controlled Model for Selective Health Context Sharing

Health data exchange has made significant progress in recent decades. FHIR provides a standardized structure for representing clinical information. Modern APIs enable secure transport between systems. The Model Context Protocol, an emerging standard for AI agent communication, defines how systems request and receive data from external sources.

These standards answer the question of how data moves. They do not, in their current form, answer the question of who controls what moves.

The individual whose data is being shared — the patient, the traveler, the person managing a chronic condition across multiple countries — is assumed to be the subject of the data, not the controller of it. The architecture of interoperability grants access to records. It does not grant the individual the ability to decide what context is relevant to a specific interaction, assemble only that context, and authorize its release for a limited purpose and duration.

Selective sharing mechanisms exist. FHIR Bundles can be filtered. OAuth scopes can limit access. Patient portals allow users to download portions of their records. But these mechanisms are typically institution-facing, designed to help providers share data with other providers. They do not, in general, give the individual a single, coherent abstraction for controlling what is shared, with whom, for what purpose, and for how long.

This paper proposes such an abstraction: Health Context Tokens.

Terminology note: In this paper, "token" refers to a purpose-bound representation of health context. It is a conceptual abstraction and does not prescribe a specific cryptographic or serialization format. We use the term to describe the function of the object — a limited, intentional, user-controlled package of context — rather than any particular technical implementation. This distinguishes our usage from OAuth access tokens, JWTs, cryptographic tokens, or blockchain tokens. We recognize the potential for confusion and aim to be explicit throughout.

A Health Context Token is a purpose-bound, user-authorized, time-limited representation of health context. It is assembled at the moment of sharing from the user's complete health data, which remains on their device.

A Health Context Token is defined by five principles:

• Purpose-specific. The token contains only the information relevant to the interaction at hand.
• User-authorized. The token is created and released only with the explicit consent of the individual whose data it contains.
• Time-limited. The token is valid only for the duration of the interaction or a user-defined window. It expires automatically.
• Auditable. The user can review what was shared, with whom, and when.
• Assembled, not stored. Tokens are not pre-existing records. They are created at the moment of sharing from the user's local data.

The fifth principle — that tokens are assembled, not stored — is the most important architectural distinction between Health Context Tokens and conventional selective sharing approaches. FHIR Bundles and patient portal exports are typically pre-configured by the institution. Health Context Tokens are assembled by the user at the moment of need. This distinction is discussed further in Section 3.

A critical architectural property of the Health Context Token model is that tokens are not pre-stored. They are assembled at the moment of sharing.

The user's complete health data remains on their device in its original form. When a sharing event occurs — a doctor's visit, a border crossing, an emergency room admission — the user selects the relevant context, the application assembles it into a token, and the token is released.

This process, which we call Context Assembly, has several implications. It means the user's data is never pre-packaged for sharing without their knowledge. It means the token can be adapted to the specific requirements of each interaction, rather than relying on a one-size-fits-all export. It means the user reviews what will be shared at the moment of sharing, when the context is fresh and the purpose is clear.

We recognize that existing mechanisms — filtered FHIR Bundles, SMART on FHIR scopes, patient portal downloads — provide forms of selective sharing. The distinction we are proposing is not that selective sharing is new. It is that Health Context Tokens combine purpose, authorization, expiration, audit, and assembly into a single user-controlled abstraction, rather than distributing these functions across multiple institution-facing mechanisms.

We propose four initial token types, each designed for a distinct use case. These are templates, not fixed schemas. The user can modify what each token contains.

Travel Token. Contains vaccinations, active medications, insurance information, emergency contacts, and relevant allergies. Designed for customs declarations, travel clinic visits, and medical consultations abroad.

Emergency Token. Contains allergies, chronic conditions, blood type, current medications, and emergency contacts. Designed for emergency rooms, ambulance handoffs, and situations where the individual may be unconscious or unable to communicate.

Specialist Token. Contains relevant lab results, imaging reports, current treatment plan, active symptoms, and referring physician notes. Designed for consultations with new specialists who need clinical context without the full medical history.

Clinical Trial Token. Contains eligibility-related information only — diagnosis, age, relevant biomarkers, treatment history. Designed for trial enrollment inquiries where the individual wants to share enough to determine eligibility without exposing their full record.

Templates provide a starting point. The individual retains final control.

The Handshake is the mechanism by which a user authorizes the creation and release of a Health Context Token. It is not merely a confirmation dialog. It includes recipient identity, the purpose of the request, the token's expiration, and an audit record of what was shared, with whom, and when.

A detailed technical specification of the Handshake protocol is provided in Paper 020.

Health Context Tokens are proposed as a complementary abstraction to existing interoperability standards. They do not replace FHIR, APIs, or MCP. They occupy a different position in the stack.

FHIR defines the data structure. APIs define the transport. MCP defines the communication protocol between AI agents and external systems. Health Context Tokens define the user-controlled assembly and authorization layer.

These layers are designed to work together. A Health Context Token could be structured using FHIR-compatible formats. It could be transported via standard APIs. It could be requested by an AI agent using MCP. The token model adds a layer of user control that existing standards do not, in their current form, directly address: a single abstraction that combines purpose, authorization, expiration, audit, and assembly under the user's control.

An initial implementation of Health Context Tokens is in development within the Zkomi application. The application stores all user health data locally on the device. No health data is transmitted to any server. The user holds the only copy of their complete medical history.

The token assembly and Handshake authorization flows are functional in prototype form. The implementation is ongoing.

Device recovery and data persistence: The current prototype stores data locally on a single device. This has a known limitation: if the device is lost, fails, or is upgraded, the user's health data may be lost. We are actively exploring encrypted backup mechanisms that would allow users to securely transfer their data between devices without introducing server-side storage or compromising the zero-knowledge properties of the system. This is an open engineering challenge and an area where we welcome collaboration.

We welcome feedback from researchers and developers who wish to examine, critique, or build upon this work.

This paper proposes a model. It does not claim to have solved all the challenges of user-controlled health data exchange. Several questions remain open.

How should token templates be standardized across different applications and platforms? What is the appropriate mechanism for revoking a token after it has been released? How should tokens be verified by recipients with no prior relationship to the user? Can token authorization be delegated to a trusted agent without compromising the user's control? What is the optimal balance between template defaults and user customization?

We do not have definitive answers. We invite collaboration.

Health Context Tokens are a proposal for a user-controlled abstraction that complements existing interoperability standards. They are purpose-bound, user-authorized, time-limited, auditable, and assembled at the moment of sharing rather than stored as pre-existing records.

This is a model, not a finished system. We invite critique, collaboration, and further development.

Published: July 2026
Archived: Internet Archive
Repository: GitHub
Hash: [SHA-256 — upon final publication]

Key Sources:

• HL7 FHIR. (2026). Fast Healthcare Interoperability Resources.
• Anthropic. (2025). Model Context Protocol.
• Zkomi Research Team. (2026). Paper 004: The Zero-Knowledge Architecture. The Continuity Project.
• Zkomi Research Team. (2026). Paper 016: Memory Without Custody. The Continuity Project.