Healthcare interoperability + AI workflow automation
A platform that receives healthcare data, checks it, cleans it into one consistent format, and uses an AI agent to find and explain relevant information — always pointing to the evidence it used.
Synthetic data only. Portfolio demonstration. No real patient information is used. Not medical advice.
Hospitals and clinics exchange information in several different formats, and those formats are often incomplete or inconsistent. Before anyone can ask a useful question of the data, it has to be checked and translated into one reliable shape.
This platform does exactly that. It accepts three common healthcare formats, validates every message step by step, converts everything into the modern FHIR standard, and scores data quality. On top of that clean data sits an AI agent that answers care-coordination questions — like “Was this patient recently discharged, and do they have a follow-up?” — and cites the records it used.
The answer is checked before it is shown: if a sentence isn't backed by the evidence, it's rejected. The whole system also runs without any AI model configured, which makes it predictable and easy to test.
At a glance
Three input formats, one pipeline
HL7 v2, C-CDA and FHIR all go through the same staged checks.
Data-quality scoring
A 0–100 score per record, with issues explained and bad records quarantined.
Grounded answers
Every claim must point to evidence, or it doesn't make it into the answer.
Safety screening
Refuses prompt-injection attempts and emergencies; never gives diagnoses or treatment advice.
Live demo
The application runs separately and opens in a new tab. Use the public demo account to sign in.
Once you're in, try this
Demo account — limited access.
Demo credentials will appear here once the public demo is deployed.
No password needed: on the app's landing page, click “Explore the demo” to sign in with a limited demo role. The free server sleeps when idle, so the first load can take up to a minute.
Synthetic data only. Portfolio demonstration. No real patient information is used. Not medical advice.
Use cases
In plain language — no technical background needed.
Instead of manually searching through several records, you ask one question. The agent finds the relevant visits, medications, labs, and notes, and brings them together.
The system checks every incoming message for missing, invalid, or inconsistent information, and explains what's wrong — so bad data doesn't quietly spread.
Different healthcare systems describe the same thing in different ways. The platform converts everything into one consistent format so it can be compared and searched.
The AI searches doctors' notes and visit summaries and answers using the passages it found — and shows you those passages.
Questions like “Was this patient discharged recently, and is a follow-up booked?” normally take several clicks. The agent decides which lookups are needed, runs them, and gives a grounded answer.
How it works
Each step in one or two sentences. The grey lines underneath are for engineers who want the technical detail.
Messages and documents come in from other systems — admissions, discharges, lab results, and visit summaries.
Technical implementation: HL7 v2.5.1 (ADT^A01/A03/A04/A08, ORU^R01), C-CDA R2.1, FHIR R4 bundles via REST ingestion endpoints.
Each message is checked for problems: missing fields, invalid codes, broken references, or duplicates. Bad records are set aside instead of silently stored.
Technical implementation: Staged pipeline: parse → syntax → schema → quality. LOINC mod-10 and SNOMED Verhoeff checks, MSH-10 duplicate detection, quarantine on error, HL7 ACK (AA/AE/AR).
Different systems describe the same thing differently. The platform lines up codes, dates, and patient identities so everything matches.
Technical implementation: Code-system mapping, timestamp normalization, lightweight patient matching (MPI-lite), ADT merge handling.
Everything is stored in one modern, standard format, and each record gets a 0–100 data-quality score.
Technical implementation: Canonical FHIR R4 resources in PostgreSQL; custom declarative validator for 10 resource types.
When you ask a question, the agent first screens it for safety, works out which patient and what kind of question it is, then plans which tools to use.
Technical implementation: LangGraph graph: safety_screen → classify_intent → identify_patient → plan_tools → execute_tools → … → finalize.
The agent looks up encounters, medications, labs, and appointments, and searches clinical notes for relevant passages.
Technical implementation: 9 typed clinical tools + hybrid retrieval (vector + keyword + section prior) over pgvector, with a relevance floor.
Everything the agent found is collected as evidence, and the answer is checked against it. Unsupported sentences are rejected.
Technical implementation: Grounding check: each claim must cite evidence, share ≥50% of terms, and match every number and date. LLM answers under 0.7 fall back to an extractive answer.
You get a short, plain answer with citations — and a trace you can open to see exactly how it was produced.
Technical implementation: Server-sent events streaming, per-run traces with tool calls, latency and token usage.
Key ideas
Like a careful clerk checking a form before filing it: are required fields filled in, are the codes real, does this record point to a visit that actually exists? Problems are reported, and broken records are held back.
Technical implementation: Syntax, schema and quality stages; issues stored per record; quarantine on error.
FHIR is the modern standard way to describe health records. Converting everything into it means a lab result looks the same no matter which system sent it.
Technical implementation: Canonical FHIR R4 resources; HL7 v2 segments (PID, PV1, DG1, AL1, OBR, OBX, NTE) mapped to FHIR.
Rather than one big guess, the agent follows a fixed sequence of steps: check the question is safe, figure out the patient, choose the lookups, run them, then write the answer.
Technical implementation: LangGraph state machine with conditional edges; rules or LLM planner.
Every sentence in the answer has to be backed by a record or note the agent actually found. Sentences that can't be backed up are removed.
Technical implementation: Claim-level grounding verifier with citation, term-overlap and number/date matching.
Screenshots
Captured from the demo environment — synthetic data only.
Architecture
The short version is the flow above. Open the panel below for the engineering detail.
backend/app/ingestion/pipeline.pyingestion/hl7/*ingestion/ccda/parser.pyingestion/fhir/validator.pybackend/app/agents/graph.pyagents/nodes.pyagents/grounding.pyTechnology
Safety