A new care model needs more than a working app

What we found in the news

The February 12, 2026 version of the CMS ACCESS Model application document (opens in a new tab) described a voluntary test of payment for technology-supported chronic care. Its summary connected expanded options with:

“accountability for clinical and patient reported outcomes”

— Centers for Medicare & Medicaid Services, ACCESS application document

In March, the model was preparing for a planned July start. The document set out the model’s operating arrangement for applicants, including professional oversight and outcome responsibilities. It did not demonstrate that the model had improved care. It also did not make any software product a Medicare service simply because it could support communication.

Look beyond the demonstration

Imagine a team showing a promising digital service to a community partner. The screen is clear, the connection works, and the demonstration is reassuring. Then someone asks who answers if a participant is confused on a Saturday, or how the person's existing clinician learns about a concern.

Those questions belong in the design from the beginning. In this illustrative example, the software demonstration has shown one part of the experience. The remaining parts involve staffing, professional judgment, communication, and agreements between organizations.

At genus, we are interested in useful tools that fit the people and services around them. That fit takes more than a successful login.

Describe the care before choosing the channel

Start with what the service intends to do for a particular group of people. Identify the decisions that require a qualified clinician, the practical help a service colleague can provide, and the questions that need a different organization.

Then explain how someone reaches each part. A support button may handle technical problems without being a clinical contact. People should not have to discover that distinction by sending an important question to the wrong place.

Give the team time to test ordinary situations together. A forgotten password, an unanswered message, a change in the person's circumstances, or a preference for another communication method can reveal assumptions that a polished demonstration misses.

Make responsibility visible between organizations

A service may involve several partners while still needing one understandable explanation for the participant. Agree who introduces the offer, who confirms suitability, who manages clinical issues, and who coordinates an unresolved problem.

Describe how the new service relates to existing care. Avoid suggesting that a digital channel replaces a person's usual team unless that is the actual, appropriately agreed arrangement. Information sharing and professional responsibilities require their own review.

Give staff a way to raise questions about the boundaries. If two organizations both believe the other is following up, a carefully worded introduction will not fix the gap. Someone needs authority to resolve it.

Ask what the evidence really shows

A measure of use can tell a team whether people are opening an experience. It cannot, on its own, establish a clinical benefit or explain why someone stopped participating.

Keep claims proportional to the evidence available. If a service is being tested, describe the test and the questions it is meant to answer. If results are reported later, look at the population, the comparison, the period studied, and the limitations before turning them into a public promise.

Invite participants to describe the work the service adds to their day. A tool might make one task easier while creating another burden. That account deserves attention alongside the measures the organization has chosen.

For people considering a service

The offer should explain what participation involves, who provides the care, and how to ask about practical concerns. Someone should be able to say that a device, format, or schedule does not suit them without being treated as the problem to solve.

The genus connection

Current genus care apps and care walls provide configured places for resources, updates, and community participation. They can form part of an organization's communication experience when responsibilities and audience access are agreed.

Those capabilities do not establish clinical oversight, model eligibility, payment entitlement, or a health outcome. We make the connection here because a useful platform needs an understandable service around it. The organization should be able to explain that service before asking someone to rely on the tool.

One question before a launch

If the screen worked perfectly tomorrow, which parts of the care experience would still need a named person?