Current verified status
CMS publishes a voluntary Medicare App Library pathway for patient-facing apps that integrate with CMS Aligned Networks and meet one of three initial use cases. The pathway includes CMS-approved identity verification, independent vetting, interoperability, application materials, and CMS validation before listing.
These are published participation and listing requirements, not proof that a particular app is clinically effective, CMS-endorsed, covered by Medicare, accepted into the library, or eligible for ACCESS payment. Requirements and listings can change. Current authoritative requirements.
Authoritative primary sources
- CMS Medicare App Library requirements (page last modified August 24, 2026)
- CMS submission overview (page last modified August 20, 2026)
- CMS ACCESS model (page last modified August 12, 2026)
What the sources establish
- CMS publishes a voluntary participation, evaluation, application, and listing pathway for patient-facing apps serving people with Medicare.
- The initial use cases are Kill the Clipboard, Conversational AI Assistants, and Diabetes & Obesity Prevention and Management.
- Published requirements address identity, interoperability, third-party evaluation, CMS review, and launch; ACCESS has a separate and conditional payment relationship.
Requirements decision object
Use this source-dated table to test readiness. It separates what CMS currently publishes from details that remain open and require direct confirmation.
| Field | Current published requirement | Decision use or limit | Primary source |
|---|---|---|---|
| Use-case pathway | Integrate with a CMS Aligned Network and meet at least one of three initial use cases: Kill the Clipboard; Conversational AI Assistants; or Diabetes & Obesity Prevention and Management. |
| CMS requirements |
| Target user | People with Medicare using patient-facing apps or technology-enabled care options. CMS invites health app developers, tech-enabled organizations, and innovators to apply. | Do not assume that every health app, provider tool, or enterprise workflow is eligible. | CMS requirements |
| Identity requirements | Support secure identity verification using CMS-approved IAL2 and AAL2 standards; CMS directs applicants to ID.me or CLEAR. | Treat identity implementation as a prerequisite, not a post-listing enhancement. | CMS requirements |
| Third-party review route | Complete independent evaluation through either the DiMe Seal route or CARIN Consumer-Facing Applications accreditation through DirectTrust; CMS also states that applicants sign the CARIN Code of Conduct. CMS describes review across clinical evidence, privacy, security, usability, equity, and technical standards. | A product should select and verify one current route directly with the named reviewer. | CMS requirements |
| Clinical evidence | Clinical evidence is a named pillar of third-party evaluation. | The CMS pages checked do not publish a detailed evidence threshold or required study design. Listing must not be presented as proof of effectiveness. | CMS requirements |
| Privacy/security | Privacy and security are named third-party evaluation pillars. CMS review includes data handling, privacy disclosures, disclosure of data sources and terms or agreements, and a security checklist. HIPAA applies when the app is a covered entity or business associate. | Confirm the product's actual legal role and current reviewer requirements; do not treat the App Library page as replacing applicable law. | CMS requirements |
| Usability/accessibility | Usability is a named third-party evaluation pillar. | The CMS pages checked do not name a separate accessibility standard or accessibility test. Accessibility evidence therefore remains an open verification item. | CMS requirements |
| Equity | Equity is a named third-party evaluation pillar. | The CMS pages checked do not publish a detailed equity scoring rubric. | CMS requirements |
| CMS Aligned Network/FHIR connectivity | Connect to a CMS Aligned Network directly or through a Personal Health Record. CMS's submission overview specifies FHIR R4 and SMART on FHIR; use-case requirements add FHIR exchange and visit-summary functions where applicable. CMS also lists enabling Medicare.gov beneficiary notifications, including notices, EOBs, and fraud alerts, as a core patient-facing-app requirement. | Validate the exact use-case data flow and current network acceptance criteria before claiming readiness. | CMS submission overview |
| CMS review access | CMS validates use-case alignment, CMS Aligned Network connectivity, data handling, and legal agreements. A fee-charging app must provide trial access for Medicare patients. CMS says ACCESS participants are exempt from CMS Review and Trial Access because those requirements are addressed through ACCESS participation. | An exemption is limited to qualifying ACCESS participants; it must not be generalized to other applicants. | CMS requirements |
| Launch/discovery | After the pledge, identity implementation, network connection, third-party vetting, application, and CMS review, an approved app can be featured in the Medicare App Library on Medicare.gov. The application requires program and listing materials. | Application or review is not listing. Listing is not CMS endorsement or clinical proof. | CMS requirements |
| ACCESS/payment relationship | CMS says qualifying technology-supported chronic-care organizations may separately apply to ACCESS. ACCESS participants that also pledge to the Health Tech Ecosystem are featured with a special designation indicating ACCESS participation and Medicare coverage status; ACCESS tests outcome-aligned payments in Original Medicare. | App Library inclusion is not itself a payment determination, and neither pathway guarantees clinical effectiveness, coverage, or payment for a particular product. | CMS ACCESS model |
| Unknowns | The pages checked do not publish detailed scoring thresholds for clinical evidence, usability, accessibility, equity, or technical standards; a complete public application link; decision timelines; category-level acceptance counts; or product-specific coverage and payment determinations. | Obtain current instructions from CMS and the selected vetting partner before a product-specific eligibility or launch decision. | CMS requirements |
| Next source-check date | 2026-09-10, or sooner if CMS changes the requirements, submission, or ACCESS pages or application access. | This is a P4L monitoring control, not a CMS deadline. | CMS requirements |
What this does not establish
- Approval, acceptance, clinical effectiveness, Medicare coverage, payment, or CMS endorsement of a particular app.
- That the pages checked publish every technical or evaluation threshold needed for a product-specific readiness decision.
- That current requirements, partners, application access, listings, or ACCESS rules will remain unchanged.
Prevention for Longevity (P4L) interpretation
P4L treats the App Library as a distribution and trust pathway that must be assessed together with identity, interoperability, evidence, privacy, usability, equity, CMS review, and any separate ACCESS eligibility.
This paragraph is P4L interpretation, not a statement by CMS.
Record maintenance
- Official sources checked
- 2026-09-03
- CMS requirements page last modified
- 2026-08-24
- Next source check
- 2026-09-10, or sooner after a CMS change
Related P4L records
Record provenance
- Last verified
- 2026-09-03
- Stable URL
- https://preventionforlongevity.org/signals/medicare-app-library/
- Canonical requirements object
- volatile-records.json · medicare_app_library