Work

The Problem

The organization operated a custom application for client records, contacts and transaction metadata alongside a separate document management platform. The two systems had no common identifiers: different naming conventions, inconsistent record numbering and in some cases a single client mapped to multiple workspaces in the document system.

Staff navigated between the systems manually, running searches in both and routing document requests through support staff when records couldn't be located directly. The document platform was the system of record but was operationally disconnected from the application where day-to-day work happened.

What Was Built

An integration layer that resolved entity matches between client records in the operational application and workspace structures in the document platform. The matching logic handled name variations, partial record number matches and the cases where a single client had been set up differently across offices or practice groups.

The integration surfaced document access within the existing application. Users accessed documents directly from the client record without switching to the document platform. The document system remained the system of record; the integration made it accessible from within the existing workflow.

Outcome

Document retrieval moved from a multi-step manual process into the record workflow. The entity-matching work also surfaced data quality gaps between the two systems — records present in one but not the other — which the client used to reconcile both datasets.

The Problem

The client needed to locate documents based on specific language and phrasing rather than structured metadata. Standard search tools index around attributes like assignee, classification and date. They are not designed to find documents that contain overlapping language from a source text, particularly when the relevant content appears in specific sections of lengthy filings. Research that required that kind of language-based matching was going to outside vendors or taking days of manual work per engagement.

What Was Built

A full-text search platform against an indexed document corpus. The interface accepted free-form text — a phrase or technical description — and returned results ranked by language overlap, with source excerpts visible in the results list. Users could paste directly from a source document without reformulating the query into Boolean syntax.

The indexing pipeline separated document sections so relevance scoring weighted primary content differently from background prose. Exact phrase matches in substantive sections ranked above partial matches in introductory or supporting text.

Outcome

Language-based document searches that previously required manual review or outside research firms were handled by the platform. Turnaround on searches dropped from hours to seconds, and the platform returned results on queries that conventional metadata search could not address.

The Problem

A federally-mandated healthcare registry collected, validated and published outcome data covering survival rates, waitlist statistics and center-level performance metrics. The data was published through static reports — structured tables and PDF exports formatted for statistical consumption. The primary users of those reports were patients evaluating treatment options and clinicians comparing center performance, and the static format was not designed for that audience.

What Was Built

A web-based data visualization platform that presented the registry's validated data through interactive charts, filterable views and outcome comparisons. Patients could explore survival curves and compare performance across care centers. Clinicians could filter center-level metrics by time period, patient population and procedure type. All visualizations drew from the same data as the published statistical reports; the platform was a presentation layer on top of existing validated data, not a separate data source.

Display logic for statistical confidence intervals and cohort sizes required explicit design decisions. Results from low-volume centers were flagged or suppressed rather than displayed as equivalent to data from higher-volume centers, where the same chart would carry different statistical weight. The platform also supported a separate patient-facing report format — a simplified view of the same underlying data, with statistical notation removed and the information organized around the questions a patient is likely to bring to it. The clinical and patient-facing views shared the same data pipeline with different rendering logic.

Outcome

The registry's public-facing reporting moved from a manual PDF publication process to a maintained web application. Outcome data that had been accessible primarily to researchers became navigable by patients, families and clinical staff through a public-facing platform.