pyaar note viewer
A clinical-notes viewer that puts the original note, the LLM extraction, and the structured results side by side, so you can trace every field back to the sentence it came from. Runs on fully synthetic data.
What it is
pyaar note viewer is a single-file web applet for reading clinical notes through an extraction pipeline. Each note is shown in three linked panes: the original note as written, the LLM pass that reads it, and the structured results it produces. Every extracted value is anchored to the exact span of text it was pulled from, so a reviewer can click a result and land on the sentence that justifies it.
It was productionized from an internal prototype into a clean, shareable demo. All patient data is fully synthetic (107 generated records); no real PHI ever ships with it.
How it works
- Loads a CSV of notes and their extracted fields directly in the browser, no backend required.
- For each row, renders the source note alongside the structured output (diagnoses, medications, findings, and other captured fields).
- Highlights the verbatim quote backing each structured value, making the original-note → LLM → results flow auditable at a glance.
What it's for
Structured extraction from clinical text is only trustworthy if you can see where each answer came from. pyaar note viewer is a lightweight way to inspect and QA that pipeline: to sanity-check an LLM's reading of a note, to demo the original → extraction → results loop to a non-technical audience, and to do it safely on synthetic data before pointing anything at real records.
Origin
I built pyaar note viewer while leading the annotation team at TargetRWE. Working through clinical notes day to day, it became clear there wasn't an easy way for the team to review notes and their edge cases, especially the specific edge-case notes that surfaced during escalations. Reviewing them meant digging through raw exports with no view of how the extraction pipeline had actually read each note. So I made this app to streamline that: put the original note, the model's reading, and the structured output side by side, and let a reviewer flag and annotate as they go.
Where this fits
I see this as a kind of tooling-engineer function that increasingly belongs inside a PM's job: building small, sharp internal tools that help other teams make decisions faster. Whether it's speeding up development or cleaning up data, a PM who can ship the tool that unblocks a team, not just spec it, compounds everyone's output.