From System Description to Lifecycle Control: Building the Evidence Architecture for Complex Medical Devices

Executive premise

The failure is in the connections, and it is specific enough to name. A hazard is identified in the risk file but never converted into a design input with an acceptance criterion. A worst-case test condition is selected but the justification for why it is worst case lives in someone's memory rather than in the protocol. Software verification proves the software works but never demonstrates that the integrated system behaves safely when a subassembly faults. A training program exists but the evidence that it produces competent users does not. A labeling claim survives three review cycles without anyone tracing it back to the specific test that supports it.

None of those gaps are visible while the evidence sits in functional silos. Each function can defend its own artifact. The gap only appears when someone tries to traverse the chain, which is exactly what a reviewer does.

This is what evidence architecture means. Not more documentation. A designed set of connections among the documentation you already produce, built so that any claim can be traced backward to the system behavior that justifies it, and any system change can be traced forward to every piece of evidence it invalidates.

FDA's newest draft guidance for robotically-assisted surgical devices is an unusually explicit map of what those connections look like when a device is genuinely complex. It was written for one device category. The architecture it implies is worth reading by anyone building a device where software, mechanics, users and service life all interact.

What FDA issued

On September 25, 2026, FDA announced the availability of a draft guidance titled Robotically-Assisted Surgical Devices, Premarket Submissions, issued by CDRH through the Division of General Surgery Devices. The Federal Register notice assigns docket number FDA-2026-N-9505. The comment period closes November 24, 2026.

This guidance is draft. It is not final, it is not for implementation, and it contains nonbinding recommendations. It reflects FDA's current thinking. It does not establish legally enforceable responsibilities and it does not create rights for any person. Nothing in it is a compliance expectation today, and nothing in this article should be read as saying otherwise.

Scope. The draft addresses non-clinical testing, clinical data and labeling content for premarket submissions for robotically-assisted surgical devices, which it describes as teleoperated, software-controlled systems operating under direct practitioner control in a leader and follower architecture, with optional automated functions, used to assist qualified practitioners in precisely positioning and controlling surgical instruments during open, minimally invasive or endoluminal procedures.

What the draft places outside its scope. This matters as much as what is inside it. Per the draft, the guidance does not cover pre-operative planning systems or stereotaxic systems, RASDs that assist in the placement or use of interventional devices such as interventional catheters, remotely teleoperated systems where the operator is not in the same operating room, or autonomous robots performing procedures independent of a practitioner. For devices outside scope, the draft recommends engaging FDA through the Q-Submission Program.

Source boundary, stated plainly. Everything attributed to FDA in this article comes from that draft guidance and its Federal Register notice. Those recommendations apply to the device category the draft names. They are not general requirements for medical devices, and this article does not claim they are.

What is Bayou Vantage analysis. The evidence architecture framing, the executive evidence ledger, the 30-day diagnostic, and the argument that these connections generalize beyond robotic surgery are ours. FDA has not reviewed, endorsed or adopted any of it. Where this article reads a general principle out of a category-specific recommendation, it says so.

Why a robotics draft is worth reading outside robotics. Robotically-assisted surgical devices sit at an unusual intersection. They are mechanical systems with meaningful force and motion. They are software systems with enhanced documentation expectations. They are networked systems with cybersecurity obligations. They are reusable systems with reprocessing and service life constraints. They are used by teams rather than individuals, under time pressure, with emergency scenarios that have to work. Few device categories carry all of those at once, which is why a guidance written for them ends up being an unusually complete description of how evidence has to interlock. If your device carries three of those five characteristics, the connection pattern is instructive even though the specific recommendations are not yours.

Begin with the system

The first structural point in the draft is that the device description is not an introduction. It is the map everything else is indexed against.

FDA describes RASDs in terms of three subassemblies: an operator console where the practitioner views the surgical field and controls instruments and cameras remotely, a bedside or patient subassembly, a cart or pedestal carrying the sterile to nonsterile interface and the working arms that control instruments and cameras, with controls accessible to surgical assistants, and an OR staff subassembly, typically a tower holding electrosurgical generators, pumps, secondary displays, insufflation and light sources.

For submission content, the draft recommends a whole-system overview supported by kinematic diagrams and connections diagrams, physical dimensions, a representation of data transmission, detailed functional descriptions of each subassembly, and identification of safety features with their specific locations. For 510(k) submissions it recommends identifying technological characteristics not present in the predicate. It also recommends videos demonstrating user interfaces and novel features.

Read that list again for what it implies rather than what it requires. FDA is asking for the system to be described in a way that makes every later claim addressable. A kinematic diagram is not decoration. It is the thing that lets a reviewer ask whether the reachability testing covered the actual workspace. A data transmission representation is what lets a reviewer ask whether the cybersecurity assessment covered every path. Safety feature locations are what let a reviewer ask whether the emergency access testing was performed where the emergency would actually occur.

Bayou Vantage analysis. Three tests for whether your system description is doing this job:

Can every test protocol name the subassembly and interface it exercises? If protocols reference the device generically, the description is not being used as an index and coverage gaps will not be visible.

Does the description account for what crosses the boundary? External services, cloud infrastructure, hospital network dependencies, third-party generators and instruments, and data that leaves the device are all part of the system for evidence purposes even when they are not part of the product you manufacture. The draft's cybersecurity section makes this explicit for RASDs by extending assessment to back-end infrastructure and public and private networks.

Is there one description, or several? Most organizations have a marketing description, a regulatory description, an engineering architecture and a risk file scope statement, and they do not fully agree. Divergence among them is where traceability breaks, because each downstream function is indexing against a different map.

Convert risk into testable control

The gap that matters most in complex device evidence is between a hazard that has been identified and a test that proves it is controlled. Organizations are generally good at the first and inconsistent at the second.

The draft's framing principle is direct: non-clinical performance test conditions should simulate the worst-case conditions the device is likely to encounter during clinical use.

That sentence does more work than it appears to. It makes worst case a clinical question, not an engineering convenience. The burden is to show that the condition tested is the condition the device will actually meet at its most demanding, which requires knowing the use environment well enough to argue it.

The RASD-specific use-related hazards the draft directs manufacturers to address are worth listing, because they show how far upstream and downstream FDA expects the hazard analysis to reach:

• Surgical planning, instrument preparation and system connection procedures

• Device reprocessing

• The effect of user inexperience with robotic technology

• Negative knowledge transfer from experience with a competing RASD

• Instrument removal, instrument exchange and port switching

• Interaction between the surgeon and the surgical team during operation

• RASD motions interfering with staff workflow or with emergency access to the patient

Negative knowledge transfer is the one to sit with. FDA is naming a hazard that originates entirely outside your device, in a competitor's interface conventions, and asking that it be addressed. That is a hazard analysis boundary well past the device housing.

The draft also sets expectations for what a complete test report contains: the test objective, methods and procedures, sample size, predefined pass and fail criteria with clinical justification, justification for the specific instruments used, results, conclusions, and for 510(k)s an explanation of how the results support substantial equivalence.

Bayou Vantage analysis. The connection you are building runs hazard, then design input, then acceptance criterion, then test condition, then result, then residual risk conclusion. Four failure modes break it:

• The orphan hazard. Identified, assigned a control, and the control is a procedure or a labeling statement with no verification that it works.

• The unjustified criterion. A pass and fail threshold with no clinical basis, typically inherited from a prior product or a standard that was not written for this use.

• The convenient worst case. A test condition selected because it was achievable on the bench rather than because it represents the clinical extreme, with no documented rationale either way.

• The unlinked result. A test that passed, filed in a report, never connected back to the hazard it was meant to close.

Predefined is the operative word in FDA's report expectation. Acceptance criteria written after results are known are not acceptance criteria.

Integrate digital and physical evidence

Complex devices fail at the seams between disciplines. The draft's non-clinical testing content is, read as a whole, an argument that mechanical, software, network and visual evidence have to be reconciled at the system level rather than proven separately.

Teleoperation and latency. The draft addresses total system latency measured from hand input through instrument motion to visual feedback, evaluated under maximum processing loads and typical configurations, with testing on a minimum of three units unless otherwise justified. It addresses verification of real-time feedback sufficient for safe performance, and characterization of motion enhancement functions such as motion scaling and tremor reduction across their full operational range.

The minimum of three units is a quiet but significant point. It is an acknowledgment that a single unit's performance is not evidence about a manufactured population.

System controls. Stability under disturbances and fault conditions, emergency removal procedures ensuring timely patient access, safety stop functionality and fail-safe transitions, and fault detection, response and recovery.

Kinematics and dynamics. Accuracy, repeatability and resolution on a minimum of three units, workspace verification with safety mechanism validation, reachability across the extremes of the intended patient population including BMI and anatomical variation, instrument articulation range at both the beginning and the end of use life, velocity limits across all movement axes, position tracking with error detection, collision detection and avoidance across full operating conditions, singularity identification and mitigation, and physical stability under clinical disturbances.

Articulation range at the end of use life is the item most likely to be missed, because it requires the reliability program and the performance program to share a definition of end of life.

Visualization. Image resolution, distortion, field of view and depth of field, reliability under electromagnetic disturbance, with conformance to IEC 60601-2-18 recommended.

Software. The draft states that RASDs warrant Enhanced documentation under FDA's device software functions guidance unless otherwise justified. It addresses unit, integration and full system-level verification and validation, objective performance metrics representative of real-world use, testing of safety features including notifications and warnings, justification for regression testing of modified functions, impact analysis of changes on affected software units, version control and deployment strategy, traceability linking requirements to design, testing and risk controls, off-the-shelf software documentation, disclosure of open-source and proprietary components, classification of unresolved anomalies with risk prioritization, and mechanisms for communicating mitigations to users.

It also addresses multiple function devices, asking that the impact of non-device functions such as procedure timing or video recording on the core device function be assessed with respect to shared computational resources and data dependencies.

Cybersecurity. Under section 524B, the draft states that submissions should identify all relevant assets, potential threats and vulnerabilities affecting device functionality, end users and patients, together with an assessment of exploitability. The assessment scope it describes reaches all network elements including subassemblies, accessories and compatible devices, back-end infrastructure including servers, databases and cloud services, and the public and private networks used for communication, remote access, teleoperation and system updates. It addresses penetration testing simulating a compromised hospital network.

Wireless and fail-safe behavior. The draft states that RASDs should have fail-safe operation in the event of teleoperation faults, giving cable disconnection and electromagnetic interference as examples, and references AAMI TIR69 and IEEE ANSI USEMCSC C63.27.

Electrical safety and essential performance. The draft asks that essential performance be defined as the device's ability to perform robotic functions accurately within specified limits, and references ANSI/AAMI ES60601-1, ANSI/AAMI/IEC 60601-1-2, IEC 80601-2-77, IEC 60601-2-2 and IEC 60601-2-18.

Bayou Vantage analysis. The integration question to put to your own evidence: which single test demonstrates that the system remains safe when a fault occurs in one domain and the response depends on another? A network interruption that must trigger a mechanical fail-safe. A software fault that must preserve visualization long enough for the user to react. A power loss that must leave the patient accessible.

Those scenarios sit between functional owners, which is why they are the most frequently unowned. In our experience the reliable way to surface them is to build the fault list from the interfaces in the system description rather than from each function's own risk file, because a fault that crosses a boundary belongs to the boundary, not to either side.

Prove performance over time

Evidence that the device works is not evidence that it keeps working. The draft treats durability as its own evidence chain with several distinct strands.

Reliability. Characterization of mean time between failures for repairable systems, or B10, the point at which 10 percent of components have failed, for components. Maintaining control over surgical instruments across service life. For grip and cutting functions, 95 percent reliability with 95 percent confidence, with justification required for any different level. Worst-case loading conditions for grip testing and clinically justified material selection for cutting testing. Quantification of jaw failure in terms of the force required and the number of cyclic fatigue cycles to failure. Shaft structural integrity under worst-case loading.

Service life and use life. The draft asks that manufacturers define and demonstrate safe operation across the specified service life of the system and the use life of reusable instruments. As noted above, it also asks for instrument articulation range at the end of use life, not only at the start.

Sterility. Sterilization method description with validation data, a sterility assurance level of 10 to the minus 6 for devices contacting tissue or 10 to the minus 3 for devices contacting intact skin only, and sterilant residual limits with justification for chemical methods, referencing ISO 10993-7 for ethylene oxide.

Reprocessing. The draft states that validated instructions for reprocessing a reusable device, or a single-use device supplied non-sterile, are critical. It addresses validated cleaning, disinfection and sterilization between uses, ultrasonic washing or a validated equivalent for components with small lumens or difficult-to-reach surfaces, flushing instructions for inner surfaces, validation of automatic washer-disinfectors using the identical equipment and cycle specified in labeling, testing under real-world and simulated use conditions with adequate soiling technique, visual inspection at 10x magnification to confirm adequate cleaning, and performance testing after reprocessing and at the end of service life. Components outside the sterile field, such as the operator console and user interfaces contacting only intact skin, require cleaning and disinfection before use. Components too large for standard sterilizers require cleaning, disinfection and sterile drape coverage.

Shelf life and packaging. Simulated distribution assessment, seal strength testing, accelerated and real-time aging, conformance to ISO 11607-1 and ISO 11607-2, repetition of bench tests potentially affected by aging, and for polymeric materials parallel real-time aging confirming the accelerated result. The draft notes these results are documented in the design and development file and that complete reports are not required in the submission.

Bayou Vantage analysis. Two connections here are commonly missing.

The first is between reprocessing validation and performance testing. Validating that a component can be cleaned is a different claim from validating that it still performs after being cleaned the number of times its labeling permits. The draft's expectation of performance testing after reprocessing and at end of service life links them. Most organizations run these as separate programs owned by separate functions.

The second is between the numbers in labeling and the evidence that produced them. A use life stated as a cycle count, a service life stated in years, a reprocessing limit stated as a number of cycles: each of those is a claim, and each needs a traceable line to the test that establishes it. When those numbers are set by commercial or service considerations and the evidence is assembled afterward, the gap is visible to anyone who looks for the linkage.

Treat people as part of the system

The draft's human factors and training content is notable for treating the operating room as a multi-user environment rather than a device with an operator.

Training. The draft states that manufacturers should create and deliver an effective training plan for users consistent with the uses being sought for authorization. The user scope it describes covers surgeons, bedside assistants, surgical scrub nurses and other OR staff, with varying experience levels and clinical backgrounds. It addresses didactic content, robotic simulator use, and practice on bench, animal or cadaver models. It addresses establishing competency criteria, giving the number of procedures required to achieve proficiency as an example. It states that training evaluation should be updated when device user interfaces change or when new instruments or new user groups are introduced.

Human factors validation. The draft asks that validation encompass all user-device interaction points, conducted in a realistic operating room environment with representative users working as teams. The tasks it names include surgical planning, instrument preparation and system connections, device reprocessing, instrument removal, instrument exchange and port switching evaluated separately, and emergency procedures including conversion to open or laparoscopic surgery, emergency withdrawal, power loss and safety stops. It addresses multiple setup options representing various specialties, procedures and tasks, and testing of all feature enhancements such as tremor reduction, motion scaling and magnification even when their use is optional. It asks that the features available and the features actually used be recorded and reported for each scenario.

Bayou Vantage analysis. Three observations for anyone building a device used by a team.

Training is an evidence obligation, not a commercial deliverable. Competency criteria and evidence of training effectiveness are part of the traceable chain. Training content owned solely by commercial functions, with no defined competency measure and no link into the risk file, is a gap that becomes visible the first time a use error is investigated.

The trigger list for retraining is a change control question. The draft names interface changes, new instruments and new user groups as triggers for updated training evaluation. Those are the same triggers that should appear in your change impact assessment, which means training belongs in the change control matrix rather than downstream of it.

Emergency workflows are where team evidence is weakest. Emergency scenarios are infrequent, hard to simulate, and involve people who are not the primary user. They are also the scenarios where failure is least recoverable. If your human factors validation covered the primary user performing the primary task, the gap is the rest of the room.

Trace claims to proof

Labeling is where the evidence chain terminates, and it is the most common place for the chain to be broken, because labeling is drafted late, edited by many hands, and reviewed for accuracy of language more often than for traceability to evidence.

For accessories and compatible devices, the draft asks that each intended accessory or compatible device be listed in proposed labeling with the manufacturer name, device name, version or model number, and submission numbers where previously marketed. It addresses performance testing verifying compatibility and interoperability, whole-system testing with all intended accessories and compatible devices, documentation of connections, attachments and functionality, and description and testing of adapters and drapes. It references FDA's guidance on interoperable medical devices.

For 510(k) submissions the draft addresses predicate comparison, recommending side-by-side comparison of dimensions, materials, functions, degrees of freedom, force ranges and velocity limits with a rationale explaining why differences do not raise different questions of safety and effectiveness, and a separate summary of new or altered features with the impact assessment, the location of supporting performance testing in the submission, and the substantial equivalence analysis. It advises using the words identical or same only for features that are demonstrably identical.

The draft also describes an umbrella and covered procedure paradigm, in which a surgical procedure of sufficient complexity and risk can serve as an umbrella whose performance data supports covered procedures of lesser complexity and risk within the same specialty, potentially without additional in vivo testing.

Bayou Vantage analysis. A practical way to test labeling traceability: take the labeling document and mark every sentence that makes a claim about what the device does, how long it lasts, who can use it, what it is compatible with, or what it must not be used for. For each marked sentence, name the record that supports it, its version, and the acceptance criterion the record was evaluated against.

Sentences that cannot be resolved in under a minute fall into predictable categories. Inherited claims carried forward from a prior product. Compatibility statements based on an engineering assumption rather than a compatibility test. Limitations written to bound a risk that was never tested at the boundary. Use life or service life figures with no traceable basis.

FDA's caution about the words identical and same generalizes cleanly. Absolute language in a comparison is a claim of equivalence that has to be supportable at the level of the specific feature, not at the level of general similarity.

Govern lifecycle change

Everything above describes evidence at a point in time. The harder discipline is keeping it valid as the device changes.

The draft's lifecycle content includes several specific hooks. For software, it addresses impact analysis of changes on affected software units and subunits, justification for regression testing of modified functions, and version control and deployment strategy. For AI and machine learning enabled features, it references FDA's draft guidance on Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations and addresses proposing a Predetermined Change Control Plan for anticipated post-authorization modifications, together with data management, model description, performance validation and transparency documentation. For training, as noted, it names user interface changes, new instruments and new user groups as triggers for updated training evaluation. For additional features including eye tracking, haptics, imaging modalities and AI/ML algorithms, it addresses robust risk assessment, redundancy and fail-safe design testing for critical components, and recommends a Q-Submission for AI/ML integration or for concurrent use of high-energy imaging.

Bayou Vantage analysis. The organizing idea is that a change is not an event in one function's system. It is a query against the evidence architecture, and the answer is the list of records the change invalidates.

Change triggers that should initiate a documented impact assessment on a complex device:

• Component or material change, including a supplier-originated change, which reaches reliability, biocompatibility, sterilization, and any performance test whose result depended on that component

• Interface change, physical, electrical or data, which reaches the system description, integration testing, cybersecurity assessment and compatible device testing

• Instrument change or a new instrument, which reaches kinematics, reliability, use life, reprocessing, labeling and training

• Software change, which reaches regression scope, system-level verification, traceability, unresolved anomaly classification, and potentially the submission decision

• AI or ML model change, which reaches the PCCP if one exists and requires a submission decision if it does not

• New user group or new clinical setting, which reaches human factors validation, training, labeling and use-related hazard analysis

• New accessory or compatible device, which reaches compatibility testing, whole-system testing and labeling

• Service life or reprocessing limit change, which reaches the evidence supporting the labeled figure

• Manufacturing or sterilization process change, which reaches validation and potentially shelf life

The governance test is not whether these appear in a procedure. It is whether an engineer proposing a change encounters the list before implementation rather than after, and whether the impact assessment is performed against the evidence map rather than against the assessor's recall.

Executive evidence ledger

This section is Bayou Vantage analysis. It is an operating model, not an FDA recommendation.

The instrument that makes evidence architecture governable at the executive level is a single register covering the critical functions of the device. Not a replacement for the traceability matrix, which lives in the quality system and operates at requirement granularity. A management-level view, at the granularity of claims and critical functions, that leadership can actually read.

Six fields per row:

FieldWhat it capturesWhy executives need itOwnerThe named individual accountable for this evidence, not the functionUnowned evidence is the most common gap, and functions cannot be held to accountSource recordThe specific document and section that constitutes the evidenceForces the connection to be real rather than assumedVersionThe revision of that recordEvidence drifts out of date silently when versions are not tracked at this levelAcceptance criterionThe threshold the evidence was evaluated against, and its basisDistinguishes evidence that proves something from evidence that merely existsUnresolved assumptionWhat this evidence assumes but does not establishThe single highest-value field, because it makes known gaps visible instead of resident in individual memoryChange triggerWhat would invalidate this evidenceConverts the ledger from a status report into a change control instrument

The unresolved assumption field is the one that changes conversations. Every evidence package contains assumptions: that a worst case is representative, that a bench model predicts clinical behavior, that a user population matches the validation sample, that a component behaves consistently across suppliers. Those assumptions are usually known to the engineer and invisible above them. Writing them down does not resolve them. It lets leadership decide which ones are acceptable, which is a decision leadership is supposed to be making.

The change trigger field is what makes the ledger durable. A register that only records status is obsolete the moment the device changes. A register that records what would invalidate each row becomes the first thing consulted when a change is proposed.

Governance use: the ledger belongs in design review and in management review, with attention directed at rows where the owner is vacant, the version is behind the current device configuration, the acceptance criterion has no stated basis, or the unresolved assumption has been open across multiple reviews without a decision.

The 30-day diagnostic

This section is Bayou Vantage analysis.

Do not attempt to build the full architecture first. Test whether it exists by tracing one path end to end.

Select one critical function. One that involves software and mechanics together, is used under time pressure, and has a labeling claim attached. On a complex device this is usually a safety-critical behavior rather than a primary clinical function.

Trace it in one direction, then the other.

Forward, from the system description: locate the function in the architecture, identify the subassemblies and interfaces it depends on, find the hazards associated with it, find the design inputs and acceptance criteria those hazards produced, find the verification and validation that exercised them, find the worst-case justification, find the human factors evidence for the associated user tasks, and find the labeling statements that describe the function to users.

Backward, from labeling: take each labeling statement about the function and resolve it to a record, a version and an acceptance criterion.

Record where you stop. The diagnostic output is not a completed trace. It is a list of the specific points where the trace broke, the time each break took to resolve, and who had to be asked. Breaks that were resolved by asking a person rather than by reading a record are findings, because that path does not survive the person leaving.

Expect four patterns. A hazard with no verified control. An acceptance criterion with no stated basis. A labeling claim with no traceable record. A record whose version no longer matches the current configuration.

What to do with the result. If the trace completes with minor breaks, the architecture is sound and the gaps are maintenance. If it breaks in more than one place, the problem is structural and the response is the ledger and the change trigger list, not a document remediation project. Document remediation on a broken architecture produces more documents and the same gaps.

Can your team trace one critical function from system architecture through risk, verification, user evidence, labeling and lifecycle control? Bayou Vantage conducts focused complex-device readiness reviews built on exactly that trace. Contact Bayou Vantage.

Primary sources

• U.S. Food and Drug Administration, Center for Devices and Radiological Health. Robotically-Assisted Surgical Devices, Premarket Submissions. Draft Guidance for Industry and Food and Drug Administration Staff. Draft issued September 25, 2026. Docket FDA-2026-N-9505. Comments due November 24, 2026. Guidance page | Draft PDF

• Federal Register. Robotically-Assisted Surgical Devices, Premarket Submissions; Draft Guidance for Industry and Food and Drug Administration Staff; Availability. 91 FR, document 2026-19704, September 25, 2026. Notice

Referenced within the draft. The draft cites a number of other FDA guidances and consensus standards, including guidance on the content of premarket submissions for device software functions, cybersecurity in medical devices, radio frequency wireless technology in medical devices, interoperable medical devices, the 510(k) program and substantial equivalence, and the draft guidance on artificial intelligence-enabled device software functions and lifecycle management. Standards referenced include ANSI/AAMI ES60601-1, ANSI/AAMI/IEC 60601-1-2, IEC 80601-2-77, IEC 60601-2-2, IEC 60601-2-18, IEC 60825-1, IEC 60601-2-22, ISO 10993-7, ISO 11607-1 and ISO 11607-2, AAMI TIR69 and IEEE ANSI USEMCSC C63.27. Consult the draft directly for the specific context in which each is cited.

Status, restated. This guidance is in draft. It is not final, it is not for implementation, and it contains nonbinding recommendations that do not establish legally enforceable responsibilities. Its recommendations are directed at the device category defined in its scope section and do not extend automatically to other devices. The comment period is open until November 24, 2026, and the final guidance may differ from the draft in any respect. Nothing in this article should be read as a statement that FDA has established a compliance expectation, or that any particular recommendation applies to a particular device. Verify against the source before acting.

Discuss a readiness review

Can your team trace one critical function from system architecture through risk, verification, user evidence, labeling and lifecycle control?

Bayou Vantage helps complex-device organizations build and test the connections among their evidence, so that traceability holds under review and survives change.

Contact Bayou Vantage about a focused complex-device readiness review.