Syncy Care

Hospitals manage care. Syncy helps patients understand it. An Alexa+ companion that explains the care plan, flags confusion to nurses, and never gives medical advice.

Comment

Inspiration

A hospital stay can be overwhelming. Patients receive information from different doctors and nurses, undergo tests, experience changes to their care plans, and are expected to understand discharge instructions, often while tired, stressed, or recovering.

One problem stood out to me: healthcare systems can document what information was provided, but that doesn't necessarily mean patients understood it.

I wanted to explore how technology could bridge the communication gap between patients and their care teams without creating another AI system that attempts to replace medical professionals.

That idea became Syncy Care, a patient-understanding companion designed to make hospital information clearer, more accessible, and easier to follow.

My goal was simple: help patients understand their care, not make clinical decisions for them.

What it does

Syncy Care is an interactive, AI-assisted patient-understanding platform designed around an Alexa+-style conversational experience, powered by a self-hosted Model Context Protocol (MCP) server.

The prototype includes a patient-facing interface, a care-team dashboard, and three fully synthetic patient scenarios.

Patients can ask questions such as:

  • "What's happening today?"
  • "What changed since yesterday?"
  • "What am I waiting for?"
  • "What should I ask my doctor?"
  • "What do I need to know before going home?"

Instead of freely generating medical answers, Syncy Care retrieves information from structured synthetic patient records and provides explanations linked to their sources.

Clinical Safety: GREEN, YELLOW, and RED

I designed Syncy Care with three deterministic safety classifications:

  • GREEN (Informational): Questions about schedules, approved definitions, and general information can be answered directly.
  • YELLOW (Chart-Specific): Questions requiring patient-specific explanations are answered only when supported by information in the synthetic patient record.
  • RED (Clinical Decisions): Questions involving diagnosis, medication changes, treatment recommendations, or other clinical judgments are refused and added to a simulated care-team review queue.

This prevents the application from treating a language model as a substitute for professional medical judgment.

AI-Powered Plain-Language Explanations

I integrated Amazon Bedrock using Amazon Nova Micro to help patients understand existing care-plan information in simpler language.

When a patient requests a clearer explanation, Syncy Care retrieves the relevant approved synthetic information first. Amazon Bedrock then rewords that information while the application applies safety restrictions and fallback behavior.

The goal is to improve understanding without generating new medical instructions.

Understanding Tracking and Teach-Back

Syncy Care also demonstrates how patients can review and communicate their understanding of important instructions.

For example, a patient can explain medication instructions in their own words. The application checks the response against predefined criteria from the synthetic care plan and identifies information that may need further explanation.

These results appear on the care-team dashboard as simulated understanding indicators, not clinical assessments.

Additional Features

  • Care-plan timeline: View upcoming and completed synthetic care events.
  • What Changed?: Compare structured care-plan snapshots to identify updates.
  • Pending Events: See which tests, activities, or other documented events remain pending.
  • Care-Team Dashboard: Review understanding indicators and simulated patient questions.
  • Accessibility Controls: Adjust presentation settings and request simpler explanations.
  • MCP Architecture Demo: Inspect actual MCP initialization, tool discovery, and execution requests.
  • Audit Logging: Track important demonstration interactions and application actions.

The AI explains. The clinician decides.

How I built it

I independently developed Syncy Care using a lightweight full-stack architecture focused on reliable information retrieval, explicit safety boundaries, and reproducible demonstrations.

Backend and Model Context Protocol

I used JavaScript and Node.js to build the backend, application APIs, and self-hosted MCP server.

The server exposes 13 MCP tools that support care-plan retrieval, change tracking, approved explanations, discharge information, understanding tracking, teach-back exercises, and simulated clinical question management.

Examples include:

  • get_today_care_plan
  • get_changes_since
  • get_pending_events
  • get_approved_patient_explanation
  • get_discharge_requirements
  • create_question_for_team
  • record_teach_back
  • explain_clinical_term

The MCP transport is implemented directly using HTTP and JSON-RPC, including protocol initialization, tool discovery through tools/list, and execution through tools/call.

The implementation targets MCP protocol version 2025-11-25. I built an interactive demonstration of these operations, although complete interoperability with an official Alexa+ client has not been independently verified.

Amazon Bedrock Integration

I integrated Amazon Bedrock's Converse API using the Amazon Nova Micro model (us.amazon.nova-micro-v1:0) in the US East (Ohio) region (us-east-2).

Bedrock is used for controlled, plain-language rewording of information retrieved from structured synthetic patient records.

I successfully verified the integration through a live AWS invocation using Maria Thompson's synthetic care plan.

I also implemented safeguards and fallback behavior so the application can return the original approved information if the AI-generated wording is unsuitable or unavailable.

The Bedrock implementation is included in my public GitHub repository, with additional documentation explaining the integration and its limitations.

Deterministic Safety Architecture

Rather than relying entirely on AI prompts, I implemented application-level safety rules.

Requests are classified before the system determines whether they can be answered, require chart-based evidence, or must be referred to a simulated care-team queue.

This approach keeps the language model focused on explanation rather than clinical decision-making.

Care-Plan Comparison

The "What changed?" feature compares structured care-plan snapshots in code.

Instead of asking a language model to remember previous information, the application identifies differences between predefined records.

This makes changes reproducible, traceable, and easier to test.

Frontend and User Experience

I used HTML, CSS, and JavaScript to develop the responsive patient workspace, care-team dashboard, safety demonstration interface, and architecture page.

I focused on making information understandable through straightforward navigation, clear status indicators, and interactive explanations.

Automated Testing

I used Node.js automated testing tools to verify:

  • MCP operations and API responses
  • Patient-data isolation
  • Clinical-safety classification
  • Refusal of clinical-decision questions
  • Source attribution and care-plan comparisons
  • Teach-back behavior
  • Amazon Bedrock integration and fallback handling

My published implementation passed 86 automated tests, including seven added tests related to the Bedrock integration.

Development Tools

I used OpenAI ChatGPT, GitHub Copilot, and Cursor to assist with architecture exploration, implementation, debugging, testing, and documentation.

I also used the AWS CLI and AWS Agent Toolkit to configure and verify the Bedrock integration.

All patient information is synthetic. No real patient data was used.

Challenges I ran into

1. Making AI Useful Without Providing Medical Advice

One of my biggest challenges was deciding where conversational assistance should stop.

I wanted the system to provide useful information without allowing it to diagnose conditions or make treatment decisions.

I addressed this by implementing deterministic safety classifications, structured information retrieval, and explicit restrictions on clinical questions.

2. Making Answers Trustworthy and Traceable

A useful patient assistant needs to explain not only what information is available but also where that information came from.

I connected patient-specific explanations to structured source records rather than allowing unrestricted AI-generated answers.

This also required ensuring that information belonging to one synthetic patient could not appear in another patient's responses.

3. Implementing and Testing MCP

Building the MCP server required understanding protocol initialization, JSON-RPC communication, HTTP behavior, tool discovery, and tool execution.

Although local tests could verify core functionality, they could not independently guarantee compatibility with every external MCP client.

This challenge inspired me to develop MCP Streamable Proof, a separate open-source utility that helps developers test essential MCP server interactions.

4. Integrating Amazon Bedrock

Configuring AWS authentication, understanding regional model availability, and obtaining successful model access required additional troubleshooting.

I initially encountered account verification restrictions when exploring model access in Canada Central.

I successfully completed the integration using Amazon Nova Micro in US East (Ohio) and verified the result with synthetic patient information.

5. Testing Safety Responsibly

Because I developed both the application logic and many of the tests, I recognize that passing automated tests does not establish clinical safety.

I treated testing as an important engineering baseline while documenting the limitations of the prototype.

Accomplishments That I'm Proud Of

  • Built Syncy Care independently, combining a patient-facing application, care-team dashboard, and self-hosted MCP server.
  • Implemented 13 MCP tools for structured patient-information retrieval and simulated care workflows.
  • Successfully integrated Amazon Bedrock Nova Micro and verified live AI-powered plain-language rewording.
  • Developed deterministic GREEN, YELLOW, and RED safety rules to restrict clinical decision-making.
  • Created a reproducible care-plan comparison system that identifies changes between structured snapshots.
  • Implemented teach-back exercises that compare patient responses against predefined instructional criteria.
  • Built three synthetic patient scenarios, understanding tracking, a simulated question-review queue, and audit logging.
  • Passed 86 automated tests covering core functionality, safety boundaries, and Bedrock integration behavior.
  • Published MCP Streamable Proof, an independent, MIT-licensed open-source testing utility for MCP developers.

One of my biggest personal accomplishments was bringing together backend development, conversational interfaces, cloud AI, application safety, and user experience into one functioning prototype.

What I Learned

Building Syncy Care taught me that delivering information and ensuring understanding are two different challenges.

I also learned that responsible AI development requires much more than connecting an application to a language model.

By keeping patient records structured, enforcing deterministic rules, and limiting Amazon Bedrock to plain-language explanations, I gained a deeper understanding of how AI can provide value while remaining constrained by application-level safeguards.

Developing the MCP server and integrating a real AWS service strengthened my understanding of API design, cloud authentication, automated testing, debugging, and documentation.

I also learned the importance of testing AI-assisted code rather than assuming generated implementations are correct.

Most importantly, this project strengthened my interest in creating technology that makes complex information more understandable and accessible.

What's Next for Syncy Care

My next goal is to explore how this concept could evolve beyond a synthetic hackathon demonstration.

Future priorities include:

  • Official MCP Interoperability: Test the server with official MCP clients and explore a real Alexa+ integration.
  • Usability Research: Gather feedback from patients, nurses, and other healthcare professionals.
  • Accessibility: Improve conversational context, reading accessibility, and voice-based interaction.
  • Healthcare Data Standards: Explore synthetic FHIR R4 integrations and standards-based data exchange.
  • Privacy and Authentication: Develop stronger authentication, consent controls, and secure data handling before considering real-world information.
  • Safety Evaluation: Conduct independent assessments of explanation accuracy, clinical boundaries, and patient understanding.

My long-term goal is to explore how conversational technology can make healthcare communication clearer while preserving the role of qualified medical professionals.

Links and Resources

Main Project Repository:

Syncy Care on GitHub

Amazon Bedrock Integration Documentation:

AWS Builder Technical Documentation

Open Source Contribution:

MCP Streamable Proof

Development Friction Log:

View Friction Log

Disclaimer: Syncy Care is a hackathon prototype using entirely synthetic patient information. It is not a medical device, does not provide medical advice, and is not intended for clinical use.

Built With

Share this project:

Updates