Restoring Data Integrity Across FDA's Bioresearch Monitoring Program
An automated, nightly reconciliation framework that independently validated every data element moving between three separately owned FDA systems, replacing disputed manual audits with a recurring, objective standard that every team could act on.
Self-Built
Personally Designed & Coded the Framework
100%
Data Elements Validated Each Run
3
System Owners Held Accountable
~1 yr
As Lead Engineer on the Fix
The Challenge
Three Systems, One Set of Dashboards, No Owner for the Corruption
FDA/CDER's legacy application for logging and processing complaints and inspections was partially modernized: core logging moved to the Appian Platform, but reporting and executive dashboards stayed on the legacy COMPLIS system, receiving data from Appian through the RAPID Data Hub integration layer.
Data was corrupted somewhere in that hand-off, and because Appian, RAPID Data Hub, and COMPLIS were each owned by a different team, none of them accepted accountability. Every team could point to its own system working as specified.
CDER's Bioresearch Monitoring Inspection Modernization Initiative spanned interconnected systems: the BIMO Data Broker, COMPLIS, Site Selection Tools, the BIMO Database, and BIMO analytics, across 14 program workflows
Core inspection and complaint logging had moved to the Appian Platform, but executive reporting and dashboards remained on the legacy COMPLIS (MS Access) system, fed through the RAPID Data Hub integration layer
During the multi-system transition, data was dropped, transformed with incorrect rules, and mapped to wrong columns, producing inaccurate reports and dashboards for executive stakeholders
Appian, RAPID Data Hub, and COMPLIS were each owned by a different team, and each maintained its own system worked as specified, so no team accepted accountability for the corruption
OSI and OSIS needed the safety and efficacy data behind regulatory decisions to be accurate, reliable, and interpretable, with no existing mechanism to prove it
Our Approach
Create an Objective Standard Before Assigning Blame
No amount of requirements review resolves a dispute between three teams who each believe their own system is correct. We built the objective, recurring evidence that let each team investigate and fix its own root causes.
Deep-Dive Root Cause Analysis
We traced source, intermediate, and destination data, along with the mapping and transformation rules across all three systems. The real breakthrough was recognizing the blocker wasn't the mismatch itself, everyone already knew about that, it was that no one could tell where in the pipeline the corruption originated.
Framework Design With Business & Technical Stakeholders
Rather than assign blame across three teams that each believed their own system was correct, we worked with both business and technical stakeholders to define the correct mapping and transformation rule for every data point, creating a shared, agreed-upon standard to validate against.
Build the Framework, Hands-On
Designed and personally helped build the BIMO Framework, including a meaningful share of its Java implementation, as a recurring validation layer triggered after each nightly sync and distributing a mismatch report to all three owning teams automatically.
“Everyone agreed the data didn't match. What nobody could answer was where in the pipeline it broke. I designed the framework, and helped write the code, that could answer that for every data point, every run.”
Ashish Nagpal, SME IT Project Manager, FDA BIMO Program
The Solution
The BIMO Framework: Automated, Full-Coverage Reconciliation
We built a standing validation layer that independently re-derives and compares data between source and destination systems, every field, every run.
Cross-System Reconciliation Engine
Independently pulls data from the source system (Appian) and the destination system (COMPLIS), applies the agreed mapping and transformation rules, and compares the two data sets cell by cell.
Personally Engineered, Not Just Architected
The framework's design decisions were mine alone, and I personally wrote a meaningful share of its Java implementation, working alongside our applications developer, rather than handing off a paper design for someone else to build.
Full-Coverage Validation, No Sampling
Every run checks every data element between source and destination, with no sampling. That full-coverage design is what makes the framework's findings defensible and auditable.
Automated Mismatch Reporting
Generates a report of mismatch count, type, and actual values, and distributes it automatically to all three owning teams after every run, no manual compilation required.
Cross-Team Accountability Mechanism
Turned an unowned, disputed data-quality problem into a recurring, objective fact that each team could see and act on, giving Appian, RAPID Data Hub, and COMPLIS owners a shared standard instead of three separate ones.
Modernization Roadmap
In parallel, mapped the legacy COMPLIS (MS Access) schema to a new Oracle-based BIMO database, documenting an ERWIN data model and evaluating DataStax and PostgreSQL as future-state alternatives.
The Impact
One Engineer's Framework Ended a Three-Way Standoff
100%
Data elements validated every run
Every field is independently compared, source to destination, with no sampling
3
Independently owned systems reconciled
Appian, RAPID Data Hub, and the legacy COMPLIS reporting system
Self-Built
Framework design and Java implementation
Design decisions were mine alone; I personally wrote a meaningful share of the code
6
Person delivery team
Program management, business intelligence, database architecture, and applications development
How the reconciliation works
After each nightly sync from Appian to COMPLIS, the framework independently pulls data from both systems, applies the agreed mapping and transformation rules, and compares every data element, cell by cell. The resulting mismatch report, count, type, and actual values, is emailed automatically to all three owning teams every run.
100%
of data elements · every run
3 Teams
act on the same evidence
Cross-Team Accountability in Practice
Appian, RAPID Data Hub, and COMPLIS were each owned by teams that maintained their own systems worked as specified. The recurring, objective mismatch report gave all three a shared fact they couldn't dispute, and the urgency to investigate and fix root causes in their own system followed from that.
A Standing Operational Layer
The framework wasn't a one-time fix. Once deployed, it became a recurring validation layer for ongoing BIMO platform operations, catching new mismatches as systems continued to change rather than requiring another one-off audit.
Technologies Used
The Stack Behind the Solution
Platform & Data
- Appian Platform
- RAPID Data Hub
- COMPLIS (Legacy MS Access)
- Oracle (Modernization Target)
Reconciliation Engine
- Java
- Excel-Based Comparison Workbooks
- Automated Email Distribution
Modernization & Analytics
- ERWIN Data Modeling
- Tableau · QLIK · Palantir Prototyping
- DataStax & PostgreSQL Evaluation
For Federal Program Managers
Federal-Specific Considerations
How this capability gets procured, governed, and sustained in a federal environment.
Procurement Path
This capability was delivered as a technology subcontract through an established federal prime contractor on an active CDER task order. It is available to prime contractors as a data-integrity and modernization subcontract under NAICS 541512 or 541511. Explore teaming →
Data Governance & Auditability
Every reconciliation run is deterministic and repeatable: the same rules, applied to the same data, produce a documented mismatch report every time. That gives contracting officers and system owners a defensible, full-coverage audit trail rather than a point-in-time spot check.
Agency Adoption Lessons
Objective, automated evidence distributed on a recurring cadence succeeded where policy and requirements discussions alone had not. Once each owning team saw the same, undisputed mismatch report every night, each investigated and fixed root causes in its own system.
Have a Similar Challenge?
Whether it's a manual process that needs AI, a legacy workflow that needs modernization, or a compliance requirement that needs architecture. We'd love to hear about it.