carebridge-concept

Inspiration

CareBridge was inspired by a real experience during a long holiday when a family member suddenly became ill.

Finding a hospital that could accept us was difficult enough, but the hardest part came afterward. I had to explain the same situation repeatedly over voice-only phone calls, write down phone numbers and instructions while listening, contact hospitals one by one, and then repeat everything again to family members who were not there.

Japan already has valuable telephone consultation services such as #8000 and #7119. One experience that particularly stayed with me was that, after speaking with one of these services, I forgot to tell the hospital that I had been referred through it. As a result, the conversation did not go as expected, and I had to start explaining everything again. That moment made me realize how fragile the communication process can be.

CareBridge is not intended to replace services like #8000 or #7119.

Instead, I wanted to explore everything that happens before and after those calls.

• How can we avoid repeating the same explanation over and over?
• How can we share video only when it is actually helpful?
• How can callers, family members, coordinators, and healthcare providers work from the same confirmed information?

Through this experience, I realized that the real burden was not simply finding information—it was having to recreate and repeat the same information throughout the entire care journey.

What it does

CareBridge uses GPT-5.6 as a communication assistant, not as a medical decision-maker.

Users describe the situation in Japanese or English by typing or using browser-based speech recognition. GPT-5.6 organizes only what the user actually said into an editable, structured Care Brief.

Before anything is shared, every generated field can be reviewed, edited, and confirmed by the user.

Once confirmed, the Care Brief is synchronized between the caller, the coordinator, and family members so everyone works from the same information.

The prototype demonstrates a consultation workflow where:

• the caller shares video and audio
• the coordinator receives video and joins by voice
• family members join by voice while viewing the same synchronized information

The demo also simulates selecting a destination from twenty fictional hospitals and synchronizes the proposed hospital and acceptance status for everyone involved. Because everyone sees the same confirmed information, the caller does not need to repeat the same explanation.

CareBridge does not diagnose conditions, assess urgency, recommend treatment, or determine whether an ambulance is required.

All people, symptoms, hospitals, phone numbers, and availability shown in the public demo are fictional.

How we built it

The frontend is built with TypeScript, React, and Vite on OpenAI Sites.

Server routes run in a Cloudflare Workers-compatible environment.

GPT-5.6 is integrated through the OpenAI Responses API using a strict JSON Schema. Missing information is explicitly marked as unconfirmed, and the system prompt prohibits:

• diagnosis
• triage
• treatment advice
• specialty inference
• invented facts

As a result, every AI-generated Care Brief remains an editable draft until the user reviews and confirms it.

Browser-native Speech Recognition provides editable voice input, while WebRTC Mesh handles media communication.

BroadcastChannel synchronizes state between browser tabs, allowing the hackathon demo to reproduce caller, coordinator, and family roles without implementing backend signaling.

Codex supported the project throughout development—not only by generating code, but also by helping refine requirements, implement the bilingual interface, integrate GPT-5.6, inspect rendered pages, debug browser behavior, review security and privacy considerations, and prepare deployment.

The core product decisions, however, remained mine:

• AI must never make medical judgments
• Every AI-generated summary must be confirmed by a person
• The public demo must use only fictional data
• Future concepts must be clearly separated from implemented functionality

Challenges we ran into

The biggest challenge was reducing the user’s cognitive load during stressful situations without making CareBridge appear to be a medical authority.

Official emergency guidance needed to remain immediately accessible while the coordination workflow also had to stay simple enough to use on a smartphone.

Another challenge was preventing GPT-5.6 from filling gaps or making clinical inferences. Instead of treating this as an implementation detail, I made structured output, explicit “unconfirmed” labels, and mandatory user confirmation core principles of the user experience.

Designing the media experience also required careful consideration. The caller may need to show visible symptoms over video, while coordinators and family members often only need voice communication.

For this hackathon prototype, I intentionally limited the implementation to a same-browser, multi-tab demonstration. Rather than spending time building production-grade signaling servers and TURN infrastructure, I chose to focus on refining the core concept and user experience.

Accomplishments that we’re proud of

• Built a complete bilingual workflow from emergency guidance through shared care coordination
• Used GPT-5.6 as a communication tool instead of a diagnostic AI
• Designed a responsive interface for both smartphones and desktop browsers
• Implemented a working three-role WebRTC prototype with different communication roles for callers, coordinators, and family members
• Created a privacy-conscious public demo that can be tested without entering any real personal or medical information

What we learned

This project reinforced that GPT-5.6 is most valuable here not because it can diagnose illnesses, but because it can improve communication.

Its real value is organizing what people have already said, making missing information visible, and allowing the same confirmed explanation to follow them throughout the care journey.

I also learned that safety should be designed into the interface itself, not hidden in backend logic.

Clear AI boundaries, explicit user consent, editable output, fictional demonstration data, and direct access to official emergency resources should all be visible at the moment users need them.

Finally, working continuously with Codex showed how an AI development partner can accelerate iteration across planning, implementation, testing, review, and deployment while leaving the key product decisions in human hands.

What’s next

The next step is validating this workflow together with medical coordinators, caregivers, healthcare providers, accessibility specialists, and legal and privacy experts.

A production system would require:

• authenticated coordinators
• production-grade WebRTC signaling and TURN infrastructure
• verified hospital data
• timestamped availability information
• consent management and audit logs
• operational monitoring
• and formal collaboration with participating healthcare providers

Another future direction would be integrating MCP so that a personal AI assistant could launch the appropriate child or adult CareBridge workflow while keeping all medical judgment and camera-based interaction inside the reviewed web application.

These ideas represent future work and are not implemented in the submitted prototype.

Built With

• accessibility
• ai-assisted-development
• ai-safety
• artificial-intelligence
• care-coordination
• codex
• digital-health
• generative-ai
• gpt-5.6
• healthcare
• human-in-the-loop
• medical-communication
• multilingual
• openai
• openai-responses-api
• openai-sites
• react
• speech-to-text
• typescript
• webrtc