Clinical Document Navigator

Product thesis

A patient’s paper trail is long: referral letters, discharge summaries, lab reports, imaging correspondence, decades of scanned faxes. The people who work with it — admissions coordinators, medical secretaries, case managers, clinicians preparing a consult — spend real time hunting for a passage they know exists. The interesting product is not “medical AI”. It is a navigation layer for documents that were never designed to be navigated: it finds, organizes, and cross-references, while the reading and every judgment stay with the person accountable for them.

What this deliberately is not

The system answers “where is it?” and “what refers to what?” — never “what does it mean?”. No diagnostic suggestions, no clinical recommendations, no summaries that stand in for reading the source. This is a product decision and a regulatory posture in one: the concept is scoped to remain a documentation tool, with explicit guardrails against feature drift toward interpretation, because that drift changes what the product legally is.

Who it serves

• Admissions and referral coordination teams assembling complete records
• Medical secretaries and case managers preparing files for consults and transfers
• Clinicians who need the original passage, not a paraphrase of it
• Clinical coding, quality, and audit teams who work backwards through histories

The problem, concretely

• A single complex patient can mean hundreds to thousands of pages across systems
• Much of it is scanned or faxed — unsearchable without disciplined OCR
• “When was this medication first mentioned?” means manual page-flipping today
• Cross-checking a value in a discharge summary against the original lab report is tedious enough that it often doesn’t happen
• The cost of missing a document is asymmetric: minutes saved against consequences that land on a patient or in an audit

Product strategy

1. Locate, never interpret. Every capability is a pointer into the source material. The moment the system starts explaining what a finding means, it has left its lane.
2. Citation or nothing. Every result is a highlighted passage in the original page, shown alongside the answer. If the system cannot point, it does not speak.
3. Verification is the workflow, not a checkbox. Results stay marked unverified until a person has opened the source. Working sets and exports only complete on verified items.
4. Data protection as architecture. Health data handling is designed in from the first line — residency, isolation, and auditability are structural, not settings.

Core user journey

1. Documents ingested OCR, typing, dating, de-duplication
2. Staff asks or filters “last mention of anticoagulants”
3. Passages retrieved ranked, each citing its source page
4. Reader verifies in source side-by-side viewer
5. Item added to working set verified status recorded
6. Handoff or export audit trail attached

Major features

• Ingestion pipeline: OCR for scans and faxes, document typing (referral, discharge, lab), date extraction, duplicate detection — with per-document quality scores surfaced, not hidden
• Timeline view: the entire document set ordered by clinical date, not upload date
• Passage-level retrieval with the source highlight one glance away
• Cross-reference panel: the same medication, allergy, or finding traced across documents
• Working sets: assemble the exact pages needed for a consult, transfer, or audit task
• Coverage indicator: which documents the current query searched — and which it could not read, so a gap is visible instead of silent

Where AI fits — and the line it never crosses

Retrieval is the core: passage search over a per-patient index, document classification, entity linking so that one substance or finding connects across letters written years apart. Extraction fills document metadata — type, date, author organization — with per-field confidence.

The line: no interpretation, no clinical inference, no answer without a citation. Low- confidence OCR is flagged, never silently corrected, because a plausible wrong word in a lab value is worse than a visible gap. And the system never ranks by clinical importance — that would be a judgment in disguise. It ranks by textual relevance and says so.

Data protection is the architecture

Health data is special-category data under GDPR Article 9, and this concept treats that as the starting constraint rather than a compliance afterthought:

• EU data residency end to end, including model inference inside the same boundary
• Tenant isolation with encryption at rest and in transit; no training on customer data
• Role-based access mirroring the organization’s own authorization model — the tool never widens who can see a document
• Append-only audit trail of every search, view, and export, serving both accountability duties and the organization’s own oversight
• Retention and deletion aligned to the customer’s medical-records obligations
• A data protection impact assessment scoped before any pilot touches real records

System overview

• Web application built around a fast document viewer — the viewer is the product’s floor
• Ingestion pipeline feeding a typed document store and per-patient search index
• Retrieval and entity-linking services with confidence surfaced per result
• Append-only audit log as a first-class subsystem
• Import from archive and document-management systems; exports back with provenance

Accessibility considerations

This is all-day software for desk staff: full keyboard operation, screen-reader-compatible results and viewer, high-contrast reading mode, and no interaction that depends on hover or color alone. Structured results make assistive output natural rather than retrofitted.

Prototype scope

Narrow and synthetic: one task (assembling a referral packet), one document mix, and a corpus of entirely synthetic patient records — no real patient data before the compliance groundwork is real. The hypothesis is behavioral: does citation-first navigation beat the current PDF-reader-and-Ctrl-F workflow by enough to change a working habit?

Evaluation plan

• Retrieval recall on a labeled synthetic corpus of known-item queries (target hypothesis: high enough that staff stop double-searching manually — measured, then argued about)
• Time-to-verified-passage against a manual baseline on the same tasks
• Zero tolerance for uncited assertions anywhere in the product surface
• Complacency check: do users keep opening sources after week four, or start trusting the snippet? The design goal is that verification stays cheaper than doubt
• OCR quality floor: measured error rates on aged fax stock, because that is the real input

Risks and open questions

• Regulatory boundary: features that drift toward interpretation could reclassify the product under medical-device rules; the roadmap needs a standing guardrail review
• The blank-spot problem: a retrieval miss can be worse than no tool, because the tool creates confidence — coverage indicators must make “not searched” impossible to miss
• Decades-old scans put a hard ceiling on recall; honesty about that ceiling is a feature
• Integration gravity: value depends on sitting inside hospital archive systems, and healthcare procurement moves in years, not sprints

Delivery phases

1. Discovery with coordination and secretariat teams; corpus design and query taxonomy
2. Ingestion and retrieval prototype on synthetic records, measured against the evaluation plan
3. Verification workflow, audit trail, and the compliance groundwork (DPIA, processing agreements)
4. Pilot integration with one archive system under a controlled scope, then hardening