CareOrbit

• 

  prototype

Inspiration

Chronic care happens every day, but doctor visits do not. Patients need a simple way to remember what to do each day, ask questions between appointments, review their health records, and understand which AI suggestions have actually been approved by their clinician.

I created CareOrbit to give patients timely daily support while reducing the routine workload placed on clinicians. The goal is not to replace medical judgment. Instead, CareOrbit handles reminders, organizes patient information, answers appropriate educational questions, and routes important cases to clinicians for review.

What it does

CareOrbit is a patient-facing mobile companion for people managing chronic conditions such as diabetes and hypertension.

It provides four clear destinations:

• Today: Personalized medication, blood-pressure, and glucose reminders.
• Chat: Plain-English health questions and photo uploads for meter readings or meals.
• Health records: Simple views of the patient’s readings, medication confirmations, trends, and appointments.
• Doctor advice: A clear comparison between what the AI suggested and what the clinician ultimately approved.

When CareOrbit detects a predefined risk pattern or receives a medication-related question, it prepares a structured summary for clinician review. The patient can see whether the suggestion is waiting for review, approved, updated and approved, or not approved.

CareOrbit never allows the AI to independently change medication, approve a care-plan update, or override a clinician’s decision.

How I built it

I built CareOrbit as a new OpenAI-only project using FastAPI, SQLite, and a mobile-first interface created with HTML, CSS, and JavaScript.

All AI requests pass through a single OpenAI Responses API gateway using GPT-5.6. GPT-5.6 supports:

• Patient-friendly conversations
• Structured SBAR handoff summaries
• Multimodal analysis of synthetic blood-pressure and glucose meters
• Meal-image understanding
• Retrieval query rewriting
• Validated Structured Outputs

For general diabetes and hypertension education, I implemented a safety-gated retrieval workflow. Eligible questions are rewritten, matched against a source-verified knowledge base through OpenAI File Search, and answered with visible sources. If sufficient supporting information cannot be retrieved, CareOrbit abstains and recommends consulting a healthcare professional.

Safety-sensitive questions use a separate path. Emergency phrases, medication-change requests, and predefined abnormal-reading patterns are handled by deterministic rules before GPT-5.6 is called. Medication suggestions, red events, and care-plan changes require an external clinician decision.

I used Codex throughout the project to design the architecture, build the OpenAI gateway, implement the database and safety rules, create the mobile interface, write automated tests, verify the retrieval workflow, and prepare the submission materials.

Challenges I faced

The most difficult challenge was making human oversight visible without turning the patient application into a clinician dashboard.

My initial interface included information that was more useful to doctors or evaluators than to patients. I redesigned the product around a single audience and placed clinician decisions inside the patient-facing Doctor advice section.

Another challenge was separating helpful AI communication from medical decision-making. I gave GPT-5.6 responsibility for communication, retrieval, image understanding, and structured summaries, while deterministic rules remain responsible for risk classification and clinicians retain approval authority.

The mobile interface also required several rounds of refinement. Reminder actions needed to be obvious without feeling alarming, health records needed to avoid unexplained abbreviations, and the relationship between an AI suggestion and a clinician’s final decision needed to be immediately understandable.

What I learned

I learned that human-in-the-loop design is also an information-design problem. Adding an approval step in the backend is not enough. Patients should be able to understand:

1. What the AI suggested
2. Who had authority to review it
3. What the clinician decided
4. Which final guidance they should follow

I also learned that a safer healthcare assistant requires more than a good prompt. It needs deterministic boundaries, grounded retrieval, abstention behavior, validated model outputs, patient authentication, confirmation before saving image-derived readings, and tests covering complete workflows.

Accomplishments I am proud of

I completed an end-to-end proactive care workflow covering daily reminders, deterministic escalation, structured clinician handoff, external approval, appointment updates, patient notifications, and visible final guidance.

The project also includes:

• 20 fixed-seed synthetic patients
• 90 days of synthetic observations
• 23 automated tests
• Source-bearing retrieval answers or abstention
• Confirmation before saving image-derived readings
• A strict clinician-approval boundary
• A patient-only mobile experience

What’s next

My next steps would be usability testing with older adults, accessibility and voice-input evaluation, clinician review of the educational knowledge base, and integration with an authorized FHIR or EHR workflow.

Before any real clinical deployment, CareOrbit would also require formal privacy, security, regulatory, and prospective safety evaluation.

Links

• View the source code
• Watch the demo video

Built With

• api
• codex
• css3
• fastapi
• gpt-5.6
• html5
• javascript
• python
• rag
• sqlite