Armakuni Contact us
← All case studies

One patient's history could run to 2,000 pages,
much of it the same visit written down again.

A U.S. clinical-data company turns long, inconsistent patient records into structured information for clinicians, and some histories ran to 2,000 pages with the same history repeated across visits. We split extraction into 12 medical data types, each with its own rules, found the repeated material, and connected the structured results, summaries and search back to the source page.

Before

Hundreds of documents per patient, and no template.

Clinical data needs clinical checking.

After
95%fewer duplicate entries
Up to 95%extraction accuracy, with review
40%faster access to structured records

As the company reported.

Hundreds of documents per patient, and no template

The company's product depends on turning patient records into structured clinical information: medications, vital signs, consultations and clinical notes. The records arrived as long, inconsistent collections of notes, prescriptions and visit documentation from many different providers, with no fixed format. A patient could have hundreds of documents, some over 20 pages, adding up to 2,000 pages.

Some records left out whole sections, and others repeated historical material across every visit. That repetition cluttered the record and made the work slower, and removing it by hand took real time.

Clinical data needs clinical checking

Quality assurance on medical data needs domain knowledge, and at the start, review was manual and intensive. Any automated approach had to keep that review in the loop, and make it faster, not skip it.

Split the record by what it contains

The turn was to stop treating a patient history as one document. Split it by the kinds of clinical information the product needs, so each section gets its own extraction logic and its own review, and so a missing section is just a missing section, not a failure.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Twelve medical data types, twelve sets of rules
  2. Every answer traceable to its page
  3. Review alongside the people who know the medicine

Twelve medical data types, twelve sets of rules

Built withBedrockS3KMSECSFastAPILangChain
One record MedicationsVital signsConsultations… 12 types each type with its own rules; repeats flagged
The engineering
  • Bedrock-based prompts process the 12 medical segments independently, including medications, vital signs, consultations and clinical notes.
  • Section-specific business logic handles format variations and missing sections without forcing one template onto the whole record.
  • Deduplication identifies historical material repeated across documents and visits, keeps the relevant information and flags likely duplicates for review.
  • S3 stores source documents, encrypted with KMS, with containerized processing on ECS and a Python/FastAPI application layer, all held to HIPAA standards.

The architecture can evaluate different model options, Claude among them, without tying the whole application to one provider. That model-agnostic design on ECS mattered when new model families appeared mid-project and the company wanted to know it could switch. LangChain and LangGraph handle orchestration, and queued processing on SQS keeps document work apart from interactive requests.

Why: a model asked for "everything" from 2,000 pages misses things, and one asked for a single data type, with rules for that type, can be tested type by type.

Every answer traceable to its page

Built withOpenSearch
A questionThe answerThe page it came from
The engineering

A conversational interface lets healthcare professionals ask patient-specific questions and see both summaries and deeper search results. OpenSearch vector retrieval supports that, with traceability back to the source document, so a clinician can check any statement in the original.

Review alongside the people who know the medicine

Duplicates flaggedA specialist checks, page open
The engineering

The customer's domain specialists reviewed real examples and worked with us on extraction changes as new document patterns appeared. Review covers uncertain fields and suspected duplicates, with the source on hand to tell a redundant entry from relevant clinical history. Through that review, the QA team built its own medical domain knowledge.

One patient history, end to end

  1. A patient's records arrive: hundreds of documents, some 20 pages long.
  2. The pipeline splits them into the 12 data types. Medications go to the medication rules, vital signs to theirs.
  3. A section that's missing is simply missing, without breaking the rest.
  4. Deduplication finds the same history repeated across many visits, keeps it once and flags the rest for review.
  5. A clinician asks: what medications has this patient been on in the last year?
  6. The answer comes with links to the pages it came from.

What we'd tell another CTO

1Split long records by data type, so each type gets rules that can be tested on their own, and treat missing sections as normal, because medical records are incomplete. Deduplicate before you summarize, since repeated history skews every summary.
2Make every answer traceable to its page, because clinicians need to check rather than trust, and review with domain experts, whose knowledge grew with the system.

What else changed

As the company reported.

  • 95% of clinical-note summarization automated.
  • A conversational interface with summaries and search traceable to the source.
  • A pilot release, with more enhancements planned around new document patterns and review findings.

What comes next

More enhancements in a later phase, built around the document patterns and review findings from the pilot.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

Each of the 12 data types would get its own golden set of pages with the right extraction, reviewed by clinicians, plus a sealed set nobody tunes to, with a wrong medication as a critical case that must pass on every run. The HIPAA evidence would come from the controls as they run, and for each model endpoint we'd agree what is kept, for how long and whether it may be used for training.

Across 2,000-page records most pages are routine, so AI Inference Engineering would send them to a model the company owns on Amazon SageMaker AI, at about a tenth of the price, with the hard ones on a frontier model through Amazon Bedrock and the model and the data in the company's own account.

Modernize with AI AI Inference Engineering AK AI Factory

More work like this

  1. AI10–50×A U.S. health-data platformfaster answers when a question repeats, as reported"Is this drug covered?" was asked again and again. Each time, it paid for a fresh model call.30–40% lower cost on model processing90% less backend load from file transfersOn AWS Nova Pro · ECS · CloudFront · Bedrock
  2. AI~90%An ad-intelligence businesslower infrastructure costTwenty-four hours of stream. About thirty minutes worth keeping.~95% less video stored~20 minutes a run, down from 30 to 40On AWS Lambda · Bedrock · S3 · SQS
  3. AI2–3 minutesA U.S. psychology organizationper document, where it took about 3 hours, as reportedFinding one psychological test in a paper took an expert three hours.~$0.10 a document, where specialist time cost $100 an hour>90% fasterOn AWS Lambda · Bedrock · SageMaker · OpenSearch

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop