Oura’s expanded partnership with Counsel through Medicare’s ACCESS model is worth paying attention to. There is a care provider at the other end of the wearable data, with responsibility for eligibility, enrollment and treatment. Oura will help interested members connect through its app; people with an Oura Ring can choose to share their data. In its September 17, 2026 announcement, Oura said Counsel plans to begin care in early 2027 for eligible patients with hypertension, obesity, hyperlipidemia and/or prediabetes, with no out-of-pocket cost. Oura’s announcement
Someone managing a chronic condition may already have sleep or activity information they want to discuss with a clinician. Making that easier seems a worthwhile use of all this data. There is also plenty of room to make it unnecessarily difficult: mismatched accounts, unexplained gaps, an update waiting in a portal nobody knows to visit. The handoff deserves as much curiosity as the ring.
For an app assembling that context, Terra’s Oura connection supplies supported sleep, activity and daily data through the same interface used for other wearables. The normalisation work stays below the patient-facing view; the team can spend its time on the missing nights and the clinical handoff. That is separate from participating in Counsel’s service or satisfying ACCESS reporting.
The dates need untangling
ACCESS itself is already running. The CMS Innovation Center’s Advancing Chronic Care with Effective, Scalable Solutions model began on July 5, 2026 and lasts ten years. It tests recurring payments to participating care organizations, with full payment tied to measurable health outcomes.
Counsel’s early-2027 plan sits within that wider model. There is another date to keep separate: April 1, 2027, when CMS’s newly announced tracks begin, alongside a follow-on period for chronic musculoskeletal pain. The September 15 expansion announcement covers heart failure, chronic obstructive pulmonary disease, substance use disorders and tobacco cessation. ACCESS serves Original Medicare; Medicare Advantage enrollees are not eligible for the model itself.
So the model launch, Counsel’s service and the new tracks have three different timelines. Combining them into one launch would make a tidier headline and a worse explanation of what a patient can actually use.
Counsel will confirm individual eligibility. Its planned no-cost care offer does not establish blanket Medicare reimbursement for buying a ring, and the announcement does not introduce a new public Oura API. The promising development is a planned care pathway. Its implementation and results are still ahead of us.
Those four missing nights
Consider a clinician looking at a hypothetical two-week sleep history with ten nights of readings. The other four could be missing because the patient did not wear the ring, the device did not sync, authorization expired or a processing job failed. That is quite a range of explanations to hide behind the same empty space.
We would much rather see a modest coverage note beside the trend: ten nights available, last received yesterday, four nights missing. If the system knows why, it can say so. If it does not, “reason unknown” is useful information too. The clinician can judge the available history without having to reverse-engineer the connection during an appointment.
There is some satisfying engineering behind that small piece of text. Keeping the time a measurement describes separate from the time it arrived lets an app recognize an older record that has only just come through. Retaining the source, units and relevant time zone keeps that record interpretable, including when someone travels. A successful sync today does not necessarily mean there is data about today.
It is worth keeping the device visible as well. Our comparison of sleep measurements across wearables shows why a familiar stage label should not make readings from different devices interchangeable.
Retries and corrections need the same care. A record delivered twice still represents one observation; an updated record needs enough history to explain why a previous report looked different. These are ordinary data problems, but the person looking at the chart should not have to know that a job ran twice. Nor should the patient have to defend their participation because an import failed.
On the measurement side, event-driven delivery can keep the view current without repeatedly polling each wearable. Delivering that measurement to an app and coordinating clinical care remain separate jobs.
The distinction between wearable context and clinical outcomes matters here too. CMS lists blood pressure, LDL cholesterol, HbA1c and weight among the outcome measures for the early cardio-kidney-metabolic track. More sleep records, or a better wearable score, do not by themselves establish improvement in those measures.
A service could put sleep and activity trends alongside blood-pressure readings to support a conversation, keeping the source and collection method of each visible. Deciding what those patterns mean clinically belongs in the care team’s design; the integration cannot establish that relationship by displaying the charts together.
The update has to reach someone
One detail in CMS’s technical FAQ deserves attention: posting an update to a provider’s own portal does not, by itself, satisfy care coordination. There must be an established sharing relationship or technical integration that gets it to the coordinating clinician and makes it accessible.
We’re pleased CMS spells this out. From the recipient’s side, another place to look for updates is quite a different proposition from receiving one. It is easy to become fond of a portal when you are the person building it.
CMS calls for updates at care initiation, clinical escalation and the end of each care period. By July 2027, ACCESS care providers must also connect to a CMS Aligned Network, health information exchange or similar trusted network so structured patient information can be queried through clinicians’ existing systems.
That makes delivery status a meaningful part of the product. A generated summary, a rejected transmission and a delivered update are different states, even if all three began with a successful click on “send.” Someone needs to notice and fix the failed delivery. Leaving it to the patient to discover that two services have not spoken to each other would be a disappointing use of all that integration work.
The summary itself can be restrained: the period covered, the measurement sources, meaningful gaps and a clear distinction between observations and interpretation. The author or system behind an interpretation belongs there too. That gives the clinician a way to assess a claim without treating every line in the report as equally authoritative.
CMS also requires specified measures to be reported through standards-based APIs it will host. That describes a reporting obligation; it does not document the Oura–Counsel data interface or establish access through Terra.
Connecting a ring should remain a choice
Before any of those updates, the right wearable account has to be attached to the right patient. An email address alone is a fragile basis for that relationship: a patient could use different addresses for their ring and their clinic. Explicit account linking, stable identifiers and a way to correct mistakes are worth the effort. Reconnecting should restore the relationship, without accidentally creating a second patient history.
Consent has a less visible engineering side. A patient who disconnects should be able to trust that collection has stopped, including in scheduled imports and jobs waiting to retry. A background worker does not get its own interpretation of the patient’s decision. Recording the permission’s scope makes it possible to enforce that decision where the work happens. Information already incorporated into a clinical record is a separate matter, to be handled through the care provider’s policies.
There is also a welcome limit on making hardware the patient’s problem. CMS permits voluntary use of devices people already own, but participants cannot require patients to buy or rent a device at their own expense to participate. A clinically appropriate pathway must exist without that purchase; it may include a device furnished by the provider.
That is a good principle to carry into the interface. Choosing not to connect a wearable is different from having a broken connection. The first person does not need an endless sequence of reminders to finish setting up their account. Both deserve useful care, and summaries that make sense with the information available.
Supporting the device a patient already owns becomes a more manageable product choice when each new brand does not mean another importer. Our WHOOP integration walkthrough shows how those authentication and parsing jobs accumulate. Terra handles the supported wearable connections through one integration; the care team can decide what deserves attention in the record.
We would be glad to see Oura and Counsel make it easier to bring personal health data into a clinical conversation. Part of doing it well will be making the service just as welcoming when someone decides to leave the ring out of it.
