For years, getting a consumer health app connected to real clinical data meant one-off integrations, portal credentials, and a lot of patience. CMS is trying to change that with its Health Tech Ecosystem. At an April 2026 launch event, CMS introduced a Medicare App Library alongside an initial set of patient-facing apps, and in July 2026 it said numerous early adopters had reached general availability. Listings are now appearing: Samsung announced on September 8, 2026 that Samsung Health had been accepted into the Medicare App Library. This is voluntary, and CMS describes it as “a movement, not a mandate.” But for founders building patient-facing products, the requirements read like a practical engineering spec. This brief is about product and engineering choices, not medical or legal advice.
The six core requirements
CMS lists six core requirements for patient-facing apps. Identity verification using CMS-approved IAL2/AAL2 standards, such as mobile driver's licenses and passkeys. Medicare connectivity, enabling Medicare.gov notifications such as notices, explanations of benefits, and fraud alerts. Participation in a CMS review that discloses data sources, terms, and a security checklist. Trial access for Medicare patients if the app charges a fee. Allowing the app to be featured in the Medicare.gov discovery experience. And operating consistent with HIPAA when the company functions as a covered entity or business associate. CMS notes ACCESS Model participants are exempt from the review and trial-access requirements.
Identity is the first integration
CMS's process says to partner with ID.me or CLEAR for identity verification that meets IAL2/AAL2, and it mentions negotiated pricing for participants. The Interoperability Framework goes further: when a patient uses an approved IAL2 credential, networks should return records without requiring knowledge of specific providers or separate portal logins. Design your onboarding around that flow. Verified identity is not a compliance step at the end of signup; it is what unlocks the data that makes your product useful.
Connect through a CMS Aligned Network
Apps connect to a CMS Aligned Network directly or via a personal health record application. The Interoperability Framework criteria now in effect as of July 4, 2026 require networks to provide FHIR APIs following the US Core implementation guide with USCDI v3 or later, terminology compliance such as LOINC, RxNorm, and SNOMED, clinical documents as FHIR attachments, and encounter notifications using FHIR subscriptions where permitted. Build your data layer on FHIR resources from the start instead of mapping everything into a bespoke schema you will later have to translate back.
Patient app data path (CMS ecosystem, simplified)
1. Onboarding: IAL2/AAL2 verification (ID.me or CLEAR)
2. Consent + purpose of use captured (individual access)
3. Query via CMS Aligned Network (FHIR, US Core, USCDI v3+)
4. Normalize: LOINC labs, RxNorm meds, SNOMED conditions
5. Subscribe: FHIR encounter notifications where permitted
6. Audit: every access logged and visible to the patientPick a use case and meet its specifics
CMS defines use cases with their own requirements. Kill the Clipboard apps share data at check-in through QR codes, SMART Health Cards, or SMART Health Links and retrieve visit summaries in FHIR. Conversational AI assistants must show clear AI-generated result indicators with disclaimers and distinguish educational content from clinical guidance. Diabetes and obesity apps integrate clinical records for coaching, reminders, and alerts. In July 2026 CMS also launched additional pledge use cases, including modern scheduling, real-time benefits, price transparency, and clinical trial matching. Choose one primary use case and build it properly before stretching.
Plan for third-party review early
Before an app is listed, it must complete evaluation with either DiMe or DirectTrust, covering clinical evidence, privacy, security, usability, equity, and technical standards, and sign the CARIN Code of Conduct. That review will ask for evidence you can only produce if you designed for it: data flow diagrams, privacy disclosures in plain language, accessibility testing, security controls, and logs. Start a review evidence folder on day one and add to it with every release.
Audit and consent are product features
The framework expects networks to give patients an accounting of who accessed their data, when, and why, and to carry consent preferences with transactions. Mirror that in your own product. Give users a readable access history, clear controls over connected sources, and an easy way to disconnect and delete data. For a patient-facing app, transparency is also a growth lever: people share health data more readily with products that show exactly what happens to it.
Talk to the identity and review partners CMS lists before you commit engineering time. Their requirements, timelines, and costs will shape your roadmap more than any architecture diagram. If you are still scoping the first version, our guide to building healthtech MVPs without getting burned by compliance covers the groundwork.
Make the business case before the build
A listing brings visibility to Medicare beneficiaries, but it also brings real costs: identity verification per user, network connectivity, third-party review, and ongoing evidence. Model those against your revenue path. Direct-to-consumer subscription apps must offer trial access to Medicare patients if they charge a fee. Organizations offering technology-supported chronic care may look at the ACCESS Model, which CMS describes as outcome-aligned Medicare payment for participants that meet its requirements. Payer-facing teams should also track the January 2027 prior authorization API deadline , which leans on the same FHIR plumbing.
Design for older adults from the start
The Medicare population includes many older users and caregivers acting for them. Large tap targets, readable type, plain-language explanations of identity verification, and support for personal representatives are not polish; they decide whether onboarding completes. Test identity flows with real older adults, because a verification step that fails silently will lose users before they ever see their data.
Founder takeaway
The Medicare App Library gives patient-facing apps a credible distribution channel and a clear technical bar. Decide early whether you will pursue it, then build toward it: IAL2/AAL2 identity, FHIR-native data through a CMS Aligned Network, use-case-specific features, review evidence from day one, and patient-visible audit and consent. Even if you never list, those choices make your product easier to sell to providers and payers. HIPAA obligations still apply underneath all of this; we wrote up what to build while the HIPAA Security Rule update is pending . Weighing a listing for your product? Talk to the CodeFlamme team .
