clinical_nlp.txt

Structuring Clinical Text for AI Readiness

A reference architecture for turning free text clinical documentation into structured, coded data

Discipline: Reference architecture
Domains: Healthcare · AI and Automation
Timeframe: 2026
Status: Reference architecture. Written as a framework and published as analysis, not delivered as a client engagement.

what_was_this_project.txt

What was this project?

Structuring Clinical Text for AI Readiness is a reference architecture I wrote for healthcare organizations that already run a lakehouse platform and want to adopt clinical AI, describing how to make their own documentation machine readable first.

This entry is different from the others in this portfolio. It is not a proposal I wrote inside an organization for a named stakeholder. It is a framework I developed and published, built from the constraints that healthcare data teams keep describing to me and from the peer reviewed literature on clinical documentation.

I am putting it here because the architectural reasoning is the same work as the rest of the portfolio, and because being clear about which pieces are engagements and which are frameworks is part of the point of publishing any of this.

what_problem_did_this_solve.txt

What problem did this solve?

Most of the clinical detail in an electronic health record lives in narrative text that no query can reliably read, so the information exists, cannot be reported on, and blocks every AI initiative that needs structured input.

Progress notes, discharge summaries, and narrative fields carry diagnoses, social determinants, and medication context that never reach a discrete, reportable field. Estimates of how much clinical information sits in free text vary by study and by definition, but the consistent finding is that it is the majority of it.

The immediate cost is visible and boring. Manual chart abstraction. Quality reports that are incomplete because the evidence was in a paragraph. Prior authorizations that take hours because someone has to read.

Reporting gaps: regulatory submissions require discrete codes while the underlying facts exist only as narrative.
Data quality: hypertension, HTN, and high blood pressure mean one thing to a clinician and three things to a database.
Workflow cost: staff spend hours reading charts for audits and authorizations that a structured field would answer instantly.
Interoperability: free text does not map cleanly to FHIR, SNOMED, or ICD-10, so it cannot cross a system boundary intact.

The larger problem sits underneath. Organizations want ambient documentation assistants, risk models, and decision support, and every one of those initiatives needs structured clinical context that these organizations do not yet have.

what_i_observed.txt

What did I observe?

A 2024 systematic review of 129 peer reviewed studies on AI for clinical documentation found that roughly two thirds of the research focused on structuring clinical data rather than on building end to end documentation assistants, which inverts how the market talks about the problem.

That review, by Perkins and colleagues in Perspectives in Health Information Management, frames the burden clearly. Physicians spend between a third and a half of their working day on clinical documentation, an opportunity cost the authors put in the range of 90 to 140 billion dollars annually in the United States alone. The clerical load reduces time with patients and contributes to burnout.

The review also found that while comprehensive AI documentation assistants show promise, error rates remained too high for broad implementation at the time of writing. Some studies reported documentation time reductions of around half, but the gains depended on the underlying data already being structured.

The constraints that shape the architecture are the ones healthcare data teams actually live with:

EHR access is read only. Schema changes to the source system are not on the table, so anything built has to sit downstream.
PHI handling is strict, which makes the order of operations in the pipeline a compliance decision rather than an engineering preference.
Outputs have to be explainable and auditable. A clinician has to be able to ask why a code was assigned and get a real answer.
Whatever is built should run inside the platform the team already operates, because a new environment means a new security review, a new access model, and a new thing to maintain.

The pattern I keep seeing is organizations trying to buy the visible thing, the assistant, while skipping the unglamorous thing that makes it work.

my_role.txt

What was my role?

I researched, designed, and wrote this architecture and the argument around it, and I have not implemented it for any organization.

Reviewed the peer reviewed literature on AI for clinical documentation and identified the split between structuring research and assistant research as the load bearing finding.
Defined the constraint set from the conditions healthcare data teams operate under: read only source access, strict PHI handling, explainability requirements, and existing platform investment.
Designed the layered pipeline, including the specific decision to place de-identification before any machine learning rather than after it.
Made the case for domain specific clinical NLP over general purpose language models for coding extraction, on accuracy and auditability grounds.
Wrote the argument that the unstructured data problem is the AI strategy rather than a prerequisite to be cleared before the AI strategy starts.

To be explicit: no organization has implemented this under my direction. I did not run a pilot, measure an extraction accuracy, or deliver this to a client. Treat it as reasoning, and check the sources.

the_proposed_solution.txt

What was the proposed solution?

The proposed architecture is a layered pipeline that reads clinical text out of the EHR, de-identifies it, applies domain specific clinical natural language processing, and lands structured coded entities in a governed table, all downstream of the source system.

The design refuses two tempting moves. It does not ask clinicians to document differently, because that has been tried for thirty years and loses. It does not wait for general purpose model accuracy to improve, because that is a moving target and the data problem is solvable now.

The processing choice is domain specific clinical NLP rather than a general purpose language model. Healthcare specific models produce traceable output: this entity was extracted from this sentence and mapped to this code with this confidence. That traceability is what lets a governance committee sign off and what lets a clinician challenge a result.

Running it natively on the lakehouse the organization already operates means no separate infrastructure, no data leaving the security perimeter, and lineage and access control inherited from the platform rather than reinvented.

system_design.txt

How was the system designed?

The pipeline moves clinical text through four layers, and the position of the de-identification step between the raw and processed layers is the single most consequential decision in the design.

Raw text is extracted from the EHR through existing paths and landed with audit lineage intact. De-identification masks protected health information before any model runs. Clinical NLP then performs named entity recognition, resolves entities to standard code sets, and detects assertion, meaning whether a finding was present, negated, historical, or attributed to a family member. The result is exposed as analytics ready tables.

Assertion detection is the part people skip and the part that decides whether the output is safe. A pipeline that extracts a condition without detecting that the note said the patient does not have it produces a confidently coded, clinically false record.

Processing is batch, aligned to reporting cycles, because nothing in this workflow needs sub second latency and a batch job that runs reliably beats a stream nobody watches.

Structuring Clinical Text for AI Readiness: system design. The full description is in the diagram's alternative text.

why_this_design.txt

Why was it designed this way?

The architecture is shaped by the constraint that nothing upstream can change, which rules out the entire class of solutions that begin by asking the EHR or the clinician to behave differently.

Design choices and the alternatives considered
Choice	Alternative considered	Why the choice won
Domain specific clinical NLP	A general purpose large language model	Clinical coding is a domain task where a wrong code affects reimbursement and compliance. Domain models also produce traceable extractions with a source span and a confidence, which a general model does not, and auditability is a hard requirement here.
De-identify before any ML	Process first, mask on the way out	Masking on the way out means PHI passed through the model. Doing it first makes the compliance posture a property of the architecture rather than a promise about behaviour.
Work downstream of the EHR	Structured data capture at the point of documentation	Source schema changes were not available, and changing how clinicians document is the intervention with the worst track record in health IT. Enriching after the data leaves the source system is the only lever that is actually in reach.
Run natively on the existing platform	A dedicated NLP environment	Native execution means no data egress, no second security review, and lineage and access control inherited from a platform the team already governs.
Batch processing	Real time extraction	The consuming workflows are reporting cycles and audits. Real time adds operational burden and failure modes to buy latency nobody in this workflow needs.
Assertion detection treated as required	Entity extraction and code mapping only	Without assertion, a negated finding becomes a coded diagnosis. That is not a degraded result, it is a wrong one, and it is wrong in the direction that reaches a patient record.

implementation_plan.txt

How would it be implemented?

The sequencing puts de-identification and a narrow, verifiable extraction task first, so that the compliance question is settled and accuracy is measured on something checkable before scope widens.

Confirm the constraints in the specific environment: read paths out of the EHR, the PHI handling rules that apply, and who signs off on a model touching clinical text.
Stand up ingestion and the de-identification step, and validate the masking on held out text before any extraction work begins.
Pick one narrow, checkable extraction task with an existing gold standard, such as a condition already abstracted manually for a quality measure, and measure against it.
Add entity resolution and assertion detection, and have clinical reviewers audit a sample rather than accepting an aggregate accuracy number.
Expose the structured output to one downstream consumer, and only then widen the scope of what is extracted.

The gate is step three. If extraction accuracy on a task with a known answer is not good enough to trust, the correct decision is to stop rather than to widen scope and hope.

expected_impact.txt

What impact was expected?

There are no measured results for this architecture because it is a framework rather than a deployment, and the figures below are either projections from the design or findings from the cited literature.

Where the value would come from, and how each would be measured
What would change	Baseline today	How it would be measured
Quality reporting stops missing evidence held in notes	Regulatory submissions need discrete codes while the supporting facts are narrative.	Share of a quality measure's numerator captured automatically versus by manual abstraction.
Chart abstraction hours fall	Staff read charts manually for audits and prior authorizations.	Abstraction time per case, compared before and after on the same measure.
Language variation stops fragmenting the data	The same clinical concept appears in several unnormalized forms.	Share of extracted entities resolved to a standard code, and the residual unmapped rate.
Clinical AI becomes possible rather than aspirational	Downstream models lack structured clinical context to consume.	Whether a downstream model can be trained or a decision support rule written on the structured output at all.

On accuracy claims: vendors of clinical NLP libraries publish benchmarks showing their domain models outperforming general purpose language models on coding extraction, sometimes by a wide margin. Those benchmarks are produced by parties with a commercial interest in the result and should be treated as a reason to run your own evaluation, not as a number to put in a business case. That is why step three of the implementation plan is measuring against your own gold standard rather than citing somebody's.

what_happened.txt

What happened?

This architecture was published as analysis rather than delivered as an engagement, so there is no client, no deployment, and no outcome to report.

What it represents is a position: that solving the unstructured data problem is not a prerequisite to be cleared before the AI strategy begins, it is the AI strategy. Organizations keep buying the assistant and skipping the foundation, and then wondering why the assistant does not work.

If you are evaluating this for your own environment, the useful move is to run step three on a task where you already know the answer, and let that decide it.

references.txt

References

Working on something like this?

Bring me the problem before the tool selection.

Schedule a Vibe Check ↗