eduKateSG · Why Science?
Follow the data without inventing a diagnosis
Use FDA’s MDDS policy through transfer, storage, format conversion, display, medical images, Non-Device-MDDS software, Device-MDDS hardware, data modification and device control.
Hospitals and home-care systems move measurements, waveforms and images across screens, archives and networks. A useful science question is whether a function simply carries existing information or creates a new clinical interpretation.
FDA’s September 2022 guidance draws that boundary for Medical Device Data Systems, medical image storage devices and medical image communications devices. Software solely intended for the named transfer, storage, format-conversion or display tasks is treated differently from hardware and from analytic functions.
Did you know? FDA calls qualifying software “Non-Device-MDDS,” while qualifying hardware remains “Device-MDDS” under an enforcement-discretion policy. Similar-looking screens can therefore require different legal analysis.
This guide supports data-system and regulatory literacy. It does not classify a particular hospital system or validate its clinical use.
Chapter index
Chapters 1–9: transfer, storage, conversion and display
- 1. The September 2022 guidance is current
- 2. Transfer is a limited function
- 3. Storage preserves data for later use
- 4. Format conversion should preserve information
- 5. Display is different from analysis
- 6. Solely intended software functions are non-device
- 7. FDA calls these Non-Device-MDDS
- 8. Hardware functions remain Device-MDDS
- 9. FDA applies enforcement discretion to qualifying hardware
Chapters 10–17: status, interaction, reliability and limits
- 10. Data modification changes the analysis
- 11. Device control is outside the limited role
- 12. Active monitoring does not decide status alone
- 13. Medical images are included
- 14. A product can contain several functions
- 15. Cybersecurity and reliability still matter
- 16. Guidance is not product authorization
- 17. A complete data-path receipt preserves scope
A medical-data pathway becomes clearer when transfer, storage, format conversion, display and interpretation are separated. FDA’s final guidance communicates current policy for Medical Device Data Systems, medical image storage devices and medical image communications devices. This prevents a data pipe from being mistaken for a diagnostic engine.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about the september 2022 guidance is current? 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: Save the function, version, date and one limit for the september 2022 guidance is current. 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 the september 2022 guidance is current, its identifier or version context, and one limit that must remain visible.
FDA treats a function differently when it merely moves or displays medical-device data and when it analyses or changes that data. Moving medical-device data or results from one location to another can fit the policy when the function does not analyse, modify or control the source device. It also keeps active monitoring and data modification visible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about transfer is a limited 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: Save the function, version, date and one limit for transfer is a limited 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 transfer is a limited function, its identifier or version context, and one limit that must remain visible.
The September 2022 guidance is the current policy anchor for MDDS and related image functions. A storage function keeps medical-device data or images without changing their content or meaning. A function-by-function map makes the policy boundary reproducible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about storage preserves data for later use? 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: Save the function, version, date and one limit for storage preserves data for later use. 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 storage preserves data for later use, its identifier or version context, and one limit that must remain visible.
Hardware and software can perform similar-looking tasks while occupying different statutory positions. Conversion can change technical representation while preserving the content and meaning of the medical-device data. The source device, displayed result and user action still need context.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about format conversion should preserve information? 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: Save the function, version, date and one limit for format conversion should preserve information. 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 format conversion should preserve information, its identifier or version context, and one limit that must remain visible.
A medical-data pathway becomes clearer when transfer, storage, format conversion, display and interpretation are separated. Showing medical-device data or results can fit the limited function, while analysing, interpreting or generating new clinical information may cross another policy boundary. This prevents a data pipe from being mistaken for a diagnostic engine.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about display is different from analysis? 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: Save the function, version, date and one limit for display is different from analysis. 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 display is different from analysis, its identifier or version context, and one limit that must remain visible.
CHAPTER 6 OF 17 · Separate functions
6. Solely intended software functions are non-device
FDA treats a function differently when it merely moves or displays medical-device data and when it analyses or changes that data. Section 520(o)(1)(D) excludes software functions solely intended to transfer, store, convert formats or display medical-device data or results, including images, waveforms, signals and other clinical information. It also keeps active monitoring and data modification visible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about solely intended software functions are non-device? 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: Save the function, version, date and one limit for solely intended software functions are non-device. 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 solely intended software functions are non-device, its identifier or version context, and one limit that must remain visible.
The September 2022 guidance is the current policy anchor for MDDS and related image functions. FDA uses the label Non-Device-MDDS for qualifying software functions and states that device regulatory requirements do not apply to them. A function-by-function map makes the policy boundary reproducible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about fda calls these non-device-mdds? 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: Save the function, version, date and one limit for fda calls these non-device-mdds. 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 fda calls these non-device-mdds, its identifier or version context, and one limit that must remain visible.
Hardware and software can perform similar-looking tasks while occupying different statutory positions. Hardware solely intended for the same limited functions is described as Device-MDDS. The source device, displayed result and user action still need context.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about hardware functions remain device-mdds? 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: Save the function, version, date and one limit for hardware functions remain device-mdds. 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 hardware functions remain device-mdds, its identifier or version context, and one limit that must remain visible.
CHAPTER 9 OF 17 · Check hardware and software
9. FDA applies enforcement discretion to qualifying hardware
A medical-data pathway becomes clearer when transfer, storage, format conversion, display and interpretation are separated. FDA states that it does not intend to enforce FD&C Act device requirements for qualifying MDDS, image-storage and image-communications hardware functions under the guidance. This prevents a data pipe from being mistaken for a diagnostic engine.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about fda applies enforcement discretion to qualifying hardware? 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: Save the function, version, date and one limit for fda applies enforcement discretion to qualifying hardware. 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 fda applies enforcement discretion to qualifying hardware, its identifier or version context, and one limit that must remain visible.
CHAPTER 10 OF 17 · Check hardware and software
10. Data modification changes the analysis
FDA treats a function differently when it merely moves or displays medical-device data and when it analyses or changes that data. An MDDS does not modify the data or modify the display of the data, so filtering, processing or diagnostic transformation needs separate assessment. It also keeps active monitoring and data modification visible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about data modification changes the analysis? 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: Save the function, version, date and one limit for data modification changes the analysis. 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 data modification changes the analysis, its identifier or version context, and one limit that must remain visible.
CHAPTER 11 OF 17 · Check hardware and software
11. Device control is outside the limited role
The September 2022 guidance is the current policy anchor for MDDS and related image functions. An MDDS does not by itself control the functions or parameters of another medical device. A function-by-function map makes the policy boundary reproducible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about device control is outside the limited role? 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: Save the function, version, date and one limit for device control is outside the limited role. 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 device control is outside the limited role, its identifier or version context, and one limit that must remain visible.
CHAPTER 12 OF 17 · Check hardware and software
12. Active monitoring does not decide status alone
Hardware and software can perform similar-looking tasks while occupying different statutory positions. FDA explains that MDDS may or may not be intended for active patient monitoring; the actual transfer, storage, conversion and display functions still need analysis. The source device, displayed result and user action still need context.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about active monitoring does not decide status alone? 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: Save the function, version, date and one limit for active monitoring does not decide status alone. 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 active monitoring does not decide status alone, its identifier or version context, and one limit that must remain visible.
A medical-data pathway becomes clearer when transfer, storage, format conversion, display and interpretation are separated. The policy expressly addresses medical image storage and communications alongside other medical-device data. This prevents a data pipe from being mistaken for a diagnostic engine.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about medical images are included? 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: Save the function, version, date and one limit for medical images are included. 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 medical images are included, its identifier or version context, and one limit that must remain visible.
FDA treats a function differently when it merely moves or displays medical-device data and when it analyses or changes that data. A system may combine Non-Device-MDDS functions with device software functions, analytics or controls that need separate review. It also keeps active monitoring and data modification visible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about a product can contain several 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: Save the function, version, date and one limit for a product can contain several functions. 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 a product can contain several functions, its identifier or version context, and one limit that must remain visible.
CHAPTER 15 OF 17 · Preserve the boundary
15. Cybersecurity and reliability still matter
The September 2022 guidance is the current policy anchor for MDDS and related image functions. A non-device software status does not remove practical responsibilities for data integrity, availability, access control and safe system design. A function-by-function map makes the policy boundary reproducible.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about cybersecurity and reliability still matter? 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: Save the function, version, date and one limit for cybersecurity and reliability still matter. 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 and reliability still matter, its identifier or version context, and one limit that must remain visible.
Hardware and software can perform similar-looking tasks while occupying different statutory positions. The policy page explains FDA’s current thinking and does not clear or approve an individual data system. The source device, displayed result and user action still need context.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about guidance is not product authorization? 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: Save the function, version, date and one limit for guidance is not product authorization. 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 guidance is not product authorization, its identifier or version context, and one limit that must remain visible.
CHAPTER 17 OF 17 · Preserve the boundary
17. A complete data-path receipt preserves scope
A medical-data pathway becomes clearer when transfer, storage, format conversion, display and interpretation are separated. Record the source device, function, data type, transfer or storage route, conversion, display, modification, control, hardware or software status, version and access date. This prevents a data pipe from being mistaken for a diagnostic engine.
Try this
Evidence question: Which official guidance passage, test record or decision supports the point about a complete data-path receipt preserves scope? 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: Save the function, version, date and one limit for a complete data-path receipt preserves scope. 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 data-path receipt preserves scope, its identifier or version context, and one limit that must remain visible.
Contents · Previous chapter · Continue at the Science Learning Hub
A clean data route keeps transport separate from interpretation
MDDS policy works best when every function can be named and traced. The boundary becomes visible when the record shows whether data were preserved, changed, analysed or used to control another device.
Save the system and version, source device, data type, each transfer, storage, conversion and display step, transformations, latency, active-monitoring role, hardware or software status, connected analytics, controls, validation, security evidence and access date.
| Reading object | What it can support | Question to keep visible |
|---|---|---|
| Data function | Transfers, stores, converts or displays | Was meaning changed? |
| Software status | May be Non-Device-MDDS | Is the purpose solely one of the named functions? |
| Hardware status | May be Device-MDDS under discretion | Which physical function is performed? |
| Connected feature | May analyse or control | Which separate policy applies? |
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 MDDS Final Guidance — accessed 25 October 2026.
- FDA MDDS Overview — accessed 25 October 2026.
- FDA Examples That Are Not Medical Devices — accessed 25 October 2026.
- FDA Device Software Functions — accessed 25 October 2026.
- FDA Digital Health Guidance List — accessed 25 October 2026.