ChronicCare

Inspiration

Living with a chronic illness is not limited to what happens inside a clinic.

Daily care is often coordinated through scattered family messages, handwritten notes, medication reminders, health documents, and conversations that are difficult to remember accurately. Patients may struggle to communicate how they have been feeling, while caregivers may not have a clear and shared picture of what happened throughout the day.

We were inspired to build ChroniCare after recognizing that this is not only a medical-information problem. It is a coordination problem.

Instead of trying to replace doctors or produce clinical decisions, we wanted to create a safer digital space where patients and caregivers can organize everyday care context, preserve important observations, and prepare better questions for qualified healthcare professionals.

Our hackathon scenario uses fictional people and synthetic type 2 diabetes data to demonstrate the workflow. However, the product is designed as a non-diagnostic care-coordination system that could support people living with different chronic conditions.

What it does

ChroniCare creates a separated Care Circle for each patient.

Patients receive a simple, supportive interface where they can access their assigned profile, complete daily check-ins, review care routines, and communicate relevant context without navigating a complicated medical dashboard.

Authorized caregivers can:

Manage clearly separated Patient Profiles.
Review patient check-in information.
Maintain medication and reminder records.
Coordinate daily-care activities.
Preserve context that may be useful during the next professional consultation.
Access only the patient information they are explicitly authorized to view.

ChroniCare is also designed around a human-reviewed document workflow. Azure AI Document Intelligence extracts text and layout from a privately stored synthetic health document. Azure OpenAI can then map only the minimum required OCR text into a validated structured draft.

The extracted result is never treated as confirmed medical truth. A caregiver must review and approve it before the information can become part of the patient’s confirmed context.

The target Patient and Caregiver assistants use guarded Azure OpenAI workflows for:

Product navigation.
General routine support.
Organizing care-related information.
Preparing questions for a doctor visit.

The assistants are explicitly restricted from diagnosing conditions, changing medication or dosage, prescribing nutrition, producing final laboratory interpretations, or replacing doctors and emergency services.

When an external AI or OCR provider is unavailable, ChroniCare displays a clearly labeled deterministic fallback instead of pretending that a live AI response succeeded.

The target MVP also includes an open-dashboard SOS coordination alert and a static Tangerang facility and BPJS helper. These are designed as coordination and discovery tools—not emergency dispatch, guaranteed notification, or authoritative healthcare-provider information.

Only capabilities that pass final implementation and QA verification will be presented as working features in the final demo.

How we built it

ChroniCare was developed as a modular Next.js monolith during a 30-hour hackathon.

A single Next.js App Router application contains:

The Patient and Caregiver interfaces.
Route Handlers.
Domain services.
Server-side authorization.
Database access.
External provider adapters.
Validation and fallback logic.

We used React, TypeScript, Tailwind CSS, shadcn/ui, and Base UI to build a responsive and accessible interface.

Supabase provides PostgreSQL, caregiver authentication, private storage for the target document workflow, and Realtime capabilities for the target open-dashboard SOS workflow. Prisma is used as the ORM and database-access layer.

Patient access uses a hashed access code and an opaque httpOnly session linked to exactly one Patient Profile. Every patient-bound operation requires an explicit patientProfileId and a server-side relationship authorization check.

For AI and document processing, the target architecture uses:

Azure AI Document Intelligence for OCR text and layout extraction.
Azure OpenAI for structured extraction and guarded assistance.
Zod schemas for runtime validation.
Server-side context selection.
Human confirmation before extracted information can enter AI context.
Explicit refusal rules and labeled fallbacks.

We divided the implementation into small evidence-based packets. A packet was not considered complete based only on generated code or visual appearance. It required relevant evidence such as linting, type checking, automated tests, builds, responsive checks, authorization checks, and human review.

The responsibilities were divided across the team:

Bernard owned the API, database, authentication, Supabase integration, and server-side authorization.
Ozan owned product scope, acceptance criteria, QA evidence, demo readiness, and pitch coordination.
Daniel owned Patient and Caregiver information architecture, responsive UI, accessibility, and user-facing copy.
Al owned Azure OpenAI, Azure AI Document Intelligence, extraction design, AI safety rules, and provider fallbacks.

OpenAI Codex assisted with implementation planning, code drafting, code review, test suggestions, consistency checks, and submission documentation. The team reviewed AI-assisted changes, ran the available verification commands, and remained responsible for every product and safety decision.

Challenges we ran into

Designing useful AI without turning it into medical advice

The largest challenge was deciding what the AI should not do.

A generic chatbot can easily produce confident medical-sounding answers. For ChroniCare, we needed strict boundaries around diagnosis, laboratory interpretation, medication, dosage, nutrition, emergency situations, and clinical decisions.

We therefore designed the AI as a navigation and preparation layer rather than a clinical authority.

Protecting separated Patient Profiles

ChroniCare may contain sensitive care context for multiple people within one Care Circle. It was not enough to hide information visually in the interface.

We needed server-side authorization for every patient-bound operation and an explicit patient identifier throughout the request flow. We also needed to test wrong-profile access rather than assuming that authentication alone was sufficient.

Distinguishing unknown information from absent information

In healthcare-related workflows, “we do not know” is different from “this condition is not present.”

We had to design the data model and interface so that missing information would not accidentally be presented as a confirmed negative statement.

Making OCR useful but not authoritative

OCR and structured extraction can reduce manual input, but an extraction error can be dangerous when presented as confirmed health data.

We addressed this by keeping extracted information in a draft state until a caregiver explicitly reviews and confirms it.

Handling unavailable providers honestly

Hackathon demos are vulnerable to network failures, expired credentials, provider limits, and external-service downtime.

Instead of silently substituting prerecorded results, ChroniCare uses explicitly labeled fallbacks. This made the architecture safer, although it also required additional provider-state and interface logic.

Managing scope within 30 hours

We had many possible features but limited implementation time.

We prioritized one connected Patient-to-Caregiver journey, profile separation, safe access, fictional data, and evidence-backed completion. Features without sufficient implementation and QA evidence were kept as target capabilities rather than being represented as completed functionality.

Accomplishments that we're proud of

We are proud that ChroniCare is designed around care coordination rather than exaggerated medical claims.

Our strongest accomplishments include:

Building separate Patient and Caregiver experiences around one connected care journey.
Binding Patient access to one profile through a hashed code and an opaque server-side session.
Requiring relationship authorization for patient-bound operations.
Treating OCR output as a reviewable draft instead of confirmed medical truth.
Designing explicit AI refusals and deterministic provider fallbacks.
Distinguishing unknown information from information explicitly reported as absent.
Using only fictional people and synthetic health data.
Creating an evidence-based development process rather than marking features complete based only on visual progress.
Coordinating product, interface, backend, AI, safety, QA, and submission work across four team members within a 30-hour hackathon.

What we learned

We learned that building responsible healthcare technology requires more than adding warnings to a chatbot.

Safety needs to exist throughout the architecture:

In the data model.
In authorization rules.
In context selection.
In validation.
In refusal behavior.
In interface wording.
In provider-failure handling.
In the claims made during the demo.

We also learned that human review is not merely an additional interface step. For document extraction, it is part of the product’s trust model.

Another important lesson was that authentication and authorization are different. A logged-in caregiver should not automatically gain access to every Patient Profile.

Finally, we learned that a smaller connected journey with strong evidence is more valuable than a larger collection of features that cannot be demonstrated honestly.

What's next for ChroniCare

Our next priorities are to:

Complete and verify the Azure-backed document extraction workflow.
Expand guarded assistance for navigation and doctor-visit preparation.
Strengthen the human-review interface for extracted information.
Complete the Realtime open-dashboard SOS coordination workflow.
Validate facility and BPJS information through maintainable and authoritative sources.
Conduct accessibility and usability testing with patients and caregivers.
Expand beyond the synthetic type 2 diabetes scenario to other chronic-care routines.
Add multilingual support for Indonesian families.
Improve auditability around changes to confirmed care information.
Seek appropriate healthcare, privacy, security, and legal review before any real-world deployment.
Continue treating ChroniCare as a coordination product rather than a replacement for professional healthcare.