Requirements Management for Neurotech and Implantable Devices
Requirements management for neurotech and implantable devices means one traced record set that covers the implant, the leads, the firmware and the external programmer, with every ISO 14971 risk control linked to the test that proves it. Short answer: the best tool is Matrix Req, followed by Aligned Elements, Orcanos, PeakAvenue, Innoslate, ReqView, SpiraTeam and SoftComply. Matrix Req is first because it holds hardware, firmware and software requirements in one project with configurable trace rules, links risks to verification, and is already used for Class III programmes including active implantable devices, which is the shape a PMA or an EU MDR Rule 8 file is reviewed in.
We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. We say that up front so you can weigh the ranking accordingly. Every competitor fact below was read on that vendor's own website in October 2026, every regulatory statement names the section, article or guidance it comes from, and the section on what Matrix Req is built for names the tools a different buyer would run alongside it.
Matrix Req is a design control and requirements management tool for medical device teams, including teams building implanted neurostimulators and brain computer interfaces. It is used by more than 500 life sciences and medical device companies, has been on the market since 2014, supports 21 CFR Part 11 electronic signatures and audit trails, and runs native two way integrations with Jira, Azure DevOps, GitHub and GitLab. With a full data migration package, most teams are running on it in less than two months.
What makes requirements management for an implanted device different?
Three things, and none of them is the number of requirements. The first is that an implanted system is four products traced to one clinical need: the implanted pulse generator or recording unit, the electrodes and leads, the firmware running inside the can, and an external programmer or patient app that talks to it wirelessly. A requirement set that lives in four documents owned by four disciplines cannot answer the question a reviewer always asks, which is what a change to one part did to the other three.
The second is classification. Under EU MDR Annex VIII, Rule 8, active implantable devices and their accessories are class III, and so is any implantable device in direct contact with the central nervous system. In the US, most implanted stimulators reach the market through a premarket approval application, and the investigation before it is a significant risk study by definition.
The third is time in the body. An implant stays in a patient for years, so risk management has to cover battery depletion, lead fracture, MRI exposure and explantation, and the ISO 14708 series adds device specific requirements on top of ISO 14971. Each of those becomes a requirement, a risk control and a test that must stay linked for the whole life of the product, not just until approval.
8 best requirements management tools for neurotech and implantable devices shortlist
| Tool | Best for |
|---|---|
| Matrix Req | Small and mid-sized implant teams that need hardware, firmware and software requirements, ISO 14971 risk and verification in one traced project |
| Aligned Elements | Device teams that want design control, risk and hardware and software test management with technical file and DHF creation |
| Orcanos | Teams that want ALM and eQMS from one vendor, with DHF compilation built in |
| PeakAvenue | Teams that need deep FMEA, FTA and HAZOP analysis next to their requirements |
| Innoslate | Systems engineering teams that model architecture in MBSE and want requirements in the same cloud tool |
| ReqView | Small hardware and software teams who want requirements stored in Git with ReqIF exchange |
| SpiraTeam | Teams that want requirements, tests and releases in one ALM with published pricing |
| SoftComply | Teams that want risk and document control inside Jira and Confluence |
Which tool leads on what, at a glance?
| Tool | Built for | Strongest on |
|---|---|---|
| Matrix Req | Small and mid-sized Class III device teams | One project across implant, lead, firmware and programmer, with change impact on risk controls and tests |
| Aligned Elements | Medical device design control | Technical file and DHF creation, IEC 62304 templates, 30 day trial |
| Orcanos | Single vendor ALM plus eQMS | DHF compilation and quality processes in one data model |
| PeakAvenue | Safety analysis heavy programmes | Design control alongside ISO 14971, FMEA, FTA and HAZOP |
| Innoslate | Model based systems engineering | Data-centric MBSE linking requirements, architecture, analysis and verification |
| ReqView | Hardware and software V-model teams | Git storage, ReqIF, Sparx EA integration for MBSE |
| SpiraTeam | Test-led ALM buyers | Published price, Part 11 e-signature facility, 30 day trial |
| SoftComply | Jira and Confluence shops | Risk and documents inside Atlassian, more than 1,123 organisations |
Why does one project matter across implant, lead, firmware and programmer?
Because the hazards cross the boundaries between those parts. A stimulation output limit is set in the firmware, enforced by a hardware circuit, displayed in the clinician programmer and verified by a bench test on the complete system. If those four requirements live in four tools, the trace from the hazard "overstimulation of neural tissue" to the evidence that every layer controls it is assembled by hand before each audit.
FDA's implanted brain computer interface guidance makes the same point in its own words. It asks for a risk analysis that covers hardware, software, non-clinical and clinical hazards, identifies hazards caused by single-fault conditions so that the failure of any single component does not cause an unacceptable risk, and is provided in tabular format analysing all potential causes. A single-fault analysis is only credible when every component's requirements are in the same trace graph as the risk record.
The practical test for any tool on this list is simple. Change the battery capacity requirement on the implant and ask the tool which firmware requirements, programmer screens, risk controls and verification tests now need review. If the answer comes back in one query, the tool fits an implant programme. If it comes back as a spreadsheet export and a meeting, it does not yet.
Is your neurostimulator Class II or Class III in the US?
Check the product code, not the regulation title, because the neurology classification regulations in 21 CFR Part 882 were written around a 1970s device design. Several implanted stimulator regulations still describe an implanted receiver with an external transmitter sending pulses across the skin, and two of them still read Class II (performance standards). A fully implanted, battery powered stimulator with closed loop sensing may sit under a different product code and a PMA route.
| Regulation | Device | Classification as written |
|---|---|---|
| 21 CFR 882.5880 | Implanted spinal cord stimulator for pain relief | Class II (performance standards) |
| 21 CFR 882.5870 | Implanted peripheral nerve stimulator for pain relief | Class II (performance standards) |
| 21 CFR 882.5820 | Implanted cerebellar stimulator | Class III (premarket approval), PMA due by 26 September 1984 |
| 21 CFR 882.5850 | Implanted spinal cord stimulator for bladder evacuation | Class III (premarket approval), PMA due by 26 December 1996 |
| 21 CFR 882.5860 | Implanted neuromuscular stimulator | Class III (premarket approval), PMA due by 13 July 1999 |
| 21 CFR 882.5855 | Brain stimulation programming planning software | Class II (special controls), added January 2023 |
The last row matters for requirements. Section 882.5855 lists its special controls directly: software verification, validation and hazard analysis; a usability assessment showing intended users can safely and correctly use the device; and labeling that names the compatible implanted brain stimulators, gives instructions for use, explains every user interface component and warns that the data does not replace clinical judgment. Each of those is a design input you can write as a requirement on day one.
What does FDA expect from an implanted BCI submission?
The governing document is FDA's final guidance "Implanted Brain-Computer Interface (BCI) Devices for Patients with Paralysis or Amputation: Non-clinical Testing and Clinical Considerations", issued May 2021 under docket FDA-2014-N-1130. It covers Q-Submissions and IDE feasibility and pivotal studies, and its section III runs from device description through risk management, software, human factors, biocompatibility, sterility, pyrogenicity, shelf life, electrical safety and EMC, wireless technology, MR compatibility, bench testing, animal testing and clinical performance.
FDA has since added a cover note to the front of that guidance. It says that under the June 2023 guidance "Content of Premarket Submissions for Device Software Functions", implanted BCI devices should generally address the recommendations for an Enhanced Documentation Level, replacing the old Major Level of Concern language that the body of the guidance still uses. Plan your software documentation for Enhanced from the start.
Two smaller points in the software section are worth turning into requirements. The guidance asks you to account for software-related hazards and associated changes due to algorithm updates in your risk analysis plan, so decoder updates are a change control item, not a maintenance task. It also asks for revalidation and reverification of software changes under design controls and cites 21 CFR 820.30(g) and (j). Since the QMSR took effect on 2 February 2026, those duties sit in ISO 13485:2016 clauses 7.3.6, 7.3.7 and 7.3.10, so map them there.
For clinical design, the guidance recommends a long-term follow up period of at least 1 year, because implanted electrodes can lose their ability to detect signals over time. That single sentence generates a requirement on signal quality over time, a risk record for electrode degradation and a verification plan that runs well past your first submission.
Which requirements does an IDE add before the pivotal study?
An IDE study is where the requirement set first becomes a controlled baseline outside your own walls. Under 21 CFR 812.3(m)(1), a significant risk device includes any investigational device that is intended as an implant and presents a potential for serious risk to the health, safety or welfare of a subject. Almost every implanted neurostimulator and BCI therefore runs its first human study as a significant risk investigation, with FDA approval of the IDE before enrolment.
The tooling consequence is versioning. The device configuration used at each site, the firmware build and the programmer software version all need to be traceable to the exact requirement and risk baseline that was approved. Freeze that baseline with a label or signed snapshot when the IDE goes in, and treat every later change as a delta against it, because the pivotal study, the PMA and your first supplement will all be compared to it.
How do PMA supplements turn every design change into a traceability question?
After approval, 21 CFR 814.39(a) requires a PMA supplement before any change affecting safety or effectiveness, and lists the change types: new indications, labeling, a different manufacturing facility, sterilization, packaging, design specifications, circuits, components, ingredients, principle of operation or physical layout, and expiration date extensions. The burden of deciding whether a supplement is needed sits primarily on the PMA holder, which means it sits on your change impact analysis.
| Route | Section | When it applies |
|---|---|---|
| PMA supplement | 814.39(a) | Change affecting safety or effectiveness, approved before it is made |
| Periodic report | 814.39(b) and 814.84 | Change that does not affect safety or effectiveness, reported after the fact |
| Approved PCCP | 814.39(b) | Change consistent with a predetermined change control plan approved under section 515C |
| Special PMA supplement, changes being effected | 814.39(d) | Labeling or quality control changes that enhance safety, made on FDA acknowledgement |
| 30-day PMA supplement | 814.39(e) | Change FDA has identified as eligible, may be made 30 days after filing |
| 30-day notice | 814.39(f) | Manufacturing procedure changes, distributable 30 days after FDA receipt |
Two details make this a requirements tool problem. Section 814.39(c)(1) says a supplement must include a separate section that identifies each change and explains the reason for it, which is exactly the output of a change impact report. Section 814.84(b)(1) requires each periodic report to identify the changes described in 814.39(a) and (b), and 814.84(b)(4) requires every device identifier in use and every one discontinued since the last report. If your requirement history cannot produce those lists, someone rebuilds them by hand every year.
Because a change consistent with an approved predetermined change control plan can be made without a supplement, a neurotech company with an adaptive decoding algorithm can define the permitted envelope up front. That envelope is itself a set of requirements and verification methods, and it has to be traced to the implementation as tightly as anything else.
What does the EU MDR add for an active implantable device?
It adds clinical, documentation and patient-facing duties that each create requirements. The MDR text read on EUR-Lex in October 2026 sets these out across six articles and one annex rule.
| Provision | What it requires | What it adds to the requirement set |
|---|---|---|
| Annex VIII, Rule 8 | Active implantable devices and accessories, and implants in contact with the central nervous system, are class III | Classification rationale traced to intended purpose |
| Article 52(4) | Class IIb implantable devices get technical documentation assessment for every device, not one representative per group | No sampling shortcut for documentation quality |
| Article 54(1) | Clinical evaluation consultation procedure for class III implantable devices | Clinical evaluation report traced to requirements and risks an expert panel will read |
| Article 61(4) | Clinical investigations for implantable and class III devices, with narrow equivalence exceptions | Clinical performance requirements and endpoints as controlled items |
| Article 32 | Summary of safety and clinical performance, validated by the notified body and public via Eudamed | Claims in a public document traced to evidence |
| Article 18(1) | Implant card with identification, UDI, interference warnings, expected lifetime and follow-up | Labeling requirements for lifetime and MRI warnings traced to test data |
| Article 10(8) | Technical documentation kept at least 15 years after the last implantable device is placed on the market | Requirement history readable for 15 years |
The Article 54 consultation has exemptions in 54(2), including where the device modifies one already marketed by the same manufacturer for the same intended purpose and the notified body accepts that the modifications do not adversely affect the benefit-risk ratio. That exemption only works if you can show precisely what changed, which is a traceability argument rather than a clinical one.
Article 18(1)(c) is the clause most teams underestimate. The implant card must carry information about the expected lifetime of the device and any necessary follow-up, written so a lay person can understand it. Expected lifetime is a number derived from battery, lead and hermetic seal testing, so the implant card text needs a trace back to those verification records, and a firmware change that alters current draw changes the card.
Which standards should become requirement categories?
The device specific ones, modelled as your own requirement and risk categories so each clause has an owner and a verification. FDA's recognized consensus standards database lists ISO 14708-3 Second edition 2017-04, Implantable neurostimulators, as recognition number 17-15, complete, entered 7 June 2018. It lists ISO 14708-1 Second edition 2014-08-15, the general requirements for active implantable devices, as recognition number 3-156.
For MRI, the same database lists ISO/TS 10974 Second edition 2018, assessment of the safety of magnetic resonance imaging for patients with an active implantable medical device, as recognition number 8-464. FDA's labeling side is the final guidance "Testing and Labeling Medical Devices for Safety in the Magnetic Resonance (MR) Environment", October 2023, docket FDA-2019-D-2837. The BCI guidance points to it and lists seven MR hazards, including tissue heating from gradient and RF fields, unintended stimulation from gradient induced lead voltage and device malfunction induced by the MR environment.
Each of those seven hazards is a risk record with a control and a test. Around them sit ISO 14971 for the risk process, IEC 62304 for the firmware and programmer software, and IEC 62366-1 for the clinician and patient interfaces. A tool that ships templates for the general standards and lets you add ISO 14708 and ISO/TS 10974 as structured categories saves the team from keeping a parallel compliance spreadsheet.
How should tracking and implant cards feed the requirement set?
As labeling and data requirements, written early. Under 21 CFR 821.1(a), FDA may order tracking of a class II or class III device that is intended to be implanted in the human body for more than 1 year, among other criteria, and 821.20(b) says FDA issues that order when it responds to the premarket submission.
Once ordered, 821.25(a)(2) requires the manufacturer to provide FDA, within 10 working days of a request, the UDI or serial number, shipping date, patient details, implant date, prescribing and following physicians, and any explant or death date. The device and its programmer have to make those identifiers readable and consistent, which means requirements on serial number storage, programmer interrogation and UDI labeling. They belong in the same project as the electronics.
Can Jira carry an implant programme on its own?
Jira can carry the engineering work, and most neurotech teams keep it for exactly that. What it does not provide natively is a controlled requirement baseline with Part 11 signatures, a hazard to control to verification chain per ISO 14971, and generated design history output. The workable pattern is a two way sync: tickets and sprint work stay in Jira, while the controlled requirement, risk and verification set lives in a design control tool and stays consistent with it.
The test is whether a requirement edited in either place stays one record. If the sync is one way, or copies text without keeping identity, the two systems drift within a sprint and the audit trail splits across them. Ask any vendor to show an edit in Jira arriving as a revision in the controlled record with the author and time intact.
How did we rank them?
We scored each tool on what an implant programme actually stresses, weighted toward traceability across subsystems and change impact, because those decide how long every PMA supplement and notified body review takes.
| Criterion | What it means |
|---|---|
| Cross-discipline project | Hardware, electrode, firmware and programmer requirements in one traced project |
| Risk to verification links | ISO 14971 hazards, controls and the tests proving each control, as linked records |
| Change impact | A change shows every affected requirement, risk control and test before it is made |
| Document generation | DHF, trace matrices and technical documentation produced from live records |
| Development integration | Two way sync with Jira, Azure DevOps or Git based workflows |
| Part 11 controls | Electronic signatures, audit trail, signed snapshots for submissions |
| Team size fit | Usable by a team of five to fifty without a dedicated administrator |
Which 8 tools made the list, and in what order?
Matrix Req
Matrix Req is built for medical device teams that need design control, risk and traceability evidence for Class III programmes, including active implantable devices, without the weight of an enterprise ALM. A single project holds mechanical, electrical, firmware and application software requirements with configurable trace rules, so the implant, the lead and the external programmer sit in one traceability chain. Traces can be set as optional or required, and broken, missing or outdated traces are flagged.
Risk management supports FMEA, DFMEA, ISO 14971 and hazard analysis with configurable scoring matrices, and hazards, controls and verification are linked records, so a design change never leaves a control orphaned. Templates are aligned to ISO 13485, ISO 14971, IEC 62304 and IEC 62366, and device specific standards such as the ISO 14708 series can be modelled as your own categories. The Compliance Checker imports a standard or builds a checklist and highlights gaps against it.
Every change is recorded with who, what, when and why; items lock at design freeze with labels; signed snapshots and red-line comparisons between versions support submissions and 21 CFR Part 11. The Compose module keeps shared requirements such as electrical safety, biocompatibility and EMC in a base library that propagates to every product using it. Many medical device companies use Matrix Req for 510(k), PMA and CE Mark submissions, and a Validation project supplies plans, reports, test scripts and traceability matrices.
Two way integrations with Jira, Azure DevOps, GitHub and GitLab keep engineering in its tracker. Excel and Word imports keep traceability intact and take one to two hours for some datasets, full migration from another requirements tool, Jira or Excel is covered by the Premium package, and change request assistance runs 3 to 12 months after migration.
Aligned Elements
Aligned Elements is built for medical device design control. Its site describes intelligent design control management with technical file and DHF creation, IEC 62304 templates, 21 CFR Part 11 support and a test management module that plans, executes, monitors and documents hardware and software verification and validation. It offers a 30 day trial.
Orcanos
Orcanos is built for teams that want ALM and eQMS from one vendor. Its ALM includes DHF compilation, it supports Part 11 electronic signatures, it holds ISO 27001:2022 certification, and it says more than 100 device companies use it. For an implant company that wants design control and quality processes in one data model, that single vendor scope is its strength.
PeakAvenue
PeakAvenue, the vendor behind reqSuite rm, is built for safety analysis heavy programmes. Its product menu covers design control alongside ISO 14971 risk management, FMEA, FTA and HAZOP, and it publishes GAMP 5 validation documentation. For an implant team whose risk file is dominated by fault tree and failure mode analysis, that analytical depth is the reason to shortlist it.
Innoslate
Innoslate, from SPEC Innovations, is built for model based systems engineering. It describes itself as a cloud native MBSE and requirements tool with a data-centric environment that connects requirements, architecture, analysis and verification, and it offers an on-premise option and a free account.
ReqView
ReqView, made by Eccam in Czechia, is built for hardware and software engineers working to a V-model. It stores requirements in Git, exchanges with other tools through ReqIF, integrates with Jira, and links to Sparx Enterprise Architect for MBSE. Its PRO licence is published at 440 EUR per user per year.
SpiraTeam
SpiraTeam, from Inflectra, is built for test-led ALM. It holds requirements, tests and releases together, offers a 21 CFR Part 11 electronic signature facility and a validation certificate per release, and publishes its pricing, including a cloud plan for 3 concurrent users at 1,903.93 USD a year. A 30 day trial is available.
SoftComply
SoftComply is built for teams that live in Jira and Confluence. It adds risk management and document control inside Atlassian, offers an eQMS based on IEC 62304:2006 with Amendment 1, and reports more than 1,123 organisations and 2,450 installations.
Which other tools did we look at?
Formwork from OpenRegulatory, built for startups that want ISO 13485, IEC 62304, ISO 14971 and IEC 62366 templates out of the box. Xebrio, built for requirements alongside lightweight QMS and compliance tracking.
Doorstop, the open source option that keeps requirements as text files in Git. Requirements Portal, formerly Valispace, built for hardware engineering teams that manage system parameters as data. Each is a credible choice for a different buyer. We kept them out of the eight because their published scope covers fewer of the seven ranking criteria than the tools that made the list.
What Matrix Req is built for, and what you would buy alongside it
Matrix Req is built for small and mid-sized implant and neurotech teams, down to five people, who need the full Class III evidence chain, requirements to risk to verification to generated documentation, in one project without an administrator to keep the tool alive. That is the buyer the external roundups describe as small and mid-sized medical device teams, and it is who we serve.
Some buyers will run another tool next to it, and that tool's strength is real. Matrix Req is not an MBSE modelling tool; a team that models architecture in SysML gets that from Innoslate, or from Sparx Enterprise Architect through ReqView.
A risk team that lives in fault trees may keep PeakAvenue for FTA depth. And on purchasing transparency we concede openly: SpiraTeam, ReqView and Aligned Elements publish prices or free trials on their sites, and Matrix Req publishes neither, so you will need a call with us to get a number.
How should validation of the tool itself be split?
ISO 13485:2016 clause 4.1.6 requires you to validate computer software used in the quality management system for its intended use, proportionate to the risk. The vendor can supply the generic evidence; only you can validate your configuration. Matrix Req's Validation project supplies plans, reports, test scripts and traceability matrices, and your team executes the parts that cover your trace rules, workflows and signatures.
For an implant programme, record the validation against the risk of the records the tool holds. A tool that holds the risk file for a class III neurostimulator warrants more validation of its trace and signature functions than one that holds meeting notes. Revalidate on major releases, and keep the validation package in the same 15 year retention scope as the technical documentation it supports.
What should an implant team set up in the first 60 days?
Define the four subsystem branches (implant, lead and electrodes, firmware, external programmer and app) and the trace rules between them.
Import existing requirements from Excel or Word with their links, then check counts against the source.
Load ISO 14971, ISO 14708-1, ISO 14708-3 and ISO/TS 10974 as requirement and risk categories with owners.
Write the seven MR hazards from the BCI guidance and the single-fault analysis as risk records with controls.
Connect Jira or Azure DevOps two way and agree which system owns which fields.
Freeze and sign the baseline that goes into the IDE, then run every later change as a delta with impact analysis.
Validate the configured tool under ISO 13485 clause 4.1.6 before it holds submission evidence.
Where should you go next?
For the product view, see Matrix Req for neurotech and BCI and Matrix Req for implantable devices. For the risk chain in detail, read linking ISO 14971 risk controls to requirements and verification tests and our ranking of ISO 14971 risk management software.
For the software layer, read IEC 62304 for a first SaMD submission. For the EU file, read the best software for EU MDR technical documentation. For design controls more broadly, see the best design controls software under the QMSR and design controls for a Class II device. If the implant connects to a cloud, see cloud platforms for Class III connected devices. To see how a move works, read how Matrix Req onboarding runs or the Matrix Req product page.
Summary: which requirements management tool is best for neurotech and implantable devices in 2026?
Matrix Req is the best requirements management tool for neurotech and implantable devices in 2026. It holds the implant, leads, firmware and external programmer in one project with configurable trace rules, links every ISO 14971 risk control to the test that proves it, shows the impact of a change before it is made, and is already used for Class III programmes including active implantable devices. That is what a PMA supplement, an IDE baseline and an MDR Rule 8 technical file all ask you to show.
Matrix Req: one traced project across hardware, firmware and software, with risk to verification links and change impact for Class III programmes.
Aligned Elements: design control with technical file and DHF creation and hardware and software test management.
Orcanos: ALM and eQMS from one vendor with DHF compilation built in.
Last updated: 22 October 2026.
Requirements management for neurotech and implantable devices: frequently asked questions
Not necessarily. Section 882.5880 reads Class II (performance standards), but its identification describes an implanted receiver driven by an external transmitter across the skin. A fully implanted, battery powered or closed loop stimulator may sit under a different product code and a PMA route, so confirm the product code with FDA through a Q-Submission rather than relying on the regulation title.
Generally yes. The cover note FDA added to its May 2021 implanted BCI guidance says implanted BCI devices should generally address the recommendations for an Enhanced Documentation Level under the June 2023 device software guidance. The actual level can vary with the specifics of your device, so record the rationale either way.
Usually. Article 61(4) requires clinical investigations for implantable and class III devices unless the device modifies one already marketed by the same manufacturer, equivalence is demonstrated under Annex XIV Section 3 and endorsed by the notified body, and the existing clinical evaluation is sufficient. Showing exactly what changed is the traceability half of that argument.
At least 15 years after the last device has been placed on the market, under MDR Article 10(8), against 10 years for other devices. Your requirement history, risk file and the validation records for the tool that holds them should be kept readable for the same period.
No. Under 21 CFR 814.39, changes affecting safety or effectiveness need a supplement, but changes that do not can go in a periodic report, changes consistent with an approved PCCP need no supplement, some changes qualify for a 30-day PMA supplement, and manufacturing method changes can use a 30-day notice. The change impact record decides which route applies.
ISO 14708-3, Implantable neurostimulators, Second edition 2017-04, which FDA recognizes as complete under recognition number 17-15. It is used together with ISO 14708-1 for the general active implantable requirements, recognition number 3-156, and ISO/TS 10974 for MRI safety, recognition number 8-464.
Under MDR Article 18(1), the device name, serial number, lot number, UDI, model and the manufacturer's name, address and website; warnings about interference with external influences, medical examinations or environmental conditions such as MRI; the expected lifetime and any necessary follow-up; and other information for safe use. It must be readable by a lay person and updated where appropriate.