Medical Devices

What are medical devices?

What is a medical device in regulatory terms? Section 201(h) of the Federal Food, Drug, and Cosmetic Act defines devices by their intended use: diagnosing, curing, treating, mitigating or preventing disease, or affecting the structure or function of the body. That includes blood pressure cuffs, glucose meters, infusion pumps and imaging systems, and it can include software on its own.

Device classes and pathways

• Class I: Lowest risk. Most Class I devices are exempt from premarket notification.
• Class II: Moderate risk. Most need a 510(k) showing substantial equivalence to a predicate device.
• Class III: Highest risk. Most need Premarket Approval (PMA).
• De Novo: A pathway for novel low to moderate risk devices that have no predicate.

Software as a medical device

The FDA uses the IMDRF definition of Software as a Medical Device (SaMD): software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. Not all health software is a device. Section 520(o)(1)(D) of the FD&C Act excludes software that only transfers, stores, converts formats of or displays device data and results, unless it is intended to interpret or analyze that data. The FDA's Clinical Decision Support Software guidance, issued in January 2026, explains which decision support functions for health care professionals are not devices.

Why do medical devices matter for software teams now?

• Quality system rules: Since February 2, 2026, the FDA's Quality Management System Regulation incorporates ISO 13485:2016 by reference.
• Cybersecurity: Section 524B of the FD&C Act requires sponsors of cyber devices to submit a plan for postmarket vulnerability management, maintain cybersecurity processes, provide updates and patches, and supply a software bill of materials. The FDA's current premarket cybersecurity guidance was issued on February 3, 2026.
• AI-enabled devices: The FDA's final guidance on Predetermined Change Control Plans for AI-enabled device software functions, finalized in December 2024 with a current version dated August 2025, lets manufacturers describe planned model changes in the marketing submission. A separate draft guidance on AI-enabled device software lifecycle management, issued in January 2025, had not been finalized as of October 2026.
• Wellness products: In January 2026 the FDA revised its General Wellness guidance to clarify that some non-invasive wearables that estimate physiologic values can be low risk wellness products if they make no disease claims.
• Remote monitoring billing: For Medicare remote physiologic monitoring, the device must meet the FD&C Act definition of a medical device, though it does not have to be FDA cleared, which is a CMS rule that affects device choice.

What are the main medical device standards?

• IEC 62304: Life cycle processes for medical device software development and maintenance.
• ISO 13485:2016: Quality management system requirements, now incorporated into the FDA's QMSR.
• ISO 14971:2019: Risk management for medical devices, including software, from concept through decommissioning.
• IEC 62366-1: Usability engineering to find and reduce risks caused by use errors.
• IEC 80001-1:2021: Risk management for organizations that connect medical devices and health software to IT networks.
• IEEE 11073 and the HL7 FHIR Personal Health Device guide: How personal health devices represent measurements, and how that data maps to FHIR Observation and Device resources.
• Unique Device Identification: Device labels carry a unique device identifier, and labelers submit key data to the FDA's Global Unique Device Identification Database (GUDID).

How does medical device integration work step by step?

• 1. Choose devices with documented interfaces: Prefer devices that publish their data format and support standard profiles, such as Bluetooth health profiles based on IEEE 11073.
• 2. Connect the device: Pair through a phone app, a home hub or a bedside gateway, and handle reconnection and battery limits.
• 3. Capture with context: Record the time, units, device identifier and patient for every reading.
• 4. Validate and map: Reject impossible values, convert units, and map readings to FHIR Observations or HL7 v2 ORU messages.
• 5. Route to clinical systems: Send data to the EHR, a monitoring dashboard or an alerting service.
• 6. Secure every link: Encrypt data in transit and at rest, authenticate devices and users, and log access.
• 7. Monitor in production: Track missing readings, device errors and integration failures.

Medical device networking

In hospitals, medical device networking is a safety issue as well as an IT issue. IEC 80001-1:2021 asks organizations that connect devices to IT networks to manage risks to safety, effectiveness and security. In practice that means keeping an inventory of connected devices, separating device networks from general traffic, planning how devices are patched, and testing that monitoring and alarms keep working when the network changes.

Interoperable device design

The FDA's 2017 guidance on interoperable medical devices recommends what manufacturers should include in premarket submissions and labeling for devices that exchange data with other systems. If you build the device, document the interface, the data it sends and the limits of its use. If you integrate a device, ask the manufacturer for that documentation before you design the data path.

Hospital devices versus home devices

Hospital devices such as monitors, pumps and ventilators usually connect through vendor gateways and send HL7 v2 messages to the EHR, with strict rules about which data is validated by a nurse before it enters the chart. Home devices connect through phones or cellular hubs, send data less often and depend on patients to use them correctly, so setup, reminders and support matter more.

Alarms and alerting

Device data is only useful if the right person sees the right signal. Set thresholds with clinicians, route alerts by urgency and role, avoid duplicate alerts for the same event, and review alert volumes regularly. Too many alerts lead people to ignore them, which is a safety risk in its own right.

Device data in the EHR

Decide which readings belong in the chart and which stay in a monitoring system. Many organizations file summaries or validated readings to the EHR and keep high frequency raw data elsewhere, so the chart stays readable and clinicians can still reach the detail when needed.

What are medical devices best practices for software teams?

• Decide regulatory status early: Write down the intended use and check whether the software is a device before design starts.
• Use standards: IEEE 11073 and HL7 International's FHIR and HL7 v2 standards instead of device specific formats where possible.
• Keep device data traceable: Store the device identifier, firmware version and time source with each reading.
• Plan for cybersecurity: Threat modeling, a software bill of materials and a patching process.
• Design for use errors: Apply usability engineering to setup and alarms, not only to screens.
• Protect PHI: Apply the HIPAA safeguards HHS requires and sign Business Associate Agreements with platform vendors.
• Track device identity: Use unique device identifiers and keep an inventory of devices in use.

What are the common mistakes with medical devices and software?

• Assuming software is not a device: Adding analysis or recommendations can change regulatory status.
• Unclear time stamps: Device clocks drift, and readings without reliable times mislead clinicians.
• No plan for lost connections: Readings disappear when phones or hubs go offline without buffering.
• Closed device formats: Locking into a device that cannot share data in a documented way.
• Security as an afterthought: Connected devices without update plans become long term risks.
• Ignoring the clinical workflow: Data that arrives in the EHR without context or alerts is rarely used.

What does medical device work mean for your build plan?

• Regulatory status: Whether any part of your software is a device, its class and the pathway.
• Devices: The number of device types and manufacturers, and how each connects.
• Integration: EHR interfaces, including the FHIR APIs certified EHRs offer under ASTP/ONC rules, plus monitoring dashboards and alerting.
• Quality system: IEC 62304 processes, ISO 13485 and QMSR documentation if you build a device.
• Cybersecurity: Section 524B work, testing and a patching plan.
• Billing: If devices support billable services such as remote monitoring, the data that feeds X12 837 claims.
• Operations: Device logistics, support and monitoring after launch.

How Agnotic can help

Agnotic Technologies is a software development services company. We build the software around medical devices: Bluetooth device integration, mobile and gateway apps, data pipelines into FHIR and HL7, monitoring dashboards and EHR integration, with HIPAA safeguards and security built in. We work with your regulatory advisors when software may be a device. You own the code.

Sources

• FDA: Overview of device regulation
• FDA: Software as a Medical Device (SaMD)
• 21 U.S.C. 360j: General provisions, including section 520(o)
• FDA: Quality Management System Regulation (QMSR)
• FDA: Cybersecurity in Medical Devices guidance (2026)
• FDA: Predetermined Change Control Plans for AI-enabled device software functions
• ISO 14971:2019: Application of risk management to medical devices
• HL7 FHIR Personal Health Device implementation guide