The billing threshold is not a care plan

When Medicare began paying separately for remote physiologic monitoring in the late 2010s, it did something sensible. It recognised that a nurse reviewing a heart-failure patient's weights at home is doing clinical work, and it created a way to pay for that work. The structure of the payment followed the logic of a fee schedule. One code pays for setting up the device and teaching the patient to use it. Another pays for the device supply, but only in a thirty-day period in which the patient has recorded readings on a minimum number of days. Others pay for the clinician's management time, counted in minutes and requiring interactive communication with the patient.

Each of those requirements is reasonable on its own. Together they create a shape, and products grow into the shape of whatever pays for them. I have watched it happen across our industry, and I have watched it happen inside Ardenwick, where I am responsible for the product that more than two hundred health systems and medical groups use to monitor about 118,000 patients. I want to argue that a product leader in remote monitoring has a specific duty here: to design for what the patient needs, to support accurate billing for what was actually done, and to refuse the features whose real purpose is to manufacture the count.

How a payment rule becomes a feature

The first sign is usually innocent. A practice asks to see which patients are short of the required days with a week left in the month. That is a fair request. Practices are the billing entity, they carry the compliance risk, and they need to know which claims they can support. We built that view in 2021 and I would build it again.

The second request is different. Could the patient receive an extra reminder on day twenty-three if she is still two days short? Could the reminder be louder, or come with a phone call from a medical assistant? Could the device prompt a reading at a time of day when the patient is likely to be standing next to it? Each step is small, and each can be described as engagement. By the time a product has a dozen of them, its reminder logic is organised around the billing month rather than around the patient's illness.

In 2022 our own sales team brought me a proposal of exactly that kind, modelled on what customers had seen elsewhere: an escalating sequence of reminders keyed to the days remaining in the billing period. I declined it, and the reason was in our data. Among patients with hypertension whose blood pressure had been under control for six months, daily readings were changing almost nothing. Medication changes in that group came from symptoms, from scheduled visits and from the occasional reading far outside the patient's usual range, not from the day-to-day series. We were asking people in their seventies to take readings so that a claim could be filed, and the readings were then lengthening a nurse's worklist.

What the nurse's minutes are for

The time-based codes create a quieter version of the same problem. Management time has to be documented, and a product can make documenting it easy or hard. Easy is right. But a product can also make the minutes accumulate: a timer that runs whenever a patient's record is open, a call script that lengthens a routine contact, a monthly summary task that exists mainly to be timed.

Our monitoring nurses, and the nurses at our customers, have a fixed number of hours. Every minute spent on a stable patient to complete a month's management time is a minute not spent on the heart-failure patient whose weight has risen three pounds in two days. After we redesigned our heart-failure alerts in 2023, nurse time per patient per month fell from 34 minutes to 21, and the nurses told us the freed time went to the patients they had been worrying about. Some customers also noticed that fewer of their patients reached the management-time threshold in a given month. Those are the same fact seen from two different chairs.

I do not think the answer is to ignore the codes. Practices depend on that revenue to employ the nurses who do the work, and a monitoring product that cannot support accurate billing will not be bought. The answer is to be clear about what the product is for. Our timer counts only the minutes in which a clinician is actively working on a patient's record, and it stops when the screen is idle. The call note records what was discussed and decided, because that is what a reviewer would look for. We report to each customer the share of billed minutes that included a change in care, not because a rule requires it but because it is the most honest measure of whether the time was well spent.

Designing to the patient's need, and saying so

The harder change was to reading schedules. Since 2023 a clinician can move a patient whose condition has been stable for a set period onto a reduced schedule, such as three readings a week, with an automatic return to daily readings if a value falls outside the patient's range. About 23 per cent of our hypertension patients are now on reduced schedules. For many of them, in many months, the practice cannot bill the device-supply code.

That cost our customers money, and it cost us money too, because our fee had been tied to an enrolled patient in a billable month. We introduced a lower maintenance fee for patients on reduced schedules, which lowered our revenue per hypertension patient by about 11 per cent in 2024. Two customers told us plainly that they preferred the old arrangement, and one of them left. I understood their position. They had built staffing plans around a revenue stream, and we had changed its shape without asking them first.

Government auditors have published concerns about remote monitoring billed to Medicare without clear evidence of the care it was meant to support, and payers revise these rules from year to year. I expect more scrutiny, not less, and I think a vendor whose product is organised around the count will find its customers exposed when that scrutiny arrives. But that is a defensive argument, and it is not my main one.

My main argument concerns what a product leader owes the people at either end of the connection. The patient owes us nothing. She has agreed to step on a scale or wrap a cuff around her arm because her doctor told her it would help. If it is not helping, she should be asked to do it less often. The nurse owes us nothing either. Her attention is the scarcest resource in the programme, and we should spend it only where it changes something. A payment rule can tell a product team what will be reimbursed. It cannot tell us what to build. That decision belongs to clinical need, and the product leader's job is to defend it when the billing month argues otherwise.