Hey, I'm Shea.

A systems analysis of document intake, indexing, and verification within a multi-system state government environment — based on a real, ongoing workflow I operate within daily at Maine DHHS.

The problem

In high-volume administrative environments, documents rarely move through a single system. A single client record can pass through intake, indexing, and cross-system verification before it's considered complete — and every handoff is a place where things can go wrong.

Metadata indexed incorrectly, records attached to the wrong case, or documents stalled in a queue don't just create rework. In a regulated environment handling protected health information and PII, they create compliance exposure and delay the caseworkers and clients depending on that data being accurate and available. The bottleneck isn't usually one broken system — it's the seams between systems, and the manual judgment calls required at each handoff.

The systems analyzed

• DocuWare — the primary document management system where incoming records (mail, email, and fax) are received, split, and indexed into case files. This is the operational core of the workflow.
• ACES — used both to look up client/case information needed to index a document correctly, and to verify or cross-check the record against the system of record before or after indexing.

I also have working familiarity with Siebel from this environment, though it plays a smaller, adjacent role in this specific document-intake workflow rather than a core one.

Current-state workflow

The diagram below maps the process end-to-end — from the three intake channels through to a finalized case record — with the five recurring bottlenecks identified through direct observation.

Analytical approach

I mapped the current-state process end-to-end to identify exactly where delay and error risk concentrate, rather than treating "backlog" as one undifferentiated problem. That mapping surfaced five distinct, recurring bottlenecks — each of which maps to a specific, low-cost process fix, detailed in the full case study.

Technical next steps: bridging analysis to code

Identifying where and why errors occur is the analyst's job. The next step is building tools that catch them automatically, before they reach a downstream system.

I'm currently building a Python and SQL metadata-validation tool that models this exact problem: it ingests a batch of record metadata, checks it against a defined rule set (required fields, valid formats, likely duplicates), and flags anything that fails before it would be indexed — logging every flag to an audit trail rather than silently passing bad data through. This project is a direct extension of the analysis above: it takes a bottleneck I identified by hand and starts closing it with code.