Healthcare & Clinical

Automating Clinical Report Generation From Multi-Source Patient Files

A proposed pipeline that reads MRI reports, lab panels, genetic results and clinical notes, builds a checked patient record, and drafts a clinician's PowerPoint and Word report into the practice's own templates.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

CS-005_Clinical_Report_Automation_Tool image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client's clinicians spend meaningful time after every patient visit manually preparing two documents - a consultation presentation and a detailed treatment-plan report - by gathering information from MRI reports, blood panels, genetic reports, DEXA scans, prior records, and their own notes, then copying and formatting it by hand.

Pfactorial Technologies proposed a tool that automates everything between upload and clinician approval: it identifies each uploaded file's format, extracts and cross-checks clinical values against a defined field list, flags any conflicting or unverifiable values rather than guessing, and drafts into the practice's existing PowerPoint and Word templates without rebuilding them.

The design deliberately keeps the clinician in the loop at both ends - selecting the visit and uploading files at the start, and approving every generated report at the end - while removing the manual collection, copying, and formatting work in between. Every sentence in a drafted report is traced back to the source value that supports it before a clinician ever sees it.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to AI systems handling sensitive clinical data: extracting against a defined field list rather than free text, flagging every conflict instead of resolving it silently, and keeping a clinician as the final approver on every generated document.

THE CHALLENGE

Manual report preparation after every patient visit created four compounding problems that shaped the proposed design.

1. Clinical time goes to formatting, not judgment

Clinicians spend valuable time gathering information, copying data, and formatting documents rather than focusing on patient care, even though the clinical decisions themselves come entirely from their own judgment.

2. Every laboratory formats its results differently

Text-based PDFs, scanned documents, and faxes all arrive in different layouts, and a single upload can contain several distinct documents run together with no separator page.

3. The same clinical value can appear twice, and disagree

The same lab result sometimes appears in two source documents with different units or values, and a system that resolves that conflict silently rather than flagging it would be actively dangerous.

4. Templates cannot be rebuilt, only filled

The client's existing PowerPoint and Word templates carry specific branding, fonts, and layout that must survive the automation untouched - rebuilding the document from scratch was not an acceptable approach.

The real brief Not "summarize patient files with AI" but "build a checked, traceable patient record first, then write from it into our existing templates - with every conflict flagged and every report clinician-approved before it is used."

THE SOLUTION

Pfactorial proposed a four-step pipeline where the tool first builds a verified patient record from every uploaded document, and only then drafts into the practice's existing templates - never handing a pile of files directly to a model and asking for a report.

CS-005_Clinical_Report_Automation_Tool image 2

Figure 1 - The proposed pipeline: format-aware file reading, checked record extraction, template filling in place, and storage inside the client's own Google Drive.

Architectural principles

Build a checked record before writing anything - clinical values, conditions, medications, lab results and imaging findings are extracted against a defined field list and checked against the page they came from - not handed to a model as raw documents and summarized directly.
Conflicts are flagged, never silently resolved - where the same value appears in two documents and they disagree - such as a lab result with mismatched units - the conflict is surfaced for clinician review rather than the system picking one value.
Templates are filled in place, never rebuilt - the practice's PowerPoint and Word templates are mapped once, then written into directly using python-docx and python-pptx, so fonts, colours, slide masters and logos cannot be disturbed.
Only the minimum data a component needs, sees it - patient names and record numbers are withheld from the AI while it writes - a treatment protocol does not require them - and reattached only when the finished document is produced.

CAPABILITIES DELIVERED

The proposed tool covers the full path from a folder of visit documents to a clinician-approved report, with every extracted value traceable back to its source.

CAPABILITY	WHAT IT DOES
Format-Aware Document Reading	Identifies each uploaded file's type and routes it to a purpose-built reader - table-preserving PDF parsing, or OCR with a quality check for scans and faxes.
Multi-Document Boundary Detection	Where a single upload contains several documents run together, decides whether each page continues the previous document or starts a new one.
Checked Field Extraction	Extracts against a defined list of clinical fields rather than free text, validating each value for type, range, and clinical plausibility before acceptance.
Conflict Flagging	Surfaces disagreements between sources - such as the same lab value in two panels with different units - for clinician review instead of resolving them automatically.
In-Place Template Filling	Writes into the practice's existing PowerPoint and Word templates using python-docx and python-pptx, preserving all original formatting.
Traceable, Source-Linked Drafting	Drafts each report section using the practice's own approved reports as worked examples, with every sentence traced back to the value that supports it.

CS-005_Clinical_Report_Automation_Tool image 3

Figure 2 - Where identifiers are protected: direct patient identifiers are withheld from the AI while it writes and reattached only in the finished, clinician-approved document.

Design note Three AI model routes were evaluated: a managed model (Vertex AI, HIPAA-eligible, recommended for its written-interpretation strength), a managed alternative (AWS Textract plus Bedrock), and a self-hosted model as a cost-saving route where document layouts are consistent - suited to extraction, with a managed model still preferred for written interpretation.

ENGINEERING FOR SCALE AND RELIABILITY

Several design decisions shape whether a clinical documentation tool is trustworthy enough for a clinician to actually approve its output.

Deployed inside the client's own cloud environment

the application runs inside the client's own cloud project, so the practice owns the environment and can revoke access at any time, with Google Drive remaining the store of record for uploads and generated reports.

Reports are queued, not processed on the spot

a report takes minutes to generate, so work is queued, retried, and never silently lost rather than tying up a live web request.

The AI sits behind an abstraction layer

any underlying model can be swapped without touching the rest of the system, keeping the practice from being tied to a single AI vendor's roadmap or pricing.

Minimum necessary data reaches each component

direct patient identifiers are removed before anything is sent to the AI and reattached only when the finished document is written into the template, applying the HIPAA minimum-necessary principle architecturally rather than as a policy statement.

The two-stage extraction design is already proven

the same segment-then-validate approach used on Pfactorial's related structured clinical data extraction work - isolating the relevant section before extraction, then validating every field afterward - was carried into this design rather than invented fresh.

Boundary detection for multi-document uploads is reused, not rebuilt

where an upload contains multiple documents run together, the page-boundary technique from Pfactorial's related medical document boundary detection project decides document continuity rather than requiring a new detector.

DELIVERY APPROACH

The proposed engagement runs eight weeks from contract, with six achievable if sample files, templates, and signed agreements are ready on day one.

1. Discovery and validation - review the client's actual documents, templates, and workflows to validate the pricing and scope assumptions before development begins.

2. Architecture and data-protection design approval - finalize the security approach, HIPAA-eligible service configuration, and Business Associate Agreement setup before any build starts.

3. Build the extraction and record layer - implement format-aware reading, boundary detection, field extraction, and the checked-record validation logic.

4. Build the template-filling layer - map the client's PowerPoint and Word templates once, then implement in-place filling that preserves all formatting.

5. Integrate storage and review workflow - wire up the Google Drive folder structure per patient and visit, and the clinician approval step before a report is considered final.

6. Review and acceptance testing - validate the tool against real sample visits with the client's clinicians before handover.

RESULTS AND IMPACT

CS-005_Clinical_Report_Automation_Tool image 4

Figure - Key outcomes from this engagement.

In the design's worked reference example, an eight-file visit upload - MRI report, two blood panels, a DEXA scan, a genomic panel, a prior protocol, and dictated notes - is sorted, read by the correct reader per format, and roughly 180 clinical values are extracted, with a unit mismatch between two lab panels caught and flagged rather than silently resolved.

The same worked example produces a drafted deck and treatment protocol within minutes, arriving at the clinician's desk with any uncertain items already highlighted for confirmation rather than buried inside an unreviewed document.

What it enabled commercially

If delivered as scoped, the tool removes the manual collection, copying, and formatting work between a patient visit and a finished report, letting clinicians spend that time on patient care while every generated document still requires their explicit approval before use.

WHY PFACTORIAL

This engagement draws on Pfactorial's applied research and compliance capability: structured clinical data extraction, multi-document boundary detection, and de-identification techniques proven on prior delivered work, applied here to a documentation workflow that keeps a clinician as the final check on every output.

CS-005_Clinical_Report_Automation_Tool image 5

Figure - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with clinical and healthcare teams looking to automate documentation without compromising clinician oversight or data protection. If you are evaluating a similar clinical documentation or extraction workflow, we are happy to give you an honest read on scope, cost, and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.