Sep 4, 2026
Breaking News: MDR classes explained for EU medical device classification
Regulatory

What falls under regulation in healthcare and medical technology

September 2, 2026
metal, bridge, architecture, steel, construction, old, industrial, under the bridge, haze, under tracks

What being under regulation means in medical markets

In healthcare and medical technology, being under regulation means a product, service, workflow or dataset is subject to enforceable rules because it can affect patient safety, product quality, clinical decision-making, privacy or public health. The issue is not simply whether a company operates in healthcare. The more useful questions are what the offering does, what claims are made about it, who uses it, and what harm could occur if it fails or is misused.

A low-risk wellness tool, a diagnostic algorithm, a sterile implant, a clinical laboratory test and a cloud service handling electronic protected health information may all sit in very different regulatory categories. Each needs to be assessed on its own facts. For more industry coverage, see the Regulatory section.

hammer, libra, dish, justice, law, jurisdiction, paragraph, order, regulation, judge, justice, justice, justice, justice, law, law, judge, judge, judge, judge, judge

The main triggers that bring something under regulation

Regulators usually do not rely on branding alone. They look at intended use, risk, evidence, data flows and market behavior. A product may become regulated when it is intended to diagnose, cure, mitigate, treat or prevent disease, or when it affects the structure or function of the body. In medical device regulation, intended use is central because the same technology can be treated differently depending on its claims and functionality.

For example, software that stores general lifestyle notes may sit outside medical device oversight. Software that analyzes patient images to support diagnosis may fall into a device software category. A wearable that counts steps for fitness is different from a wearable that alerts clinicians to a potentially dangerous cardiac rhythm. The hardware may look similar, but the medical purpose and risk profile are not the same.

Data handling can also trigger obligations. A vendor that creates, receives, maintains or transmits electronic protected health information for a HIPAA covered entity may have direct security duties as a business associate. That status does not depend on whether the vendor describes itself as a healthcare company. It depends on the relationship, the data and the regulated function being performed.

How regulated status changes the compliance burden

Once an activity falls under regulation, the organization usually has to move from informal controls to documented, auditable processes. The exact requirements vary by jurisdiction and product type, but the pattern is familiar: define the intended use, classify risk, build evidence, control changes, monitor performance and keep records that show decisions were made through a reliable system.

Area Why it may be regulated Typical obligations Evidence to document
Medical devices The product is intended for a medical purpose and may affect patient safety. Risk classification, premarket submission or exemption analysis, labeling controls, quality system duties and post-market reporting. Intended use statement, device classification rationale, risk file, design controls and clinical or performance evidence.
Device software and AI-enabled tools The software performs or supports a medical function, such as diagnosis, triage or treatment guidance. Software documentation, validation, cybersecurity planning, change control and, when applicable, marketing authorization. Software requirements, verification and validation results, algorithm change plan, training and test data controls.
IVD products and laboratory tests The test produces information about samples taken from the human body for diagnosis, screening or monitoring. Analytical and clinical performance evidence, quality controls, labeling and conformity assessment requirements. Performance studies, specimen handling procedures, limitations and quality records.
Health data services The organization handles identifiable health information for a regulated entity or in a regulated transaction. Administrative, physical and technical safeguards, risk analysis, incident response and contractual controls. Security risk assessment, policies, access logs, vendor agreements and training records.
Marketing claims Public statements create a medical purpose or imply clinical performance. Claim substantiation, labeling review, promotional controls and corrective action if claims overstate evidence. Approved claim library, evidence mapping, review history and version control.

The practical point is that regulated status is not a single requirement. It is a chain of obligations. A company may need one pathway before market entry, another set of controls during production and separate duties after distribution.

Medical device regulation is risk based

The U.S. Food and Drug Administration uses a risk-based framework for medical devices. FDA materials describe Class I devices as generally lower risk, Class II devices as moderate risk and Class III devices as higher risk. If a Class I or Class II device is not exempt, a 510(k) premarket notification may be required. For many Class III devices, premarket approval is the route because FDA evaluates reasonable assurance of safety and effectiveness.

This classification approach matters because being under regulation does not always mean the same level of review. Some products are subject to general controls, some require special controls, and some need extensive premarket evidence. A manufacturer should not assume that a product is unregulated because it appears simple, or that it needs the most burdensome pathway because it has a medical use. The classification question comes first.

Post-market duties are part of the regulated lifecycle. FDA medical device reporting requirements require manufacturers to report certain deaths, serious injuries and malfunctions within defined time frames, including 30 calendar days for many reportable events and shorter five-workday reporting in specified circumstances. Compliance therefore does not end when a product is cleared, approved or launched.

Recent regulatory changes that affect the meaning of compliance

Regulatory status is not static. Requirements can change even when the underlying product has not changed. Several recent dates are important for medical technology teams reviewing their obligations in 2026.

In the United States, FDA published the Quality Management System Regulation final rule on February 2, 2024. The rule became effective on February 2, 2026 and revised 21 CFR Part 820 by incorporating ISO 13485:2016 by reference. In practical terms, device manufacturers operating under FDA quality system requirements need to align quality processes, documentation and audit readiness with the QMSR framework rather than relying only on older quality system terminology.

In the European Union, the Medical Device Regulation and In Vitro Diagnostic Medical Device Regulation remain central to market access. Regulation (EU) 2023/607 extended certain MDR transition periods, subject to conditions, including dates that run to December 31, 2027 for higher-risk devices and December 31, 2028 for many medium- and lower-risk devices. Regulation (EU) 2024/1860 addressed IVDR transition issues, gradual EUDAMED rollout and obligations linked to anticipated interruption or discontinuation of supply for certain devices.

For health data, HHS Office for Civil Rights issued a HIPAA Security Rule notice of proposed rulemaking on December 27, 2024, which was published in the Federal Register on January 6, 2025. As a proposal, it should not be treated as a final rule. However, it signals regulatory attention on cybersecurity, risk analysis and safeguards for electronic protected health information.

For AI-enabled medical device software, FDA finalized guidance in August 2025 on predetermined change control plans for AI-enabled device software functions. The compliance message is straightforward: adaptive or iterative software changes should be planned, bounded and documented rather than handled as informal product updates. See also: Implants.

A practical workflow for deciding whether something is under regulation

Teams can reduce uncertainty by using a structured assessment before launch, investment or market expansion. The following workflow is not a substitute for legal advice, but it reflects how regulatory and quality teams commonly organize an initial review.

  1. Define the actual function. Describe what the product or service does in plain language, including users, setting, inputs, outputs and decisions affected.
  2. List every claim. Collect website copy, sales decks, app store text, labels, training materials and demonstrations. Claims often determine intended use.
  3. Identify the user and patient impact. Distinguish between administrative support, wellness, clinical decision support, diagnosis, treatment and monitoring.
  4. Map jurisdictions. A product sold in the United States, the European Union and other markets may face different classification rules and evidence expectations.
  5. Check data status. Determine whether personal data, protected health information, clinical data or device-generated data is created, received, maintained or transmitted.
  6. Classify risk. Ask what could happen if the product gives an incorrect result, fails silently, is unavailable, is breached or is used outside its limitations.
  7. Build the evidence file. Document why the product is regulated, exempt, outside scope or subject to a lighter policy approach. Keep the rationale version controlled.
  8. Reassess after changes. New claims, new users, algorithm updates, new markets or new integrations can change the regulatory conclusion.

The most valuable output is not a one-line answer. It is a traceable rationale showing why the team reached that answer and what evidence supports it.

Common mistakes when teams assume they are not regulated

One common mistake is treating “software only” as a reason to ignore medical regulation. Modern regulatory frameworks focus on function and risk, not just whether a product is physical. Software that drives, informs or replaces clinical judgment can require serious regulatory analysis.

Another mistake is separating marketing from compliance. A product may be designed as a general wellness tool but marketed with disease-related claims. Those claims can create a regulated intended use even when the engineering team did not originally plan a medical device.

A third mistake is assuming that outsourcing removes responsibility. Manufacturers, sponsors, covered entities and business associates can delegate tasks, but they often remain responsible for oversight, contracts, quality controls and records. Vendor management is therefore not a procurement formality; it is part of the compliance system.

Finally, teams often underestimate post-market obligations. Complaints, adverse events, cybersecurity vulnerabilities, field corrections and supply interruptions can all create reporting, investigation or communication duties. Being under regulation means maintaining vigilance after launch, not merely passing a premarket gate.

Frequently asked questions

Does being under regulation always mean FDA approval is required?

No. Some regulated products are exempt from premarket review, some require 510(k) clearance, some require De Novo classification, and some require premarket approval. The correct pathway depends on product type, intended use, risk and available classification rules.

Can a wellness app become a regulated medical device?

Yes, depending on its claims and functions. A general fitness or lifestyle app may fall outside medical device oversight, while an app that diagnoses, treats or monitors a disease may require device analysis. The same interface can have a different regulatory status if its intended use changes.

Does HIPAA apply to every company that handles health-related data?

No. HIPAA applies to covered entities and business associates in defined circumstances. Some consumer health apps may fall outside HIPAA but still face other privacy, consumer protection or state-law obligations. Organizations should analyze data source, relationship, contract role and user expectations.

What is the first document a medical startup should create?

A concise regulatory assessment is often the best starting point. It should describe intended use, claims, users, target markets, data flows, likely classification, evidence gaps and assumptions that need confirmation before commercialization.

How often should regulated status be reassessed?

It should be reassessed whenever the product, claim set, algorithm, user group, geography, clinical workflow or data relationship changes. A product that was low risk at launch may move into a regulated category after a new feature or promotional claim.