eduKateSG · Why Science?
Map every function and the paths between them
Use FDA’s multiple-function device policy through the function-under-review, other functions, two-step impact test, positive and negative effects, shared resources, data, interfaces, cybersecurity and change.
A medical product may combine monitoring, messaging, analytics, entertainment and device control. The product name hides these distinctions, so a reliable analysis begins with a function map and follows every route by which one feature can influence another.
FDA’s final Multiple Function Device Products guidance calls the evaluated device function the function-under-review. It then asks whether other functions affect its safety or effectiveness and, if so, whether the impact raises risk or adversely affects performance.
Did you know? An “other function” is not always unregulated software. It can also be a device function under enforcement discretion or a device function simply outside the scope of the current premarket review.
This guide supports systems engineering and regulatory literacy. It does not decide the submission scope or safety of a particular product.
Chapter index
Chapters 1–9: function status, review scope and impact
- 1. A function is a distinct product purpose
- 2. The product contains a device function
- 3. Other functions can have several statuses
- 4. The function-under-review anchors the submission
- 5. Step one asks whether an impact exists
- 6. Step two asks whether the impact is negative
- 7. Positive effects should also be identified
- 8. Shared computing resources create interactions
- 9. Shared data paths can change meaning
Chapters 10–17: architecture, risk controls, testing and lifecycle
- 10. User interfaces can introduce risk
- 11. Cybersecurity links functions
- 12. Risk analysis should show the pathway
- 13. Testing should exercise combinations
- 14. Separation can be a risk control
- 15. Labeling should describe dependencies
- 16. Changes can reopen the assessment
- 17. A complete function map supports review
A multi-function product becomes reviewable when every function and interaction is mapped. FDA uses function to mean a distinct purpose of a product, which may be an intended use or a subset of an intended use. This turns a feature list into an interaction analysis.
Try this
Evidence question: Which official guidance passage or product record supports the point about a function is a distinct product purpose? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for a function is a distinct product purpose. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for a function is a distinct product purpose, its identifier or version context, and one limit that must remain visible.
FDA calls the reviewed device function the function-under-review and evaluates how other functions may affect it. A multiple-function device product contains at least one device function and at least one other function. It also keeps unreviewed functions from disappearing inside a product label.
Try this
Evidence question: Which official guidance passage or product record supports the point about the product contains a device function? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for the product contains a device function. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for the product contains a device function, its identifier or version context, and one limit that must remain visible.
A useful extra feature can create positive, neutral or negative effects on safety and effectiveness. An other function may be a non-device function, a device function under enforcement discretion or a device function that is not the subject of the current premarket review. Risk controls should follow the actual pathway of influence.
Try this
Evidence question: Which official guidance passage or product record supports the point about other functions can have several statuses? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for other functions can have several statuses. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for other functions can have several statuses, its identifier or version context, and one limit that must remain visible.
CHAPTER 4 OF 17 · Name each function
4. The function-under-review anchors the submission
Shared resources, data paths and user interfaces make the boundaries scientifically important. The device function being evaluated in the particular premarket submission should be named precisely, including its intended use and version. The final evidence package must show both benefits and adverse effects.
Try this
Evidence question: Which official guidance passage or product record supports the point about the function-under-review anchors the submission? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for the function-under-review anchors the submission. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for the function-under-review anchors the submission, its identifier or version context, and one limit that must remain visible.
A multi-function product becomes reviewable when every function and interaction is mapped. FDA’s assessment first asks whether the other function affects the safety or effectiveness of the device function-under-review. This turns a feature list into an interaction analysis.
Try this
Evidence question: Which official guidance passage or product record supports the point about step one asks whether an impact exists? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for step one asks whether an impact exists. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for step one asks whether an impact exists, its identifier or version context, and one limit that must remain visible.
FDA calls the reviewed device function the function-under-review and evaluates how other functions may affect it. When an impact exists, the analysis asks whether it increases risk or adversely affects performance of the reviewed device function. It also keeps unreviewed functions from disappearing inside a product label.
Try this
Evidence question: Which official guidance passage or product record supports the point about step two asks whether the impact is negative? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for step two asks whether the impact is negative. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for step two asks whether the impact is negative, its identifier or version context, and one limit that must remain visible.
A useful extra feature can create positive, neutral or negative effects on safety and effectiveness. An other function may improve the safety or effectiveness of the reviewed function, and a labeled positive impact should be supported rather than assumed. Risk controls should follow the actual pathway of influence.
Try this
Evidence question: Which official guidance passage or product record supports the point about positive effects should also be identified? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for positive effects should also be identified. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for positive effects should also be identified, its identifier or version context, and one limit that must remain visible.
CHAPTER 8 OF 17 · Trace interactions
8. Shared computing resources create interactions
Shared resources, data paths and user interfaces make the boundaries scientifically important. Processor load, memory, storage, power and operating-system services can allow one function to affect the performance of another. The final evidence package must show both benefits and adverse effects.
Try this
Evidence question: Which official guidance passage or product record supports the point about shared computing resources create interactions? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for shared computing resources create interactions. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for shared computing resources create interactions, its identifier or version context, and one limit that must remain visible.
A multi-function product becomes reviewable when every function and interaction is mapped. Inputs, transformations, databases, timestamps and interfaces can transmit errors or delays across function boundaries. This turns a feature list into an interaction analysis.
Try this
Evidence question: Which official guidance passage or product record supports the point about shared data paths can change meaning? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for shared data paths can change meaning. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for shared data paths can change meaning, its identifier or version context, and one limit that must remain visible.
FDA calls the reviewed device function the function-under-review and evaluates how other functions may affect it. Screens, alerts, controls and workflow changes can cause confusion, masking, incorrect selection or over-reliance even when software modules are technically separate. It also keeps unreviewed functions from disappearing inside a product label.
Try this
Evidence question: Which official guidance passage or product record supports the point about user interfaces can introduce risk? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for user interfaces can introduce risk. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for user interfaces can introduce risk, its identifier or version context, and one limit that must remain visible.
A useful extra feature can create positive, neutral or negative effects on safety and effectiveness. An other function can add connectivity, privileges, dependencies or attack surfaces that affect the security of the reviewed device function. Risk controls should follow the actual pathway of influence.
Try this
Evidence question: Which official guidance passage or product record supports the point about cybersecurity links functions? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for cybersecurity links functions. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for cybersecurity links functions, its identifier or version context, and one limit that must remain visible.
Shared resources, data paths and user interfaces make the boundaries scientifically important. Hazards, sequences of events, harms, controls and residual risks should explain exactly how an interaction could matter. The final evidence package must show both benefits and adverse effects.
Try this
Evidence question: Which official guidance passage or product record supports the point about risk analysis should show the pathway? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for risk analysis should show the pathway. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for risk analysis should show the pathway, its identifier or version context, and one limit that must remain visible.
A multi-function product becomes reviewable when every function and interaction is mapped. Integration, stress, fault, usability and cybersecurity testing can show whether the functions remain safe and effective when used together. This turns a feature list into an interaction analysis.
Try this
Evidence question: Which official guidance passage or product record supports the point about testing should exercise combinations? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for testing should exercise combinations. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for testing should exercise combinations, its identifier or version context, and one limit that must remain visible.
FDA calls the reviewed device function the function-under-review and evaluates how other functions may affect it. Architectural partitioning, access controls, resource budgets and interface contracts can reduce unwanted influence between functions. It also keeps unreviewed functions from disappearing inside a product label.
Try this
Evidence question: Which official guidance passage or product record supports the point about separation can be a risk control? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for separation can be a risk control. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for separation can be a risk control, its identifier or version context, and one limit that must remain visible.
A useful extra feature can create positive, neutral or negative effects on safety and effectiveness. Users need accurate compatibility, configuration, limitations and update information when one function depends on another. Risk controls should follow the actual pathway of influence.
Try this
Evidence question: Which official guidance passage or product record supports the point about labeling should describe dependencies? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for labeling should describe dependencies. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for labeling should describe dependencies, its identifier or version context, and one limit that must remain visible.
Shared resources, data paths and user interfaces make the boundaries scientifically important. Adding or modifying another function may change its impact on the reviewed function and can require a new regulatory assessment. The final evidence package must show both benefits and adverse effects.
Try this
Evidence question: Which official guidance passage or product record supports the point about changes can reopen the assessment? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for changes can reopen the assessment. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for changes can reopen the assessment, its identifier or version context, and one limit that must remain visible.
A multi-function product becomes reviewable when every function and interaction is mapped. Record every function, regulatory status, owner, data and resource dependency, impact, risk control, test, labeling statement, version and submission decision. This turns a feature list into an interaction analysis.
Try this
Evidence question: Which official guidance passage or product record supports the point about a complete function map supports review? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record the function, identifier, date and one evidence limit for a complete function map supports review. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for a complete function map supports review, its identifier or version context, and one limit that must remain visible.
Contents · Previous chapter · Continue at the Science Learning Hub
A feature bundle becomes a safety case when interactions are explicit
Function maps reveal how resources, data, interfaces, users and cybersecurity connect. That evidence supports a focused review without pretending that the rest of the product cannot affect the function-under-review.
Save the product and version, each function and intended use, regulatory status, function-under-review, architecture and interfaces, shared resources, data flows, positive and negative impacts, hazard analysis, controls, verification and validation, cybersecurity evidence, labeling, change history and access date.
| Reading object | What it can support | Question to keep visible |
|---|---|---|
| Function map | Names each distinct product purpose | Which function is under review? |
| Impact test | Finds effects on safety or effectiveness | Is any effect negative? |
| Interaction evidence | Shows resource, data or user pathways | Which control interrupts the pathway? |
| Change record | Preserves lifecycle reassessment | Did another function or interface change? |
Sources and next reading
Substantive resource claims in this article were checked against the primary pages below. A structured record is a route into evidence; it does not by itself prove a scientific conclusion. Recheck the live record, evidence labels and release context before using it in assessed work or research.
For a classroom enquiry, save a short research receipt containing the question, search terms, selected object, exact identifier, version, access date and the evidence boundary you observed. Add the file or page that supports each statement. This small routine turns browsing into accountable science learning and gives a teacher, classmate or future analyst a route they can independently follow.
Before sharing the conclusion, ask another reader to retrace the route without verbal hints. If they reach a different version, file or interpretation, improve the receipt and narrow the claim. Reproducibility begins with this practical check. It teaches careful reading, supports fair collaboration and keeps uncertainty visible while evidence moves from an online service into notes, analysis and a final explanation.
A useful final review separates five questions. What object was found? Which organisation or repository maintains it? What exact evidence was inspected? Which statement does that evidence support? What remains uncertain? Answer each question in one sentence, then connect every answer to a visible field, file or source page. This review catches common mistakes: citing a collection when a file supplied the value, treating the newest release as the analysed release, confusing permission with scientific suitability, or turning a discovery count into a conclusion. It also gives students a calm way to improve work. A missing detail becomes a next research step instead of an invitation to guess. When the route is complete, the final explanation can stay simple because the identifiers, dates, versions, limitations and supporting evidence are already organised underneath it.
Primary sources
- FDA Multiple Function Device Products Guidance — accessed 25 October 2026.
- FDA Multiple Function Guidance PDF — accessed 25 October 2026.
- FDA Medical Device Software Guidance Navigator — accessed 25 October 2026.
- FDA Device Software Premarket Guidance — accessed 25 October 2026.
- FDA Digital Health Guidance List — accessed 25 October 2026.