All Blogs
Samsung Health in the Medicare App Library: what developers can access
Samsung Health joins the Medicare App Library. Understand Samsung Health Data SDK access, partner approval and clinical-record integration limits.
“Kill the Clipboard” is a health technology initiative with a name we can get behind. The clipboard has had a very good innings. Its talent for asking people to repeat information is less endearing.
On September 8, 2026, Samsung announced that Samsung Health had been accepted in the Medicare App Library, a directory of third-party tools that beneficiaries can connect to their health data. Samsung also reported CMS recognition for its work with b.well on “Kill the Clipboard”, alongside a partnership with Lark for coaching and chronic-disease programmes. These are related parts of its connected-care strategy, with distinct roles. Samsung announcement.
For a person using the app, bringing records and everyday health information closer together is an attractive direction. For a developer, the next step is to draw the data map. A familiar logo on both sides of a diagram can conceal quite a lot of plumbing.
Samsung Health Data SDK is the documented wellness route
Samsung Health Data SDK gives Android applications access to selected data in the Samsung Health store, including wearable-derived activity, sleep, heart rate, and skin temperature. Its documented scope is fitness and wellness. The overview does not establish that the SDK exposes the clinical records associated with the Medicare announcement. Samsung Health Data SDK overview.
That distinction is useful when deciding what to build. A product based on nightly sleep records has one documented starting point. A product requiring clinical history needs its own verified access route, with its availability confirmed before the team commits to a feature that depends on it.
Samsung also distinguishes development from distribution. Developer mode supports testing; distributing an SDK app requires partnership approval and registration of app information. Writing data requires an approved access code. Those steps belong in the project plan early, ideally before someone has promised a launch date in a slide deck. App creation process.
Follow each handoff
Map the product around the source of each record, the user authorisation, the application receiving it, and the next destination. That exercise is more informative than labelling everything “Samsung integration”.
Keep consumer record access, wellness data access, and provider workflow integration as separate questions until documentation or a specific agreement connects them. Each route has its own recipient and purpose; those details should be visible in the product plan.
The map should expose the awkward edges too. Does a record arrive once or update later? Is the source retained? Can a permission be revoked? Which part of the product becomes unavailable if one connection fails?
These are ordinary questions. Their answers determine whether the finished experience feels ordinary to the person using it, which is a considerably higher achievement than an impressive architecture diagram.
Make everyday history useful in a care conversation
Our enthusiasm here is for a specific kind of product: one that helps a person bring relevant history into a conversation with their care team.
For example, a consented summary could let someone review recorded activity and sleep around an appointment. It should include coverage, dates, and source information, and clearly distinguish what the wearable recorded from anything the person reported themselves. Building that experience requires both a documented source and an agreed destination for the summary.
Avoid sending a clinician every measurement simply because the system can collect it. An interface that turns a short appointment into a scroll through six months of steps has moved the administrative burden rather efficiently.
Build for the question being asked. Offer the short view first and make the underlying record inspectable. Let the recipient understand why this information is relevant and where it came from. For the wearable portion, Terra's Samsung Health integration uses the Android SDK to read data on the user's phone and deliver normalised records through webhooks and the REST API. That route covers Samsung Health measurements; clinical access still needs its own confirmation.
Samsung's inclusion in the directory gives this strategy a concrete consumer-facing milestone. The SDK and distribution documentation give builders something more practical: boundaries they can plan against. If those boundaries are clear in the implementation, the user has a better chance of getting the seamless experience promised in the announcement—and perhaps one fewer form to fill in.
