Selecting The Best Vendors for Your RPM Program

My 20-year adventure into the world of digital health started at the Mayo Clinic in Rochester, Minnesota with an exciting assignment: to develop and manage the requirements for a wearable continuous heart rhythm monitoring device.

After multiple iterations and a couple of collaboration partners, the idea finally saw the light 8 years later in 2011 and official recognition (in the form of an FDA approval) in 2012. And so the BodyGuardian was born, now owned by Boston Scientific.

In hindsight, the BodyGuardian ultimately was so successful, because it was first conceived and refined in the heads of three Mayo Clinic cardiologists. That is to say, the clinical case, the clinical application came first. The innovation and refinements by software engineers came second.

At one point we had a 512-page document capturing many of the monitor’s requirements — from its monitoring and alert capabilities to handling unexpected (but predictable) events. Many things were first thought through on paper, discussed, and refined before being put into electronics and software.

“I don’t want to learn Mainframe Programming”

As a fresh graduate at IBM Global Services in the 1990s I ended up in the team of a fabulous leader who made it his life’s mission to grow young professionals into accomplished human beings. He was tough and fair, friendly and stern.

One day, I came into his office and he gave me a new assignment: “Christian,” he said, “I want you to join this team at the Hamburg State Bank and develop a solution on the mainframe in PL/1.” I was shocked. Here I was, experienced in modern and object-oriented programming languages and I was asked to learn a programming language invented in 1964?

But of course I went, had great mentors and, since I did not “speak” the language, developed the whole program in a pseudo-language similar to what I knew — and I wrote the whole program in Microsoft Word. I “tested” it myself and with others by manually running through it multiple times, corrected my mistakes and made it ready to go.

Next, with the help of PL/1 experts, I translated the pseudo-language into PL/1, uploaded the whole program into the mainframe, fixed multiple syntax errors and then….it worked. It worked as intended, it did what it was supposed to do.

This was my first lesson that developing something on paper first and testing, reviewing, and improving it first will result in a more efficient, more effective approach to developing a superb solution

The Key Lessons Learned

So what does that have to do with selecting a vendor for your Remote Physiological Monitoring (RPM) program?

There are two lessons to observe. The first one is the one I just pointed out: that creating something on paper before investing into the “real thing” is oftentimes highly beneficial.

The second one is the timing of involving experts. In the PL/1 example, I leveraged the expertise of experienced staff efficiently at the time of implementation. In the BodyGuardian example, the expertise came first in the form of a clinical vision and clinical insight which set the right scope for the solution.

These days too many digital health startups I have seen have very little input (if at all) from practicing clinicians (or other experts in the field for whom they are presumably developing this innovative technology). As those of us in healthcare know and respect, healthcare is very complex, very personal, and the consequences of failure are very risky to merely manifest innovative or creative thinking in software. Healthcare is not the hail-a-taxi industry or the rent-your-spare-bedroom industry.

To distill these lessons into two succinct sound bites: (1) Clinical solutions must be developed with clinician input. (2) Developing solutions on paper first will lower cost, reduce frustrations, and accelerate growth.

Choosing an RPM Vendor

The building blocks of a Remote Physiological Monitoring System include the following.

Vital Sign Monitoring – biomedical devices that capture vital signs and other biometrics, such as weight, blood pressure, blood oxygen, glucose levels, temperature, heart rate, heart rhythm, etc.

Logistics – the technology and processes involved in deploying the RPM technology to the patient and setting it up, as well as the potential retrieval and refurbishing if the RPM kit is to be deployed to other patients.

Technical & Operational Support – the people, processes and technologies involved in assisting patients, clinicians, monitoring nurses and other users with the effective use of the RPM solution.

Clinical Monitoring and Management – the ongoing monitoring of patients’ vital sign, ensuring adherence (by reminding patients to perform their measurements), engagement (by using just in time education, e.g., about the imminent effects of a Chinese buffet visit on blood pressure and water retention) and escalation (when clinician intervention is needed).

In the RPM world any or all of these building blocks can be outsourced – from full-service RPM vendors, that take care of everything (and only involve a provider in the case of an escalation) to vendors that only provide the vital sign monitors, or a complete solution (monitoring, collection, transmission, review, analysis, etc.) without an of the “service” aspects, such as logistics, training, retrieval, or monitoring support.

Other vendors offer solutions to support the logistics (very helpful for large-scale clinical trials, readmission prevention or hospital-at-home programs) as well as a nursing staff to manage the ongoing monitoring of patients.

Thus a key question is: What vendors are you looking for and what solutions or services should they be providing to your RPM program.

But that is not the first question. Building on the lessons learned from above, the first question is: “What experience do you want patients, providers, monitoring nurses, and support staff to have?”

This goes back to first develop your solution ”on paper”, in the abstract — and to leverage the expertise of those who will be the users: the patients, the providers, the monitoring nurses, and the support staff.

Very often in healthcare, regardless of the problem to be solved (a new EHR, an image management software, a patient portal, a telehealth solution, an RPM platform, etc.,) most teams/people (including Health IT!) oftentimes start with selecting the vendor first.

That’s like buying the horse first. And then deciding what cart the horse should push. What works much better, is knowing what load you want to pull (a wagon? a carriage? a canon?) and then deciding on the best horse (or horses) to get the job done well.

But it seems to be easier to just go out into the marketplace, be wooed by a sound sales presentation, a great demo, and some convincing client testimonials, leading you to sign on the dotted line. And then to be left to figure out how to make the best use of the solution – which may include bells and whistles nobody needs. Or it may employ a care coordination paradigm that does not align with your organization’s culture.

In the end, many technology purchases end up a disaster when measured by how much they fall short of their potential.

But it does not have to be this way.

Workflow & Features First

Everything we do in healthcare is service related. With that, everything we do is a process where individuals are taking actions and passing tasks on to others.

A solid RPM program is a series of well-defined processes. Here is a sample various processes that comprise an RPM program:

1. Enroll the patient into the program.
2. Setup the RPM equipment in the patients home
3. Train the patients on the proper use.
4. Monitor patients.
5. Intervene due to noncompliance.
6. Intervene when values are out of limits
7. Escalate to a provider when needed.
8. Review historical data.
9. Provide education.
10. Graduate patient from the program.

To succeed with RPM, each program should FIRST (even before looking at vendors) sit down with the “experts” of each of the processes to DESIGN the best user experience possible: “What should it be like to enroll a patient? What would the review of the patient’s historical data look like?”

Courting, Dating, Marriage

Armed with your understanding of the ideal state, your ideal workflow experience, you can now look for vendors who come close to your desired set of features. Doing that prep work will also allow you to put additional innovative features that vendors’ sales people are touting (“We have AI built in!”) into the right context, to see if they add value to you or not. In most cases, uninformed buyers are bamboozled by the good-sounding, value-promising statements that may not be (or they may be) relevant to what you want to accomplish.

Once you’ve narrowed the field down to one final contestant, it’s time to get back to the (process) drawing board. Since it’s unlikely that the vendor will make all your dreams come true (and may actually have fabulous, useful features you hadn’t thought of) you need to revise your workflows so that they fit with what the vendor’s solution or service can actually provide.

Now, with the newly revised workflows (and hopefully the support of all the key users) you can now launch a small proof-of-concept. Of course many vendors may push toward a minimum number of devices etc., but the highly contested and competitive RPM solutions market gives you, the buyer, the upper hand to negotiate. Any larger or long-term commitment should be contingent on the successful outcome of your proof-of-concept trial of the vendor’s offering.

Do you want to discuss your RPM program? Or learn more about our 5-part webinar series “Optimizing Hypertension Management with Virtual Care”? Then connect with Christian!