One Accountable Engineering Partner
Many FDA tasks. One complete software-evidence workstream. You keep ownership of the product and submission. ESL owns the execution of the software analysis, remediation, testing, and evidence tasks in scope.
The Platform in One Sentence
ESL FDA AI Device Intelligence is the only free public platform that combines semantic search of every FDA-authorized AI medical device with live regulatory risk monitoring - recalls, adverse events, and warning letters - plus cybersecurity evidence analysis and IEC 62304 risk classification.
It transforms FDA's opaque approval database into actionable intelligence for patients, clinicians, and device manufacturers, while positioning ESL as the go-to consultancy for FDA software evidence and regulatory remediation.
Right-Sized to Your Submission
Not every product needs every activity. ESL identifies the applicable scope with your team - then performs only the work needed.
End-to-End Remediation
A long finding list does not help a submission. ESL closes the engineering loop: find it, understand it, fix it, prove it.
Engineers Who Fix, Not Reassign
Source is repaired by experienced engineers - not merely reassigned back to your team. Before/after evidence is retained.
Four Software-Evidence Services. One Engagement.
Combine SBOM, CVE remediation, static analysis, code repair, unit tests, coverage, and ALM traceability - or take only the individual service you need.
SBOM Reports - Even From Binaries Only
- • Machine-readable SBOM plus human-readable inventory
- • Known-vulnerability correlation, incl. binary-only discovery
- • Applicability analysis, remediation & documented rationale
- • Rescan after changes, residual status made explicit
Static Code Analysis - and Actual Fixes
- • Rules & severity profile tuned to language and policy
- • Findings triaged: defects, deviations, false positives
- • MISRA C/C++, CERT C/C++, CWE & project rules
- • Final scan & disposition tied to controlled baseline
Unit Testing and Structural Coverage
- • Risk-appropriate test strategy & acceptance criteria
- • Harnesses, stubs, mocks & target communication
- • Statement, branch, condition & MC/DC where appropriate
- • Uncovered / dead-code analysis with documented disposition
Requirements-to-Test Proof in Your ALM
- • Requirements & risk controls mapped to test levels
- • Executed tests exported into the ALM with results
- • Traceability from requirement through tests to code
- • Gaps & progress visible in dashboards & matrices
Find It. Understand It. Fix It. Prove It.
ESL closes the engineering loop for both source-code defects and software-component vulnerabilities - one repeatable remediation workflow.
Discover
Scan source, builds, dependencies, containers, firmware, and binaries.
Triage
Remove noise, confirm applicability, classify impact, prioritize against risk.
Remediate
Fix code defects; upgrade, replace, or patch vulnerable components.
Verify
Rebuild, rescan, retest, and run regression checks.
Evidence
Record tool versions, findings, dispositions, results, and traceability.
One ESL Team. Two Specialized Evidence Pillars.
Use only the evidence activities your device, risk, and submission require.
SBOMator™
Developed by ESLFDA-focused software supply-chain evidence
- • Source, package, container, firmware & binary-only analysis
- • CycloneDX SBOM, VEX decisions & CVSS v4.0 context
- • CVE applicability review, remediation & cleaner reports
- • Section 524B evidence mapping & postmarket monitoring
- • HBOM, FPGA & DataBOM evidence where applicable
Parasoft C/C++test
Represented by ESLIEC 62304-focused verification evidence
- • Static analysis with defect triage & source-code remediation
- • Automated and engineer-authored unit testing
- • Statement, branch, condition & MC/DC coverage
- • Requirements-to-test traceability & ALM integration
- • TÜV SÜD-certified for use in IEC 62304 development
Complementary roles: SBOMator produces software-composition and cybersecurity evidence. Parasoft produces source-code verification evidence. ESL connects both to the controlled build, requirements, tests, findings, fixes, and release baseline. The manufacturer owns the regulatory decision; ESL supplies the engineering execution and objective evidence behind it.
From Scattered Findings to a Controlled Baseline
What changes when ESL owns the software-evidence execution.
✗Before ESL
- • Unknown components
- • Noisy findings
- • Unowned defects
- • Incomplete tests
- • Disconnected evidence
✓After ESL
- • Controlled baseline
- • Remediated findings
- • Repeatable tests
- • Reviewed reports
- • Explicit residual risk
Proof - Not Just Claims
Real, verified case studies from ESL's FDA and Parasoft engagements.
Inovytec Ventway Sparrow - FDA 510(k) with Parasoft C/C++test
Before ESL
- • Embedded ventilator software needed FDA 510(k) compliance with no static analysis baseline
- • No customized rule set mapped to FDA 510(k) certification requirements
- • Code quality issues hidden across the embedded C/C++ codebase
After ESL
- • ESL deployed Parasoft C/C++test with FDA 510(k)-customized static analysis rules
- • Every Ventway Sparrow release now runs Parasoft static analysis configured to FDA regulation definitions
- • 100% of FDA 510(k) certification rules and guidelines passed
Result: FDA 510(k) certification achieved. Parasoft C/C++test became the testing solution of choice at Inovytec, with ESL providing ongoing local support as Parasoft’s authorized Israeli distributor.
When Code Coverage Becomes an FDA Issue - Five Enforcement Cases Decoded
Before ESL
- • FDA Warning Letter (Xoran, 2024): coverage not tied to software risk - three corrective responses rejected as inadequate
- • Medtronic PMA deficiency: branch coverage and configuration-specific testing questioned - FDA asked which branches, which config
- • Medtronic dead-code review: 100% reported coverage but FDA challenged dead code, ROM/RAM variants, and timing effects underneath
After ESL
- • ESL deployed Parasoft C/C++test module-by-module on-target instrumentation - overhead bounded by single module, not full firmware
- • Risk-tiered coverage: MC/DC for safety-critical modules, branch for moderate-risk, statement for low-risk - exactly what FDA expects
- • Coverage aggregation: unit, system, host, and manual test coverage merged into one unified project report
Result: ESL’s approach transforms code coverage from a percentage chase into a defensible regulatory argument: what was tested, what was not, why the gaps are acceptable, and how evidence maps to software risk. Demonstrated on SensorDemo with 29 auto-generated tests finding real defects - the kind of evidence package that answers FDA questions before they are asked.
Who You Work With
Daniel (Dani) Liezrowice
CEO & Co-Founder, Engineering Software Lab (ESL)
22+ years leading 250+ projects in static code analysis, dynamic testing, unit testing, code coverage, and compliance-driven software quality initiatives. Background spans embedded software, enterprise-scale C/C++/Java applications, and regulated industries across virtually all major host and target operating systems.
Standards & Frameworks
ESL works against the standards your submission requires.
Source Languages
C, C++, C#, Java, VB.NET, and other stacks through suitable static-analysis, testing, and software-composition technologies.
Execution Targets
Desktop, server, cloud, container, mobile, cross-compiled, and resource-constrained embedded targets - including on-target testing.
Available Artifacts
Full repositories, partial source, package manifests, build outputs, containers, firmware, and binaries. SBOM work does not require a perfect source tree.
Bring ESL the Software - Not a Cleaned-Up Demo
We will build, clean, and connect the evidence. Start with a software-evidence scoping workshop: ESL reviews your intended submission context, software stack, available artifacts, existing tests, and ALM environment - then defines the smallest complete work package needed.
Contact
Built on Open Science
This platform extends an open-source research tool. We credit the original work and are transparent about what we added.
The Foundation: FDA AI Search
Paper: arXiv:2602.00006v1 · Published at ML4H 2025 · Licensed CC BY 4.0
The semantic search engine and device dataset powering this platform originate from FDA AI Search, developed by Arun Kavishwar and William Lotter at the Dana-Farber Cancer Institute, Brigham and Women's Hospital, and Harvard Medical School. Their work introduced an embedding-based retrieval system for the 1,200+ FDA-authorized AI-enabled medical devices, using LLM-extracted features (Gemini-2.5-flash) and MedEmbed-small-v0.1 embeddings with a hybrid BM25 + semantic similarity scoring algorithm.
What ESL Built on Top
Six regulatory-engineering layers added by Engineering Software Lab
Cybersecurity Evidence Layer
SBOM presence detection, §524B cyber-device compliance indicators, and CVE management signals per device - powered by SBOMator™.
IEC 62304 Risk Classification
Automatic Class A / B / C assignment based on device summary analysis, plus FDA device class estimation (Class I / II / III).
Evidence Requirements Mapper
IEC 62304 evidence requirements mapped to each risk class and regulatory pathway - what the submission actually needs.
Submission Readiness Assessment
Interactive 3-step wizard producing a gap analysis and prioritized action plan - not just a search result, but a roadmap.
Consultancy Integration
Verified case studies, scoping-workshop CTAs, and dual-pillar (SBOMator + Parasoft) positioning connecting search to action.
Regulatory Intelligence Workflow
The "Find it. Understand it. Fix it. Prove it." methodology applied to every device - from discovery to evidence.
In short: The original tool helps you find FDA-authorized AI devices. ESL's platform helps you find, understand, assess, and act on them - connecting each device to the cybersecurity, risk-class, evidence, and submission-readiness context that a regulatory submission actually requires.
This platform describes engineering services, not legal or regulatory advice. FDA guidance documents generally contain nonbinding recommendations unless specific statutory or regulatory requirements are cited. Applicable evidence depends on the device, software functions, risk, submission type, and current FDA expectations. ESL does not guarantee FDA clearance, approval, or inspection outcomes. The manufacturer retains responsibility for safety, effectiveness, quality-system compliance, risk decisions, validation, and submissions.