Douglas AI

• 

  Technical architecture diagram

Inspiration

Patients today have more access to their health records than ever — portals like MyChart put lab results, visit notes, and medication lists at their fingertips. But access isn’t the same as understanding. Most patients open a lab report, see numbers and medical jargon, and close the tab more confused than before. The alternative — copying their records into ChatGPT or another AI tool — means handing sensitive health data to a third party with no privacy guarantees. We asked: what if patients had an AI assistant that could explain their medical documents in plain language, right inside MyChart, without their data ever leaving their control? That question led us to DouglasAI — a Chrome extension sidebar that reads what the patient is already looking at, enriches it with their full medical history via the Epic FHIR API, and generates plain-language summaries, health insights, aftercare instructions, and an interactive chatbot. The key differentiator: a dual-layer privacy architecture (HIPAA de-identification + BAA-backed inference) ensures that no identifiable patient data ever reaches the AI model.

What it does

DouglasAI is a Chrome extension that opens as a sidebar on any MyChart page. When the patient navigates to a page lab results, visit notes, medications, billing — the extension automatically reads the page content and sends it (through a de-identification proxy) to generate: • Document Summary — a plain-language explanation of what the page says, translated into 11 languages • Health Insights — proactive flags on concerning lab values, drug interactions, and trends across the patient’s full medical history • Aftercare Instructions — a structured daily medication schedule with timing constraints (e.g., “take Omeprazole 30 min before breakfast”), symptoms to monitor, lifestyle reminders, and follow-up appointments with push notifications • Ask Your Doctor — cross-references the patient’s entire history across providers to surface issues that may have fallen through the cracks (e.g., one doctor prescribed an NSAID while another flagged declining kidney function) • Chat with DouglasAI — a conversational chatbot with full patient context for follow-up questions

How we built it

We started by mapping out the privacy constraints first — before writing a single line of feature code. We knew that any AI-powered health tool that asks patients to trust it with their data would fail if privacy wasn’t baked into the architecture from the ground up. So we began with the de-identification pipeline and worked outward. • Privacy layer and data pipeline. We stood up Presidio in Docker containers and built the de-identification proxy, validating it against synthetic PHI datasets to confirm it correctly strips all 18 Safe Harbor identifiers. In parallel, we implemented the SMART on FHIR OAuth flow with PKCE to authenticate against the Epic sandbox and built the FHIR data fetching module to pull conditions, medications, observations, and allergies. • Inference and prompt engineering. With clean, de-identified data flowing, we built the prompt builder — a module that assembles the patient’s current page context and full medical history into structured prompts for DeepSeek V3.2. We iterated extensively on prompt engineering to get the model to return well-structured JSON with medication schedules that respect timing constraints (e.g., spacing Omeprazole and Metformin 30 minutes apart). We also built the chat pipeline, which maintains conversational context while injecting de-identified patient data into every system message. • Extension UI and integration. We built the Chrome extension as a Manifest V3 sidebar using React, with a content script that tracks the patient’s active page via DOM observation and URL monitoring. The background service worker manages communication between the content script, sidebar, and back-end server. We implemented tab-based navigation (Summary, Insights, After care, Chat), language selection with 11 languages, and the consent/onboarding flow. • Testing, polishing, and the MyChart shim. We wrote a comprehensive test suite (51 tests across 7 suites) covering every server module — de-identification, FHIR summarization, inference parsing, OAuth, session management, data enrichment, and route handling. We added push notifications for medication reminders and built the supplemental patient dataset to create a realistic demo scenario (a patient with rising creatinine on NSAIDs that multiple specialists have overlooked). Tools and Technologies • Backend: Node.js, Express, Axios, Zod (schema validation) • De-identification: Microsoft-Presidio (analyzer + anonymizer) via Docker • Authentication: SMART on FHIR OAuth 2.0 with PKCE • LLM Inference: DeepSeek V3.2 API (BAA-covered) • Frontend: Chrome Extension Manifest V3, React, Vite • EHR Integration: Epic FHIR R4 API • Testing: Jest (51 tests, 7 suites) • Dev Tooling: ESLint (Airbnb config), Husky pre-commit hooks, lint staged

Challenges we ran into

No MyChart Sandbox (Resolved) The biggest early blocker was that Epic’s FHIR sandbox provides API access to patient data, but does not provide a MyChart web interface. DouglasAI’s core feature — reading the page the patient is currently viewing and generating context-aware insights — requires an actual MyChart-like website to track. Without it, we had no way to develop or demo the on-screen page tracking that makes the extension useful. We resolved this by building a full MyChart shim: a multi-page demo site served by our backend that faithfully replicates the structure and content of MyChart’s key pages (health summary, visits, messages, lab results, medications, billing). The shim is populated with a synthetic patient dataset designed to showcase complex medical scenarios — including a patient with rising creatinine and concurrent NSAID use that multiple specialists have overlooked. This gave us a realistic development target and a compelling demo environment. FHIR Data Sparsity (Resolved) The Epic sandbox returns minimal synthetic data — often just a few conditions and medications with no lab history or visit notes. This made it impossible to demonstrate features like lab trend detection and cross-provider issue flagging. We built a data enrichment module (supplement.js) that merges supplemental synthetic data into the FHIR response, with deduplication logic to avoid conflicts with real sandbox data. The supplemental dataset was carefully designed with medically realistic patterns (18 months of trending creatinine, interacting medications across 5 specialists) to exercise every feature of the app. De-identification Latency (Resolved) Presidio adds noticeable latency to every request since text must pass through both the analyzer and anonymizer before reaching the LLM. We mitigated this by parallelizing the FHIR data fetch and de-identification steps where possible, and by short-circuiting the de-identification call for empty inputs (e.g., when a patient has no medical history yet). We also implemented the regex fallback so the app remains functional even if the Presidio containers are slow or unavailable. Chrome Extension Security Model (Resolved) Manifest V3 imposes strict restrictions on service workers and content scripts. Cross-origin requests from the extension to our backend required careful CORS configuration, and the content script had to communicate with the sidebar via the background service worker rather than directly. Getting the OAuth callback flow to work across the extension context and the server required HTTPS with a self-signed certificate that Chrome would trust.

Accomplishments that we're proud of

• The privacy architecture actually works. We didn’t just claim HIPAA compliance — we built a working de-identification pipeline, validated it with tests, and backed it with a BAA. The LLM genuinely never sees patient names, dates, or identifiers. • Cross-provider issue detection. The “Ask Your Doctor” feature caught a realistic clinical scenario in our demo data: an orthopedist prescribed Ibuprofen for knee pain while a nephrologist was flagging declining kidney function caused by NSAIDs. This is exactly the kind of fragmented-care problem that falls through the cracks in real healthcare. • 51 passing tests. For a hackathon project, having a comprehensive automated test suite with real coverage of the critical paths (de-identification, OAuth, inference parsing) is something we’re proud of. It gave us confidence to iterate quickly without breaking things. • The MyChart shim turned into a feature. What started as a workaround for the missing sandbox became one of the strongest parts of our demo — a fully navigable multi-page patient portal with realistic clinical data.

What we learned

• Privacy-first architecture is a design constraint, not a feature you bolt on. Building de-identification into the data pipeline from day one shaped every architectural decision downstream — and made the whole system simpler, not more complex. • Prompt engineering is the real product work. Getting the LLM to return well-structured medication schedules with correct timing constraints (spacing drugs apart, accounting for food requirements) took more iterations than any other part of the codebase. • FHIR is powerful but sparse in sandbox mode. The gap between what the FHIR spec supports and what Epic’s sandbox actually returns is significant. Building the enrichment layer taught us a lot about the real-world shape of clinical data.

What's next for Douglas AI

Short-term improvements (1-2 weeks) • Real MyChart integration testing. With access to a production Epic environment (via a health system partnership), we could validate the extension against real MyChart pages instead of our shim. The page tracking and DOM extraction logic is designed to be site-agnostic, but real-world MyChart pages will have edge cases we haven’t encountered. • Streaming LLM responses. Currently, the extension waits for the full LLM response before rendering. Switching to server-sent events would let the sidebar stream text as it’s generated, significantly improving perceived latency. • Provider-side dashboard. A companion interface where clinicians can see what their patients are asking about — anonymized and aggregated — to help them anticipate questions and identify common points of confusion. Long-term scaling • Multi-EHR support. The architecture already uses SMART on FHIR with standard resource types, so connecting to Cerner, Allscripts, or any FHIR R4-compliant EHR requires only a new OAuth configuration — no architectural changes. This is the clearest path to broader adoption. • Containerized deployment. Move the backend to a managed container platform (AWS ECS or Google Cloud Run), put Presidio behind an internal service mesh, and add Redis for session persistence. The stateless architecture means horizontal scaling requires no redesign. • Chrome Web Store distribution. Publishing the extension to the Chrome Web Store gives us automatic distribution, updates, and user management at scale. Combined with the multi-EHR backend, this creates a path to serving any patient at any health system that supports FHIR. • Localization and accessibility. Expand beyond 11 languages, add screen reader support, and ensure the sidebar meets WCAG 2.1 AA standards to serve patients with disabilities.

Built With

• axios
• chrome-extension-manifest-v3
• deepseek-v3.2-api
• epic-fhir-r4-api
• eslint
• express.js
• husky
• jest
• lint-staged
• microsoft-presidio
• node.js
• react
• smart-on-fhir-oauth-2.0
• vite
• zod