What happens to a file from the moment it's uploaded, and what's actually been verified — written for the team evaluating this tool before a pilot.
Overview
NeoAavya Clinical Engine converts Excel-based clinical trial design specifications — forms, fields, code lists — into CDISC ODM v1.3.2 XML and Dataset-JSON. Every export is validated against the official CDISC schemas before it's returned. The engine works with trial structure, not trial subjects: it has no feature that accepts, expects, or is designed to process patient-level data.
Data handling
Most vendors describe one data-handling story. This engine actually has two, and they behave differently — worth knowing which one a given integration uses.
A file is processed in memory and temporary storage, then discarded. Nothing is written to a database. Verified: cleanup runs on every exit path, including errors — not only the success case.
Accounts, saved studies, and review workflows store the converted structural metadata. The original uploaded file is discarded once processing completes — it is not kept alongside the converted output.
On both paths, a structural content check runs on every submission and blocks anything shaped like a patient identifier before it is processed, stored, or sent to any AI provider.
Controls
Every row below was exercised against the running system, not asserted from a diagram. The right-hand column is how.
| Control | What it does | Verification |
|---|---|---|
Tenant isolation | Database-level row security, not just application filtering | Unprivileged role, unfiltered query → zero cross-tenant rows |
Session revocation | Logout invalidates a token immediately, not at natural expiry | Live test: rejected the instant after logout |
Brute-force protection | Login attempts rate-limited per account and per source IP | Live-tested against the running system |
Audit trail | Append-only, hash-chained — tampering is cryptographically detectable. The same control FDA Part 11 and EU Annex 11 both call for | Chain integrity independently re-verified |
Identifier redaction | Blocks identifier-shaped content before it reaches storage or any AI provider | Tested against representative identifier patterns |
Upload limits | Size caps on every file-accepting endpoint | Tested incl. corrupted/malformed files |
Data minimization | Raw uploads auto-deleted once no longer needed | File confirmed present, then confirmed gone |
Schema validation | Every export validated against the official CDISC schema before return | Enforced in code, negative-case tested |
Candor
That process runs 6–12 months and five figures or more — premature at this stage. In its place: full transparency. Our threat model and requirements-to-test traceability matrix are available on request, and every control above is independently checkable in our test suite rather than asserted on trust.
The system is built to reject patient-identifying content structurally, but your organization's upload discipline remains the primary control. This is stated explicitly in the data-handling warranty we ask pilot clients to accept.
Because this product is built to never hold PHI, we haven't built a Business Associate Agreement program around subprocessors — signing one would pull the product into a heavier compliance category it isn't designed to need. Happy to discuss this position directly with your compliance team.
The audit trail above is the substantive technical control both FDA 21 CFR Part 11 (US) and EU GMP Annex 11 (EU) call for, but neither is a certification granted by having the control — both need the surrounding validation, SOPs, and legal review this stage of the product hasn't done yet. We'll say exactly that if asked, not round it up to “compliant.”
Available on request