Claims processing · Production

Ricoh builds a scalable intelligent document processing platform on AWS for healthcare clients

The problem

Ricoh's healthcare document processing relied on bespoke engineering per customer, with each deployment requiring unique development, custom prompt engineering, model fine-tuning, and integration testing that could not be reused—consuming 40–60 hours of developer time per customer setup. With an anticipated sevenfold increase in document volume, these bottlenecks limited expansion. Strict compliance requirements (HITRUST, HIPAA, SOC 2) further constrained AI innovation.

First attempt

A simple API call to Amazon Bedrock—sending a scanned document alongside a prompt—was insufficient for complex multi-part healthcare documents. Template-based extraction also proved ineffective given the high variability in layouts, naming conventions, and document structures across healthcare providers.

Workflow diagram · grounded in source
1
Document ingestion via S3
Trigger
Healthcare documents enter the system through Amazon S3, triggering event-driven processing workflows.
▾ source quote
“Documents enter using Amazon Simple Storage Service (Amazon S3), triggering event-driven workflows”
2
AI document classification
Ai action
Lambda functions invoke Amazon Bedrock models to classify documents as claims, appeals, faxes, grievances, prior authorization requests, or clinical documentation.
▾ source quote
“AWS Lambda functions invoke Amazon Bedrock models to determine document types such as claims, appeals, faxes, grievances, prior authorization requests, and clinical documentation”
3
Document splitting and routing
Routing
LLMs intelligently split multi-document packets based on provider or patient information.
▾ source quote
“the team used LLMs to intelligently identify document types and split multi-document packets based on provider or patient information”
4
OCR and AI-powered extraction
Ai action
Amazon Textract parses text and layout, and the results are combined with Amazon Bedrock models for structured data extraction.
▾ source quote
“Amazon Textract parses text and layout, and the results are combined with Amazon Bedrock models for structured data extraction”
5
Confidence scoring validation
Validation
Confidence scores are calculated for each extracted field, and fields scoring below customer-defined thresholds are flagged for human validation.
▾ source quote
“Fields scoring below customer-defined thresholds (typically 70–85%) are flagged for human validation”
6
Human review of low-confidence fields
Human review
Human reviewers verify extracted data, correct errors, and validate that critical healthcare information meets quality standards for regulatory compliance.
▾ source quote
“Human reviewers verify extracted data, correct errors, and validate that critical healthcare information—such as member IDs, diagnosis codes, and claim amounts—meets the quality standards required for regulatory compliance alignment and claims processing”
7
Output storage and feedback loop
Output
Final outputs are stored in Amazon S3, with human corrections providing feedback that improves future processing.
▾ source quote
“Final outputs are stored in Amazon S3, with low-confidence cases routed for human validation through review queues where operators verify extracted data, correct errors, and provide feedback that improves future processing”
Reported outcome

Ricoh reduced customer onboarding time by over 90% (from 4–6 weeks to 2–3 days) and cut engineering hours per deployment by over 90% (from ~80 hours to under 5 hours).
Monthly throughput is projected to grow sevenfold to over 70,000 documents. The solution achieves 98–99% extraction accuracy while reducing manual review costs by 60–70% compared to fully manual processing, with annual savings exceeding 1,900 person-hours.

Reported metrics
Customer onboarding time4–6 weeks to 2–3 days, >90% reduction
Engineering hours per deployment~80 hours to <5 hours, >90% reduction
Monthly document throughput~10,000 to >70,000 documents, 7-fold increase
Processing spike capacity1,000 documents in minutes
Show all 9 reported metrics
Customer onboarding time4–6 weeks to 2–3 days, >90% reduction
Engineering hours per deployment~80 hours to <5 hours, >90% reduction
Monthly document throughput~10,000 to >70,000 documents, 7-fold increase
Processing spike capacity1,000 documents in minutes
Extraction accuracy98–99%
Manual review cost reduction60–70%
Annual person-hours savedexceeding 1,900 person-hours
Context-aware prompting accuracy improvement15–20%
Developer setup time per customer (pre-modernization)40–60 hours of developer time per customer
Reported stack
Amazon BedrockAmazon TextractAWS LambdaAmazon S3Amazon DynamoDBAmazon SQSAmazon EventBridgeAWS KMSAmazon CloudWatchAWS CloudTrailAWS CloudFormationAWS SAMIDP-CommonOCR
◆ Does this fit your context?

Compare to your context

Tell us your scale, team, and constraints. We'll show what changes at your size, what fails at your scale, and whether this case is a fit, needs adaptation, or won't scale to you. Free demo, no signup.

Compare to your context →
~30 seconds · free
Source
https://aws.amazon.com/blogs/machine-learning/how-ricoh-built-a-scalable-intelligent-document-processing-solution-on-aws?tag=soumet-20
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

Ricoh reduced customer onboarding time by over 90% (from 4–6 weeks to 2–3 days) and cut engineering hours per deployment by over 90% (from ~80 hours to under 5 hours).

What tools did this team use?

Amazon Bedrock, Amazon Textract, AWS Lambda, Amazon S3, Amazon DynamoDB, Amazon SQS, Amazon EventBridge, AWS KMS, Amazon CloudWatch, AWS CloudTrail.

What results were reported?

Customer onboarding time: 4–6 weeks to 2–3 days, >90% reduction; Engineering hours per deployment: ~80 hours to <5 hours, >90% reduction; Monthly document throughput: ~10,000 to >70,000 documents, 7-fold increase; Processing spike capacity: 1,000 documents in minutes (source-reported, not independently verified).

What failed first in this deployment?

A simple API call to Amazon Bedrock—sending a scanned document alongside a prompt—was insufficient for complex multi-part healthcare documents.

How is this claims processing AI workflow structured?

Document ingestion via S3 → AI document classification → Document splitting and routing → OCR and AI-powered extraction → Confidence scoring validation → Human review of low-confidence fields → Output storage and feedback loop.

Related claims processing cases

WHAT TO DO WITH THIS

Now compare it to your context

This case is one data point. Whether its pattern fits you depends on your volumes, your stack, and your exception load — that comparison is the step no case study can do for you.

Browse the Claims processing cases →