Solutions · 21 CFR 820 · EU MDR Annex II
OMEGA for Engineering and Assurance
Design controls require traceability between requirement, design decision, and verification. When an AI/ML component is in the loop, the traceability typically breaks at the model boundary. OMEGA closes the boundary.
The traceability gap
Under FDA 21 CFR 820.30 (Design Controls), medical device manufacturers must maintain a Design History File (DHF) demonstrating that the device was developed in accordance with the approved design plan. Under EU MDR (Regulation (EU) 2017/745), manufacturers must compile Technical Documentation per Annex II, evidencing conformity with the General Safety and Performance Requirements of Annex I. Both regimes require traceability from requirement to design output to verification and validation.
For deterministic software the traceability is hard work but tractable. For an AI/ML component - particularly one that adapts post-deployment - it typically breaks. A model is treated as a single design output and a single validation artefact. The continuous link between live model behaviour, the design decision that placed it in the device, and the validation evidence supporting it is rarely captured per-action.
What an OMEGA design-decision record contains
- Authority. The named designer or design-review authority who took the decision (
P1), within their delegated scope (P6). - Reasoning. The evidence considered - user need, intended use, risk analysis output, prior validation - and the alternatives rejected, as a directed-acyclic graph (
P2,P2_DAG). - Expectation. The expected outcome of the design decision in terms of device performance and safety (
P4), with the environmental invariants under which that expectation holds (P4T_EnvInvariant) - e.g. the population the model was trained on, the input-distribution envelope, the intended-use boundary. - Materiality. The risk-class consequence of the decision is bound to its authority scope (
P4M, Materiality Binding). A high-risk decision cannot be made under a low-risk authority. - Expectation update integrity. When the model is retrained or the device is updated post-market, the expectation must be updated under controlled change-management (
P11). Silent drift between the model the regulator approved and the model in the field is detectable. - Chain integrity. The design history cannot be silently rewritten (
P_ChainIntegrity).
Substantial equivalence and clinical equivalence
For FDA 510(k) submissions, devices may demonstrate Substantial Equivalence to a legally marketed predicate device. For EU MDR, clinical evaluation under Article 61 may rely on equivalence to another device. In both regimes, when an AI/ML component is involved, the equivalence claim depends on the model's input envelope, training population, and intended use remaining bound to the predicate or equivalent device. P11 (Expectation Update Integrity) records each post-market change to the expectation, so the equivalence claim either remains live or is explicitly withdrawn - not silently invalidated by a model update.
Worked example: AI-assisted diagnostic recommendation
Scenario. A Class IIa software-as-a-medical-device (SaMD) provides AI-assisted recommendations for prioritising radiology worklists. Eighteen months post-launch the manufacturer plans a model retrain on a broader population. A notified body audit asks for the design controls evidence supporting the retrain decision and its impact on the original conformity assessment.
Conventional response. The manufacturer produces the original Technical Documentation, the post-market surveillance report, and the retrain plan as separate documents. The continuous link between the original design decision, the live model behaviour, and the planned change is reconstructed from emails and a tracker.
OMEGA record series. The original design decision is recorded with P1 (design authority), P4 (expected sensitivity and specificity), and P4T_EnvInvariant (the patient population envelope). Each post-market surveillance review produces a record bound to the same decision under P11. The retrain decision is itself a governed record - P1, P10 (the validation team's competence attestation), P11 (the explicit update to the expectation), and a chain-of-custody link to the original record. The notified body sees one ordered chain, not a folder of documents.
What this does not do
OMEGA does not substitute for verification and validation. It does not establish that the model is clinically safe, that the risk analysis is complete, or that the device meets its intended use. It produces the artifact a notified body assessor or FDA reviewer can map to the regulatory requirement - binding the design decision, the named authority, the expected outcome, and the live device behaviour into one chain.
See the medical device example record · Why a log is not a governed record · Read the specification · Run the proof · All solutions