• 

  AI turns fragmented health chats into a clear clinical timeline, helping patients and clinicians make better-informed decisions.

Context for care

Team name: Context for care
Track: Agents
Lane: Concept

Short summary

Context for care enables patients to share selected health-related AI conversations with a clinician through AI Passport. It transforms fragmented chats into a concise, chronological and source-labelled packet containing symptoms, dates, actions tried, relevant previous context and the responses provided by AI.

The patient reviews every item and decides exactly what to share, with whom, for what purpose and for how long. The clinician receives useful context without gaining access to the patient’s complete AI history. Patient-reported information and AI-generated content remain clearly separated.

What inspired me

As a political adviser working in healthcare, I have seen how important the electronic health record is for continuity of care. However, even a comprehensive clinical record depends on the quality of the information initially communicated by the patient.

Describing symptoms accurately is difficult. People may forget when a symptom started, how it changed, what other symptoms appeared first or what actions they already tried. These details are particularly hard to reconstruct during a short and stressful medical appointment.

At the same time, many people now discuss health concerns with AI before visiting a doctor. These conversations can contain a valuable chronology of symptoms and questions, but they remain fragmented across different applications and outside the clinical workflow.

This inspired me to explore whether AI Passport could help patients bring that context into an appointment without treating AI as a doctor or exposing their complete conversation history.

The problem

Patients may describe the same health issue to an AI assistant several times before seeking professional care. Across those conversations, they may document:

• When symptoms began.
• How symptoms changed over time.
• Their frequency, severity or location.
• Medicines or self-care measures they tried.
• Previous conditions or events they consider relevant.
• Questions and concerns they want to discuss with a doctor.
• Suggestions previously generated by AI.

During an appointment, the patient may struggle to remember this chronology. Showing screenshots or scrolling through complete chats is inefficient and can reveal unrelated or highly sensitive information.

Clinicians, meanwhile, need concise and trustworthy context. They must be able to distinguish between what the patient reported and what an AI system generated. Without that distinction, AI suggestions could be misinterpreted as clinical findings or influence the consultation disproportionately.

User or group affected

The primary user is an adult patient who has asked one or more AI assistants health-related questions before a planned outpatient consultation.

The recipient is a named clinician or an authorised clinic intake process acting on that clinician’s behalf. The concept could be particularly valuable for people with recurring, intermittent or difficult-to-describe symptoms, where chronology is clinically relevant.

The first version deliberately excludes emergency care, paediatrics, autonomous triage, insurers and employers.

How AI Passport is used

AI Passport acts as the consent, context and provenance layer between the patient’s AI conversations and the clinical appointment.

The proposed experience is:

1. Select: I choose the health-related conversations or individual messages that may be relevant.

2. Structure: AI Passport proposes a chronological packet containing symptoms, dates, actions tried, AI-generated suggestions and open questions.

3. Review: I correct dates, remove irrelevant information and decide whether to include context from earlier chats.

4. Approve: I authorise a named clinician or clinic to access specific fields for a defined healthcare purpose.

5. Share: The clinician receives a concise, symptoms-first view rather than access to my complete AI account.

6. Audit: Each access creates a receipt, and the authorisation expires automatically or can be revoked.

This process turns fragmented conversations into a patient-reviewed clinical communication tool.

Context, permission, proof and access

The proposal combines four functions of AI Passport.

Context

The shared packet may contain selected symptom descriptions, a chronological timeline, actions already tried, relevant previous-chat information and questions for the appointment.

AI-generated suggestions are placed in a separate section so they cannot be confused with patient-reported symptoms or professional medical conclusions.

Permission

Permission defines:

• The named recipient.
• The purpose of access.
• The approved categories of information.
• The conversations or dates covered.
• Whether raw excerpts are included.
• Whether sensitive categories are included.
• The duration and expiry of access.

Proof

AI Passport provides evidence of provenance, integrity, consent and scope. It can show where an item originated, when it was recorded, whether the patient edited it and which version was approved.

This proof does not establish that a symptom is clinically correct or that an AI response is medically reliable.

Access

Access is read-only, purpose-bound and time-limited. The clinician receives the approved packet, not permanent access to the patient’s AI accounts or future conversations.

Requests outside the authorised scope return no information and require new patient consent.

Who controls access

The patient remains the Passport holder and the final decision-maker.

The clinic may request specific information, but it cannot silently expand the request. The patient sees the recipient, purpose, fields and expiry before approving access.

This control is essential because AI conversations may include mental-health information, family circumstances, sexual health, financial concerns or other content unrelated to the consultation.

What can be changed or revoked

Before sharing, the patient can:

• Correct dates or descriptions.
• Remove individual items.
• Add relevant information from earlier chats.
• Exclude raw conversation excerpts.
• Hide AI-generated suggestions.
• Change the recipient, purpose or expiry.
• Reject sensitive categories.
• Cancel the process entirely.

After sharing, the patient can revoke future Passport access or allow the pass to expire automatically.

Revocation cannot guarantee the deletion of information that a healthcare provider has already lawfully retained. This limitation must be communicated clearly so that patients do not develop a false expectation of complete erasure.

How I developed the concept

I designed the first version around a planned outpatient appointment because it provides a realistic and controlled use case.

The proposed prototype contains seven stages:

1. Conversation selection.
2. Extraction of candidate information.
3. Patient review and correction.
4. Selection of relevant earlier context.
5. Preview of the exact packet.
6. Consent and access configuration.
7. Clinician view, receipt and revocation controls.

The clinician view prioritises the patient’s concern and symptom timeline. AI-generated suggestions appear later, remain clearly labelled and can be collapsed by default.

The concept does not require direct electronic health record integration for its first version. A one-time clinical web viewer would allow the permission and provenance model to be tested before considering more complex integrations.

What I learned

Developing the proposal reinforced my view that better healthcare information does not simply mean collecting more data. Information must be relevant, understandable, chronological and appropriately governed.

I also learned that provenance is especially important in healthcare. A clinician needs to know whether an item was reported by the patient, generated by AI, edited during review or imported from another source.

AI Passport is therefore most valuable here not as a medical authority, but as infrastructure for controlled disclosure. It helps answer four practical questions:

• Where did this information come from?
• What did the patient approve?
• Who is allowed to access it?
• For how long is that access valid?

Challenges and risks

The main challenge was balancing clinical usefulness with privacy and safety.

Important risks include:

• Exposure of sensitive or unrelated information.
• AI-generated text being treated as clinical fact.
• Clinician anchoring on an AI explanation.
• An incomplete packet being mistaken for a complete medical history.
• Unsafe AI advice appearing to receive official endorsement.
• Reuse of health information for unrelated purposes.
• Patients misunderstanding what revocation can achieve.
• Use of the tool in emergencies instead of seeking immediate care.

The design responds with item-level approval, short-lived read-only access, persistent source labels, a symptoms-first hierarchy, separate AI-generated content, visible coverage dates, access receipts and no automatic writing to the electronic health record.

Any real pilot would require clinical-safety oversight, security testing, privacy review and jurisdiction-specific legal assessment.

Vision

My goal is not to allow AI to diagnose patients or replace clinical judgement. It is to help people document their symptoms more accurately and communicate their chronology more effectively.

Context for care gives patients a controlled bridge between the health conversations they already have with AI and the medical professionals responsible for their care.

The result is better context for the clinician, greater control for the patient and a clearer boundary between personal reporting, AI-generated information and professional medical assessment.

Built With

• chatgpt