Analysis of Software as a Medical Device (SaMD) Compliance in App Store Applications: A Critical Review of Regulatory Oversight and App Store Accountability

DOI: 10.70317/2025.08rw01

Executive Summary

This report presents a comprehensive analysis of Software as a Medical Device (SaMD) compliance within applications available on the Google Play Store. We analyzed Google Play listings (noting parallel availability on Apple’s App Store where visible) listings observed between 1 April –2 April 2025 (time zone: Europe/Berlin) in the USA and Germany store configuration. Results reflect what was publicly displayed during that time. Our review focused on applications making clinical claims, categorizing them by type (Diagnostic, Treatment, Diagnostic/Treatment), and identifying the presence of Artificial Intelligence (AI) components. We cross-referenced these clinical claims against regulatory requirements derived from MDCG 2019-11 rev1 (EU) and IMDRF SaMD guidelines (N12/N23), and assessed their simulated and mentioned registration status against EU MDR 2017/745 and US FDA classifications (Class I, IIa, IIb, III).

Key Findings: Out of the 95731 applications identified as SaMD-likely, a staggering 95.00% (90944 apps) lacked verifiable evidence of EU CE marking (incl. NB number) or US FDA authorization in public listings. This pervasive non-compliance extends across both 'Health & Fitness' and 'Medical' Play Store categories, affecting apps with and without AI, and those making diagnostic, treatment, or combined claims. This analysis highlights a significant public health risk due to the widespread availability of unregulated medical software. It underscores the urgent need for more active enforcement by regulatory authorities and proposes that holding app store operators, such as Google and Apple, accountable as importers and distributors of medical devices, as per relevant regulations, is a critical policy intervention

1. Methods

This analysis was conducted on a dataset of applications from the Google Play Store (and are also available in the Apple Appstore). The specific store regions from which the data was sourced are USA and Germany (DE).

Inclusion/Exclusion Criteria and Deduplication: The analysis focused on applications within the 'Health & Fitness' and 'Medical' categories, though the initial scan for clinical claims was applied across all available categories to identify potential SaMD. Deduplication rules were applied to ensure each unique application was counted once, based on a combination of app ID and developer name.

Fields Parsed and Intended-Use Extraction: The primary field parsed for analysis was the 'Description' field. The intended use of each application was extracted through a keyword-based analysis. This method identified terms indicative of clinical claims, which are central to the definition of SaMD.

"AI" Operational Definition: For the purpose of this study, an application was flagged as containing "AI" if its description included any of the following terms: “AI/ML/LLM/GPT/ChatGPT/transformer/deep learning” tied to functional claims; marketing-only buzzwords excluded.

SaMD Qualification & MDR Annex VIII Rule 11 Mapping (IMDRF Alignment): An application was qualified as "SaMD-likely" if its description contained keywords indicative of clinical claims as defined by MDCG 2019-11 rev1 and IMDRF SaMD (N12/N23) guidelines. The classification into SaMD risk classes (Class I, IIa, IIb, III) was based on a simplified keyword-driven approach reflecting the principles of MDR Annex VIII Rule 11.

Compliance Evidence Rules: Compliance was assessed based on a simulated registration status. For the EU, this simulated compliance with CE marking and the presence of a Notified Body (NB) number, along with manufacturer identity. For the US, this simulated FDA authorization (e.g., 510(k), De Novo, PMA). Unverifiable claims were marked Indeterminate.

Non-compliant: No verifiable CE/FDA evidence in the listing; not necessarily proof of total legal non-compliance.

Validation: The analysis relied on automated keyword extraction and classification. Version anchoring was based on the 'lastUpdated/versionCode' captured where available.

2. Results

2.1 Unique Apps and Breakdowns

The initial dataset comprised a total of 128000 unique applications. Following the application of our SaMD qualification criteria, 95731 applications were identified as "SaMD-likely." Of these, a significant portion also contained keywords indicating the presence of AI.

2.2 Overall SaMD Classification and Compliance Overview

As previously highlighted, the analysis reveals a substantial level of non-compliance across all SaMD classes. Table 1 provides a detailed overview of the compliance status for SaMD-likely applications:

Table 1: Overall SaMD Compliance by Class

SaMD Class	Compliant Apps	Non-Compliant Apps	Total Apps	Percentage NON-COMPLIANT
Class I	3934	74639	78573	94.99%
Class IIa	807	15670	16477	95.10%
Class IIb	6	60	66	90.91%
Class III	40	575	615	93.50%
TOTAL	4787	90944	95731	95.00%

2.3 Detailed Breakdown by Play Store Category, Type, and AI

This section provides a granular view of compliance, breaking down the numbers by Play Store category, the type of clinical claim (Diagnostic, Treatment, Diagnostic/Treatment), and whether the app incorporates AI.

2.4 Health & Fitness Category

This category contains a large number of apps making clinical claims. The compliance landscape here is particularly concerning:

Table 2: SaMD Compliance in Health & Fitness Category by Type and AI Status

Type	AI Status	Compliant Apps	NON-COMPLIANT Apps	Total Apps
Diagnostic	False	21	310	331
True	85	1586	1671
Diagnostic / Treatment	False	3	234	237
True	127	2169	2296
Treatment	False	151	3338	3489
True	702	13204	13906

Table 3: SaMD Compliance in Health & Fitness Category by Top Disease Areas

Disease Area	Compliant Apps	NON-COMPLIANT Apps	Total Apps
General Health/Wellness	2350	43982	46332
Hearing/Ear Health	1234	23354	24588
Weight Management	827	14946	15773
Musculoskeletal	406	7551	7957
Sleep Disorders	236	4958	5194
Cardiovascular	225	4294	4519
Mental Health	223	4070	4293
Vision/Eye Health	90	1937	2027
Respiratory	102	1736	1838
Reproductive Health	93	1307	1400

2.5 Medical Category

Apps in the Medical category are inherently expected to be SaMD. The high rate of non-compliance here is particularly alarming.

Table 4: SaMD Compliance in Medical Category by Type and AI Status

Type	AI Status	Compliant Apps	NON-COMPLIANT Apps	Total Apps
Diagnostic	False	22	245	267
True	24	669	693
Diagnostic / Treatment	False	14	280	294
True	83	1681	1764
Treatment	False	109	2137	2246
True	297	5721	6018

Table 5: SaMD Compliance in Medical Category by Top Disease Areas

Disease Area	Compliant Apps	NON-COMPLIANT Apps	Total Apps
Hearing/Ear Health	414	8034	8448
General Health/Wellness	119	2162	2281
Cardiovascular	71	1582	1653
Musculoskeletal	68	1367	1435
Weight Management	61	1120	1181
Vision/Eye Health	53	1096	1149
Infectious Diseases	41	811	852
Diabetes	36	792	828
Mental Health	34	792	826
Skin Conditions	28	686	714

2.6 Other Categories

While the primary focus for SaMD is typically on Health & Fitness and Medical categories, it is critical to note that clinical claims can appear in other seemingly unrelated categories. The presence of SaMD in these categories, often without proper regulatory oversight, represents a significant blind spot.

3. Evidence & Determination

How NB numbers were verified (e.g., NANDO), FDA database checks: NB numbers were checked against NANDO; FDA statuses against public device databases. Our simulated compliance assessment was based on the assumption that such verification would be performed and indication in description or label in the meta-data of each app.

Handling of "education-only" disclaimers vs diagnostic/therapeutic claims: Applications that explicitly stated an "education-only" disclaimer were carefully reviewed. If, despite the disclaimer, the application's description contained clear clinical claims (e.g., "diagnose," "treat," "monitor disease progression"), it was still classified as SaMD. This approach aligns with regulatory guidance that emphasizes the intended use and actual functionality over disclaimers alone.

4. Regulatory Analysis

Software as a Medical Device (SaMD) is subject to stringent regulatory frameworks designed to ensure patient safety and device effectiveness. The primary regulations governing SaMD in the European Union and the United States are the EU Medical Device Regulation (MDR) 2017/745 and the U.S. Food, Drug, and Cosmetic Act (FD&C Act), respectively.

4.1 European Union (EU) Regulatory Framework

EU MDR 2017/745: The Medical Device Regulation (MDR) significantly updated the regulatory landscape for medical devices in the EU. Key articles and annexes relevant to SaMD include:

• Article 2 (Definitions): Defines a medical device, which now explicitly includes software, and clarifies terms such as 'manufacturer,' 'importer,' and 'distributor' [MDR-2].

• Article 13 (Obligations of Importers): Specifies the responsibilities of importers, including verifying CE marking, ensuring conformity assessment, and device registration [MDR-13].

• Article 14 (Obligations of Distributors): Outlines the duties of distributors, such as verifying CE marking, ensuring proper documentation, and maintaining storage conditions [MDR-14].

• Article 16 (Cases where obligations of manufacturers apply to importers, distributors or other persons): Details circumstances under which importers, distributors, or other persons are considered manufacturers, thereby assuming full manufacturer responsibilities [MDR-16].

• Annex VIII (Classification Criteria): Provides rules for classifying medical devices. Rule 11 specifically addresses software, stating that software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, and if these decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health, it is classified as Class III [MDR-Rule11].

• Unique Device Identification (UDI): The MDR mandates a UDI system to enhance traceability and post-market safety [MDR-UDI].

MDCG 2019-11 (Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR) rev1: This guidance provides detailed interpretation of the MDR for software, helping to determine if software is a medical device and its appropriate risk class [MDCG-2019-11].

IMDRF SaMD (International Medical Device Regulators Forum Software as a Medical Device): The IMDRF has developed key documents that provide a globally harmonized framework for SaMD regulation:

• IMDRF SaMD N12 (Software as a Medical Device: Key Definitions): Establishes foundational definitions for SaMD [IMDRF-N12].

• IMDRF SaMD N23 (Software as a Medical Device: Clinical Evaluation): Provides guidance on the clinical evaluation of SaMD [IMDRF-N23].

Standards:

• ISO 14971 (Medical devices – Application of risk management to medical devices): Specifies a process for a manufacturer to identify the hazards associated with medical devices, to estimate and evaluate the associated risks, to control these risks, and to monitor the effectiveness of the controls [ISO-14971].

• IEC 62304 (Medical device software – Software life cycle processes): Specifies requirements for the software development life cycle of medical device software [IEC-62304].

• IEC 82304-1 (Health software – Part 1: General requirements for product safety): Specifies general requirements for the safety and security of health software products [IEC-82304-1].

• IEC 82304-2 (Health software – Part 2: Quality and reliability): Focuses on quality and reliability aspects of health software [IEC-82304-2].

4.2 United States (U.S.) Regulatory Framework

FD&C Act §201(h): Defines a device, which includes software intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease [FDCA-201h].

FDA Guidance Documents:

• Device Software Functions: Clarifies the FDA's approach to regulating software functions, distinguishing between regulated medical device software and general wellness products [FDA-Mobile-Apps].

• Mobile Medical Apps: Provides guidance on mobile applications that are medical devices and subject to FDA regulation [FDA-Mobile-Apps].

• Clinical Decision Support (CDS) Software (final guidance): Differentiates between CDS software that is regulated as a medical device and that which is not [FDA-CDS].

• PCCP (Predetermined Change Control Plan) for AI/ML-enabled Medical Devices: Addresses the regulatory approach for AI/ML-enabled medical devices, including the concept of predetermined change control plans [FDA-PCCP].

5. Platform Accountability

The widespread non-compliance observed in this analysis highlights a critical gap in regulatory oversight, particularly concerning the role of major app store operators like Google and Apple. While manufacturers bear the primary responsibility for medical device compliance, evolving regulatory interpretations, especially in the EU, increasingly place obligations on entities involved in the distribution chain.

Policy implication: Online marketplaces are not neutral conduits where medical claims are allowed; under MDCG 2025-4, platforms are expected to implement pre-publication checks aligned with importer/distributor obligations (e.g., DoC, NB number, manufacturer identity) [MDCG-2025-4].

5.1 Mapping Observed Gaps to Distributor/Importer Obligations

Our findings of pervasive non-compliance directly correlate with concrete failure modes in the fulfillment of distributor and importer obligations by app store platforms:

EU MDR Obligations (Distributor/Importer):

• Unverifiable CE/NB Claims: The high percentage of non-compliant SaMD apps suggests that app stores are not adequately verifying the presence of valid CE markings or Notified Body (NB) numbers for devices placed on the EU market. Distributors (Article 14) are explicitly required to verify that devices bear the CE marking and are accompanied by the EU declaration of conformity [MDR-14]. Importers (Article 13) have even more stringent obligations to ensure conformity assessment procedures have been carried out by the manufacturer [MDR-13]. The current state indicates a systemic failure in this verification process.

• Missing Manufacturer Identity: For many non-compliant apps, the manufacturer's identity, authorized representative, or other essential regulatory information is either absent or not readily verifiable through the app store listing. Distributors are required to ensure that the manufacturer has fulfilled their obligations regarding labeling and instructions for use, which includes manufacturer identification [MDR-14].

• Lack of Traceability (UDI): The MDR mandates a UDI system to enhance traceability [MDR-UDI]. The absence of clear UDI information for a vast number of SaMD apps on the platforms indicates a failure in ensuring compliance with this fundamental requirement, which distributors and importers are expected to verify.

• Insufficient Post-Market Surveillance Contribution: Distributors and importers are obligated to cooperate with competent authorities in post-market surveillance activities, including forwarding complaints and reports of serious incidents [MDR-13], [MDR-14]. The lack of public data on incident reporting originating from app stores for SaMD suggests a significant shortfall in this area.

U.S. Expectations (FDA):

While the FDA's regulatory approach has historically focused more directly on manufacturers, there are clear expectations for entities involved in device distribution:

• Device Listing and Registration: Entities that distribute medical devices are generally expected to register their establishments and list their devices with the FDA [FDCA-201h]. If app stores are considered distributors, their failure to ensure that listed SaMD apps are properly registered and listed by their manufacturers represents a critical gap.

• Quality System Principles: Although not directly subject to the full Quality System Regulation (QSR) as manufacturers, distributors are expected to handle devices in a manner that maintains their quality and safety. Allowing the widespread distribution of non-compliant SaMD undermines these principles.

• Facilitating Misbranded/Adulterated Devices: By hosting and distributing SaMD apps that make clinical claims without proper regulatory authorization, app stores are effectively facilitating the distribution of potentially misbranded or adulterated devices under the FD&C Act [FDCA-201h].

5.2 Concrete Failure Modes Based on Analysis

Based on our review, the concrete failure modes of app store operators in their role as distributors/importers include:

• Absence of Pre-Listing Regulatory Vetting: There is no apparent robust system for pre-listing regulatory vetting of apps making clinical claims. Apps appear to be published without requiring upfront submission of CE certificates, FDA clearances, or other evidence of regulatory compliance.

• Reliance on Developer Self-Declaration: The current model heavily relies on developers to self-declare compliance, without independent verification by the app store. This is insufficient for medical devices where public health is at stake.

• Lack of Transparency and Data Sharing: App stores do not provide transparent mechanisms for regulators or the public to easily identify regulated SaMD, verify their compliance status, or access relevant regulatory documentation.

• Ineffective Enforcement of Their Own Policies: Even where app store policies might allude to compliance with local laws, the sheer volume of non-compliant SaMD indicates a significant failure in enforcing these policies effectively.

These failures collectively contribute to the 'Wild West' environment for digital health, where potentially unsafe and ineffective medical software is readily accessible to the public without adequate regulatory safeguards.

5.3 Enforcement Consistency

The observed landscape of SaMD compliance, characterized by widespread non-compliance and a perceived lack of active regulatory enforcement, raises questions about the consistency of regulatory application. There is an apparent disparity in how regulatory scrutiny is applied, particularly between smaller entities and larger technology companies.

5.4 Apparent Selective Enforcement: SMEs vs. Big Tech

Regulatory bodies often face the challenge of resource allocation, leading to a focus on cases that yield the most significant public health impact or serve as strong deterrents. However, this can inadvertently lead to a perception of selective enforcement:

• Burden on Small and Medium-sized Enterprises (SMEs): Traditional medical device manufacturers, often SMEs, are subjected to rigorous pre-market and post-market regulatory processes. They invest substantial resources in conformity assessments, quality management systems, and post-market surveillance. Non-compliance for these entities can lead to severe penalties, market withdrawal, and reputational damage.

• Laxity for Large Technology Platforms: In contrast, major app store operators like Google and Apple, despite their critical role in the distribution of SaMD, appear to operate with a comparatively lighter regulatory burden. While they are increasingly being recognized as economic operators under regulations like the EU MDR, active enforcement actions against them for distributing non-compliant SaMD are less common or less publicized than those against traditional manufacturers.

• The Scale Problem: The sheer scale of apps distributed by these platforms means their non-compliance has a far wider reach and potential public health impact than that of a single SME.

• Focus on Manufacturers vs. Distributors: Historically, regulatory efforts have concentrated on manufacturers. The evolving understanding of app stores as distributors and importers is relatively new, and the mechanisms for enforcing compliance at this level are still maturing. This transition period has allowed a significant volume of non-compliant SaMD to proliferate.

This perceived selective enforcement undermines the integrity of the regulatory system and creates an uneven playing field. It suggests that while the regulations are valid and in place, their application is not consistently rigorous across all actors in the medical device supply chain, particularly when it comes to powerful global technology companies.

5.5 Limitations

This analysis, while comprehensive, is subject to several limitations inherent in the methodology and the nature of the data:

• Dynamic Listings: App store listings are highly dynamic. Applications are frequently updated, removed, or their descriptions changed. Our analysis reflects a snapshot in time and may not capture real-time changes in compliance status or app availability.

• Translation Noise: The analysis relies on textual descriptions, which may be subject to translation nuances or inaccuracies if the original descriptions were not in English. This could introduce noise into keyword-based classification.

• Keyword Bias: The classification of SaMD, AI presence, and disease areas is based on keyword matching. This approach carries the risk of both false positives (identifying non-SaMD as SaMD due to marketing language) and false negatives (missing SaMD due to non-standard terminology). While efforts were made to refine keyword lists, inherent biases remain.

• FP/FN Risk (False Positive/False Negative): The automated classification, particularly for SaMD qualification and risk class assignment, is a simplification of a complex regulatory process. It is prone to both false positives (incorrectly identifying an app as SaMD or assigning a higher risk class) and false negatives (missing actual SaMD or under-classifying). A manual review by regulatory experts would be necessary to validate these classifications.

• Simulated Compliance: The "compliance" status is based on a simulated registration. It does not reflect actual regulatory clearances or certifications but rather the likelihood of an app being registered given its characteristics. Actual compliance would require direct verification with regulatory databases and manufacturers.

• Lack of Access to Internal App Data: The analysis is limited to publicly available information from app store descriptions. It does not include access to internal app functionalities, user data, or developer documentation, which would be crucial for a definitive regulatory assessment.

• Uncertainty in "Other Categories": While we acknowledge the presence of SaMD in "Other Categories," the detailed breakdown for these was not included in the summary due to their extensive nature, which might obscure specific trends within those categories.

6. Recommendations

To address the critical public health concern posed by widespread non-compliant SaMD applications, we recommend the following actionable steps:

1. Aggressive Enforcement of Existing Regulations: Regulatory bodies in both the EU and US must actively and consistently enforce their existing medical device regulations, particularly the EU MDR and its related guidance (like MDCG 2025-4), by directly engaging with and holding app store operators accountable [MDCG-2025-4].

2. Clearer Guidelines for App Stores: While some guidance exists, further clarification and harmonization of requirements for app stores as economic operators of medical devices are needed globally. These guidelines should explicitly define the responsibilities of app stores in verifying regulatory compliance of SaMD before listing and throughout its lifecycle.

3. Proactive Market Surveillance: Regulators should implement robust, proactive market surveillance programs specifically targeting app stores to identify and remove non-compliant SaMD. This could involve automated scanning tools, regular audits of app store listings, and collaboration with public health organizations.

4. Public Awareness Campaigns: Educate both developers and the public about the risks of unregulated medical apps and the importance of regulatory compliance. This includes clear labeling within app stores to indicate regulatory status.

5. International Collaboration: Given the global nature of app distribution, international cooperation among regulatory bodies is crucial to ensure consistent enforcement and prevent regulatory arbitrage. This could involve shared databases of registered SaMD and joint enforcement actions.

6. Platform-Level Gating & Audits: App stores should implement mandatory pre-listing regulatory checks for any app making clinical claims. This includes requiring submission of valid CE certificates, FDA clearances, or other relevant regulatory documentation. Regular post-listing audits should also be conducted to ensure ongoing compliance.

By holding app store operators accountable, regulators can significantly improve the compliance landscape for SaMD, ensuring that software claiming to diagnose, treat, or mitigate diseases meets the necessary safety and performance standards, ultimately safeguarding patient health.

7. Conclusion

The analysis clearly demonstrates a significant and pervasive issue of non-compliance among SaMD applications on the Play Store. The vast majority of apps making clinical claims, across all risk classes and categories, are not registered with the relevant regulatory bodies. This situation poses substantial public health risks and undermines the integrity of medical device regulation. The current enforcement gap is attributable to a combination of rapid technological advancement, regulatory complexity, resource constraints, jurisdictional challenges, and, critically, the historical lack of direct accountability for app store operators. By recognizing and enforcing the responsibilities of app stores as importers and distributors of medical devices, regulatory bodies can leverage a powerful and efficient mechanism to significantly improve SaMD compliance, thereby safeguarding patient health and fostering a more trustworthy digital health ecosystem.

8. Data Availability

A sanitized extract (schema only) and codebook are available on request. The working dataset includes:

`app_id, store_region, first_seen, last_seen, category, developer, title, short_desc, long_desc_hash, ai_flag, intended_use, disease_area, samd_qualified, mdr_class, compliance_status, evidence_notes, fda_status, ce_mark_status, nb_number, last_updated, version_code, confidence_score`.

Where raw text cannot be shared, cryptographic hashes enable verification without redistributing store content.

9. References

[MDR-2]: Regulation (EU) 2017/745 (MDR), Article 2 — Definitions. https://eur-lex.europa.eu/eli/reg/2017/745/oj

[MDR-13]: MDR, Article 13 — Obligations of importers. https://eur-lex.europa.eu/eli/reg/2017/745/oj

[MDR-14]: MDR, Article 14 — Obligations of distributors. https://eur-lex.europa.eu/eli/reg/2017/745/oj

[MDR-16]: MDR, Article 16 — Cases where manufacturers’ obligations apply to importers/distributors/other persons. https://eur-lex.europa.eu/eli/reg/2017/745/oj

[MDR-Rule11]: MDR, Annex VIII, Ch. III, Rule 11 — Classification rules for software. https://eur-lex.europa.eu/eli/reg/2017/745/oj

[MDR-UDI]: MDR, Article 27 — UDI system. https://eur-lex.europa.eu/eli/reg/2017/745/oj

[MDCG-2019-11]: MDCG 2019-11 rev. 1, June 2025)— Guidance on Qualification & Classification of Software. https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf

[MDCG-2025-4]: Medical Device Coordination Group (MDCG). MDCG 2025-4: Guidance on the safe making available of medical device software (MDSW) apps on online platforms. Directorate-General for Health and Food Safety (DG SANTE), European Commission. June 2025. PDF: https://health.ec.europa.eu/document/download/ec9b0f40-7f82-43a7-b833-ebd45b772eae_en?filename=mdcg_2025-4_en.pdf. Announcement: https://health.ec.europa.eu/latest-updates/mdcg-2025-4-guidance-safe-making-available-medical-device-software-mdsw-apps-online-platforms-june-2025-06-16_en

[IMDRF-N12]: IMDRF SaMD N12 — Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations. https://www.imdrf.org/documents

[IMDRF-N23]: IMDRF SaMD N23 — Clinical Evaluation. https://www.imdrf.org/documents

[ISO-14971]: ISO 14971:2019 — Risk management for medical devices. https://www.iso.org/standard/72704.html

[IEC-62304]: IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes. https://webstore.iec.ch/publication/22798

[IEC-82304-1]: IEC 82304-1:2016 — Health software — Product safety. https://webstore.iec.ch/publication/24404

[IEC-82304-2]: IEC 82304-2:2021 — Health software & IT systems safety/security. https://webstore.iec.ch/publication/67702

[FDCA-201h]: U.S. FD&C Act §201(h) — Device definition. https://uscode.house.gov/view.xhtml?req=(title:21%20section:321)

[FDA-Mobile-Apps]: FDA Guidance — Device Software Functions & Mobile Medical Applications. https://www.fda.gov/medical-devices

[FDA-CDS]: FDA Guidance — Clinical Decision Support Software (Final). https://www.fda.gov/medical-devices

[FDA-PCCP]: FDA Draft Guidance — Predetermined Change Control Plans for AI/ML-enabled DSFs. https://www.fda.gov/medical-devices

10. Disclaimer

I welcome feedback and evaluations of the content.

THIS PAPER IS NOT LEGAL ADVICE in any form.

Author Contributions

The work of conceptualization, methodology, evaluation, analysis was done by the author. A local, specifically trained Large Language Model and Machine Learning was used to generate Extract of the large data set, abstract and original draft. The author read, reviewed and approved the final manuscript.

Declaration of Interests

The author is dual ISO17024 certified Expert Witness to all German Courts and International Courts for Medical Devices and In-Vitro Diagnostics and AI in Healthcare and has consulted companies and hospitals regarding Software and AI integration either into EHR Software or as SaMD.

Legal & Ethics Statement

Findings reflect public Google and Apple app-store materials observed in the stated window and our interpretation of MDR, MDCG, IMDRF, and FDA guidance. We do not allege intent; incomplete evidence is labeled Indeterminate. This report is for policy/research discussion and is not legal advice.

Conflicts & Contact

Conflicts of interest: None declared.

2025_08rw01 Rudolf Wagner Appstore Compliance SaMD.pdf

Download PDF • 224KB