11 Lessons We’ve Learned From Remote Patient Monitoring

We’ve been hearing for years that remote patient monitoring (RPM) can increase revenue and improve patient outcomes.

But how?

After working with large health systems, Harvard Medical, the US Department of Veterans Affairs and more, we at Overlap have found that there still isn’t a good place to learn how to bring patient generated data into the clinical workflow.

We want to share everything we know about remote monitoring so you can be successful today.

Our approach is non-traditional and goes way beyond technology.

But before we get into it, here’s how we recommend you use this guide:

1. Read through it once to get a general idea of the strategy
2. Re-read the “Why You Might Fail” section, and try to identify which errors you’re making.
3. Go back through and implement each piece one at a time or in parallel

Guiding Principles

RPM is an evolving field and it’s important to establish a framework for how to think through problems.

Principle 1: Failure is good. Mistakes are not.

Part of RPM is that you will fail. You will make assertions on what patients and providers will want. And you will be wrong.

The point though is that once you make an assertion and you’re wrong, try another and be wrong about that. Do this over and over until the thing you’re building keeps getting better and better.

We at Overlap have failed a lot doing RPM. So have our partners. So have others. And it’s okay.

Great, even.

This is going to be hard to hear. But we’re adding this to help you relieve some of the stress of bringing RPM to your organization.

Failure is a good thing. And this isn’t a case for failure porn.

Mistakes are bad. Mistakes are when you repeat the failure again and again.

The trick is to not be defined by the failure. Learn from what went right and wrong. Resolve the issue and build systems to prevent the issue from happening again.

We follow the rule at Overlap that a 1% improvement per week will result in ~70% improvement over the entire year. Yes that’s true.

You don’t need to get everything right from the beginning, but the goal of this guide to get you right faster.

Principle 2: Test early, test often

If you build and deploy a whole RPM system and expect it to work the moment you cut the ribbon, then you’re in for a big shock to both your ego and wallet.

It’s better, instead, to build and test an an agile manner, designing smaller units of the overall system which can be deployed as quickly as possible. It’s far easier to learn from mistakes on smaller components then trying to diagnose a large system.

To learn more about about agile methods start with the Agile Manifesto. Then read Rocket Surgery Made Easy by Steve Krug (no affiliate link).

Principle 3: Engage your users

The more you engage with your users, the better your product becomes. The good news is that you don’t need huge subject pools in each round of testing to get worthwhile results. In fact, Jakob Nielsen, a leader in user experience research, suggests that testing with as low as five participants is enough to glean meaningful insights.

With five subjects, you’ll find around 80% of the issues that exist.

Instead of spending even more time and energy on that last 20%, put your efforts into doing rapid testing with a smaller sample size, and iterate through problems along the way.

Don’t focus on perfection. Design a product that’s good enough and focuses on the actual needs of the people using it. You’ll only discover this through user-testing.

Now let’s get into the meat of making remote patient monitoring a reality.

You ready?

[Lesson #1] Define. Define. Define.

Before we get started, we are going to take a cue from design research and ask three critical questions:

1. Who’s it for?
2. What it’s for?
3. What change do you seek to make?

Who’s RPM for?

We have a saying at Overlap:

“Everyone is not your patient”

Remote monitoring is so versatile that you can customize it for any sort of design state or patient group.

A program for everyone — especially in the beginning — is really a program for no one.

Is your RPM for:

• Children? If so, do you need to make a separate app/view for parents? Do you have a way to get consent for children under the age of 13?
• Caregivers? Do they have consent from the patient?
• Seniors? Have you considered accessibility issues?
• Diabetics, hypertensives or anyone with chronic disease?
• Nurses?
• Doctors?
• Care managers?
• Health coaches?
• Spanish speakers?

Knowing who RPM is for will help you better understand user flow as well as which data matters most to which people. By focusing on who, you’re also building empathy for users.

Again — and we can’t stress this enough — making your RPM program available to everyone, will be useful to no one.

What is remote patient monitoring for?

A simple question, yes. But also very difficult.

Below are some use cases for remote monitoring which we encourage you to use in the design of your RPM program:

Population Health: Under the traditional model of healthcare, changes in a person’s condition are only tracked as an encounter inside the four-walls of the physician’s office. Being able to manage your patient population from outside the clinic can be a useful way to segment and close care gaps.

Clinical research: Paper questionnaires sent through the mail do not always make it back in and it’s not always easy to record events after the fact. With almost all potential participants owning a mobile phone, there is a great opportunity for them to interact in research from wherever they are, and provide new types of data you’ve never had before.

And if it can measured, it can be monitored.

Staying ahead of the curve: It’s important to keep up with the times. Even if the “innovation illusion” is all you’re after, that’s something that RPM can provide. You’ll find out that it’s got a lot more to offer than that. These things aren’t for all aspects of healthcare. For example, RPM may not be good for surgical procedures or emergency visits but it can be used to help with say post-operative surgery instructions.

Rebuilding trust with patients and their families: We are all in the trust-building business. Your job as a provider is to scale trust. Our job as a technology partner is to help you get there faster. RPM can be a tool to help improve your brand and engagement.

What change do you seek to make?

“If nothing changes, nothing changes.”

We are not doing remote monitoring to stand still. And you’re definitely not doing RPM because you embrace the status quo.

You’re reading this because you want to change how your organization delivers care.

You want to be more streamlined, make money and ultimately improve patient outcomes.

Implemented well, RPM can make the above things happen.

And yet, the important way to achieve them is by focusing on the small, measurable steps in-between.

For example, a change your program could want to make is to have 80% of your diabetic population at an HA1C of <8.

Or you want 90% of your hypertensives at an average blood pressure of 130/80.

The change you seek to make is up to you but it’s important to define. Being focused on the change will also help you justify further investments in your program.

That’s why defining the parameters of your unique RPM is a crucial first step.

Your organizational needs might be different and you might need to think deeply about the change you’re looking for. That’s okay.

But the key is to start.

Once you have the definitions in places, the rest of the steps below can be done in parallel.

[Lesson #2] Choose the right use case

Because you now know who and what RPM is for, it’s going to be very easy to come up with the right use case and workflow.

Why choose a use case?

A lot of you have been thinking about hooking up your EHR to Apple’s Healthkit or Google Fit.

But for what?

Whether it’s operational or technical, extra data without a use case will be, well, useless.

Most use cases focus on reducing time for data-to-action or reducing wasted time coming into the office.

Here are some examples of a use case:

Use Case Primary measurement making RPM effective Diabetes Blood glucose, HA1C Hypertension Blood Pressure, Heart rate Depression Mood Medication adherence % of medications taken on schedule

Recommendation: Choose at most two use cases to start so you can prove that RPM works for your organization.

[Lesson #3] Iron out the clinical workflow

We’ve heard it called a “glorified cash register,” a “billing machine” and even “their worst nightmare.”

Don’t believe us. ZDoggMD made a video about it:

Whether you like it or not, the clinical workflow is your Electronic Health Record (EHR).

A lot of the mixed results from remote patient monitoring stem from a poorly associated clinical workflow.

Some examples of reasons why your workflow might not be working out:

1. Requiring an order to initiate monitoring which leads to lots of co-signing
2. Constant complaints of “double entering” by nurses who are having to account for new devices
3. Technology issues, such as data not shared between episodes or heavy interface burden

Because you know who you’re doing RPM for, mapping out the workflow from ordering RPM to patient onboarding is key.

Thought exercise: Think outside the EHR? The EHR is good for billing, ordering labs, medicine and imaging. Ask yourself if you need RPM inside your EHR and figure out a way to extract data out using the FHIR interface so you can power RPM outside your EHR.

[Lesson #4] Decide whether to build or buy RPM technology

Now you’re ready to tap into the potential that RPM has to offer and want to use technology run your organization better. What do you look for in a vendor?

Without getting into the “theory of the firm,” every organization must be intentional if it’s going to build or buy technology.

Build

Building and owning your own RPM software could be a route you wish to take. Here are some pros and cons to building your own RPM software:

Pros

• It’s your IP
• It can be tailored to your precise needs
• You’ll be building product capacity within your organization which go hand-in-hand with healthcare delivery. Making products is a great way to future-proof your organization

Cons

• It’s expensive
• You’ll need to hire a team of product and UI/UX designers, product managers, back-end, front-end and mobile engineers. Not to mention, you’ll need to assemble a team for user testing and security.
• You’ll also need to build out your own HIPAA compliant cloud infrastructure (some options: Google Cloud, AWS, Aptible)
• You’re responsible for anything that goes wrong with the software. If you’re not equipped to handle this, you could be in for a world of hurt.
• You’re also responsible for all maintenance and support for the software

How to build your RPM software? Some options:

1. Hire an internal team to design, develop, deploy and maintain the software for your providers and patients
2. Contract a development shop that has deep experience with EHR integration and RPM — there aren’t many
3. Whether you choose (1) or (2), you’ll need to design and implement an internal system for testing, analysis and training

Building from scratch is not a bad choice but it’s not easy or an inexpensive undertaking and often hard to justify.

Buy

Do you own your EHR? Did you design it from scratch, assemble a team, hire product managers, designers and infrastructure people to make the technology that you use on a regular basis (see “Build” section above)?

For the vast majority of you, we’ll assume the answer is a resounding “no.”

You’re incredible at delivering healthcare to the population every single day.

Software design was not why you got into this.

For most, buying your RPM software will be your best option. Much of your discussion will come down to what type of software licensing to go after: Perpetual or Software as a Service (SaaS). This is longer discussion on the differences in software licensing which we’ll leave for another post, but here are some high-level points to consider.

Perpetual License

Buying software with a perpetual license means you pay an up-front fee and you use the software for as long as your system and the software are compatible. You’ll likely pay lots of money up front for the perpetual license and will need to pay for an annual service fee for maintenance.

Pros of buying a perpetual license

• You get to “own” the software and sometimes be able to adapt it to your needs — with professional services support
• Budget comes out of CAPEX
• You only pay once for the license — as long as the software works for you

Cons of perpetual licensing

• You might be capped at the number of users or storage/memory
• You’ll have to pay an army of consultants and contractors to customize the software
• New versions of the software won’t be available unless you buy a new perpetual license — think Epic and Cerner with their new EHR versions
• You may have to host your vendor’s RPM software on your own databases which will incur an additional cost to operations

SaaS

Some of you have heard of the Software as a Service (SaaS) economy. It’s a new way of distributing software so it’s more affordable for the buyer and scales with increasing use.

Overlap and many other vendors in this space are SaaS services. We all charge an annual license fee to use the software tied to usage metrics.

Pros for SaaS-based RPM companies

• Updates to bugs and features can be deployed quicker and everyone who uses the underlying software benefits from such updates
• No versioning issues
• Vendor hosts and manages the data collected and send it to you when you need it
• Its value scales with you. The more you use it, the more you pay (usually)
• Less overhead
• Almost every large company on the planet is heading in this direction
• Bugs and feature improvements are done on the fly by the vendor — it’s in the vendor’s interest to keep improving the product

Cons of SaaS RPM companies

• SaaS solutions are paid for out of OPEX budgets which will require your CFO or accountant to consider

Regardless of what kind of license you choose to buy, consider the following criteria in your search:

• Do they support lots of device types?
• Do they have a mobile app for patient engagement?
• Can they integrate into your EHR?
• Can they handle the disease domains you’re considering
• Are they device agnostic?
• What are their device logistics?
• Do they supply population analytics?
• Is there reporting for reimbursement?
• Can they support different languages for non-English speaking populations?
• How much technical support will you receive? And how much is the cost above the basic support fee? How fast will you receive it?
• Are you entitled to updates to your system and how often?
• Do you need to host on-prem or will the provider do it off-site?
• Can the system cope with new forms of data?
• Who owns the data and how secure and encrypted is the information?
• How long does your agreement last?
• Is the software compliant with all federal and state healthcare privacy regulations?
• If you’re patients and providers are in Europe, are there any considerations with GDPR that must be taken into account?

[Lesson #5] Choose the right device

One of the core elements of remote patient monitoring is the integration of wearables, medical devices and mobile apps.

We’ve written about this before. We know there are a lot of apps and devices out there and it’s sometimes hard to choose.

Here are some major criteria and a few questions to help you consider when selecting a device that’ll be part of your RPM program:

Privacy/Security

• Does the device maker sign business associate agreements (BAAs)?
• If the device maker hosts data, are they HIPAA compliant?

User management

• Does the patient need an email address and password?
• Is the device maker’s software available on the web as well as a mobile app?

The device itself

• Is it accurate?
• What’s the battery life?
• Is it waterproof?

Data

• Is the data clearly formatted?
• Is there a list of variables that’s being collected? Are they well-documented?
• How regular is data sent to the vendor cloud? At what frequency?
• Are there other mechanisms to collect data besides cloud-based?

Technical

• Is there an API available?
• Is an Application Development Kit (ADK) available?
• Do we have to pay to get access to API?

Support

• If there’s an issue with the device, is there a support center?
• Does the device maker have an established process for returns or damaged devices?

[Lesson #6] Be mindful of data privacy

A big consideration about RPM, perhaps the biggest, is WHO owns the data? Is it your practice? The individual provider? The patient? Or the manufacturer of one of the devices (ex. Fitbit)?

Most patients who use RPM devices believe that the data belongs to them. It’s their weight, their heart rate, and their logged miles.

Device makers ask users to agree to terms of service and privacy policies, but what those companies do with patient data is up to them. Knowing your position as to whether you want your patient’s data to be used by device maker is crucial. You may be okay with that, or you may not be.

You need to be clear about where you stand. If you are not okay with a device maker using your patient’s data, you may need to consult your legal team to sign a separate BAA with the device vendor.

[Lesson #7] Understand the nuances of onboarding

“User onboarding is the process of increasing the likelihood that new users become successful when adopting your product.” — useronboard.com

One reason why we love certain technologies is because they take the time making the experience easy and informative.

Onboarding is probably one of the most crucial steps in making your RPM program a success. Below are some dimensions of onboarding to consider.

Consent

In order for any patient to join your remote monitoring program, you need to get their consent. Although not all states require a provider to get permission from a patient to use telemedicine, it is nonetheless good practice.

Device Logistics

Many times in this digital health world, we forget that physical devices are being used to collect patient-generated data. Physical devices take up space. You’ll be surprised how fast 100 Fitbits can take up an entire office space.

Here are some ways to handle device logistics:

Store in your pharmacy

The benefit of devices being stored in your clinic’s pharmacy is that they’re already equipped to handle new inventory.

Be sure your EHR allows you to make an order to the pharmacy for devices. And you’re going to want to make sure that pharmacy technicians can help patients use the device (more in the training section).

“Genius Bar”

An alternative is to have a user-facing concession within your clinic that works much like Apple’s Genius Bar.

The example here is Ochsner’s O Bar. Patients are given a retail experience like Apple’s Genius bar to choose an RPM device. Their nice staff take the discomfort out of learning a new device or the overall hesitation in inputting your intimate health data into a iHealth Blood Pressure monitoring.

Patients also receive training on how to use their device as well as try the bar as a port of call for support. The O Bar is effective. In our view, the similarities to Apple’s Genius bar (and the use of iPads) takes the edge off the experience.

Mobile Device Management (MDM)

Don’t want to manage device provisioning yourself? You might want to consider an MDM solution.

Your EHR should have something built-in to make orders for certain medical device. Some vendors outside your practice will fulfill orders on your behalf.

Each device is locked-down and hard registered to your organization such that a rogue user of one kind or another could never successfully wipe it down and sell it on or use it after the end the device’s life.

MDM’s allow you to not deal with the day-to-day logistics of supporting devices.

Check with your IT department to see if they’re working with an existing MDM that can help support new wearable and medical devices for RPM.

Bring Your Own Device (BYOD)

A patient may already have their own device (think about how many Fitbits are in sock drawers across the world) and want to not have to worry about carrying or buying multiple devices.

While BYOD is an important concept in the business world, we don’t recommend this for RPM.

First of all, you don’t know how accurate the patient’s device is, whether they’re using it properly or if the device is going out of business (ex. Jawbone, Moves).

Some good software vendors may account for BYOD requests but, on the whole, it’s best to keep things consistent.

We recommend that to support BYOD your organization needs to have a whitelist of devices that it supports. We wouldn’t focus on the fringe devices that don’t have lots of traction or shaky APIs (see above in Lesson 5 on choosing the right device).

Who’s paying for the devices?

There are real economics with wearable devices, with some of the better ones starting at $100 on up. Who’s going to pay for it? Is it you, the provider? Is it the patient? Are you subsidizing the device? Is it the insurance company?

We’ve found that when you give patients the device for free compliance to the RPM goes up.

Your program will be so effective that spending a hundred dollars on a wearable will seem negligible in the future.

You’ll need to account for returns and defective devices, but that’s something you can figure out with your finance department (and your MDM vendor if you’re using one).

[Lesson #8] Match your great rpm program with strong training

“An ounce of prevention is worth a pound of cure.”

You’ve convinced your staff that remote patient monitoring is going to change the clinical workflow for the best.

You’ve also convinced patients that sending data to their providers is good for continuity of care.

Training your staff and patients will make the difference between a mediocre and great RPM program.

With training you’ll help set standards and make more money.

For patients:

Having a “genius bar” inside your facility could be a place to train patients on how to download 3rd party devices on to their phone and connect it to their personal health record.

Check out this video of the Oschner O-Bar staff teaching patients how to sync their iHealth Blood Pressure cuff:

If you don’t have budget for a “Genius Bar,” invest in good videos tutorials and paper documentation. Be sure to include these instructions when giving the device and use imagery of representative users (see Lesson #7 above ).

It’s a good idea that whatever devices you choose, that you photocopy the instruction manuals. It’ll make a world of difference when you need to get into technical support with the device and you can use these instructions to power your own instructions to patients.

For providers

The data that you’ll be collecting is generally high volume and arrives between typical encounters and more often than not, has never been used before.

For example, while many nurses are trained in school to read blood glucose changes over time, they tend to use HA1C as the way to manage diabetes, a metric that is measured infrequently and doesn’t change very quickly.

Doctors will want to use the high volume data but they don’t want to deal with doing more work. They need to be able to get an answer very quickly from the data without trying to synthesize and analyze reams of contextless data.

Be sure to train not only on how to use the system (whether in or outside your EHR) but also what the data means.

Provide webinars for providers to learn how to use the system and offer short clips with how-to videos.

[Lesson #9] Make accessibility your tech support’s focus

New technology is a wonder, of course, until it goes wrong. And you can’t rely on your staff and patients to be IT experts.

The key is to make technical support as easy to access and simple to perform as possible. The minute it becomes a hassle is the same moment that your patient stops sending data and clinicians stop “prescribing” RPM.

“My Fitbit isn’t connecting’ and “I’ve lost my password” are the most common kinds of inquiries we have heard. Many of these simpler requests can be covered by how-to guides delivered on device set-up (as described in Lesson 7 on Device Logistics) or in-app by your software vendor.

Should these not do the trick, then it’s time for your main technical support arm which should be outsourced to an entirely different company.

Having multiple lines of support is crucial. Having an outsourced IT support vendor to be your first line of support will help with common issues like “My device isn’t syncing”. Use your RPM vendor as second line of support to handle technical issues if something breaks.

Multiple lines of support can also help you de-identify users from the software vendor.

Just in the same way that your hospital is better at healthcare than it is software development, there are technical support specialist that are more equipped to deal with IT issues. Just make sure that you sign BAAs and/or covered under any local privacy laws to insure every measure possible to protect the identity of your patients.

[Lesson #10] Prepare the health workforce

As noted in the graphic above, through RPM your operations will become more efficient.

But to do RPM, you need people to operate it. We’re not at a point in these exciting times that we’re going to replace proviers with AI and machine learning.

If someone tries to tell you this is true, that’s a huge red flag and be wary.

The reality is that people are going to power your RPM program.

Here are considerations that most every provider hits as they work to integrate remote patient monitoring devices as part of their clinical workflow.

Unions

It’s a good idea to clear the idea of using any type of remote patient monitoring with all of your staff members, especially unions. If they aren’t on board, that can easily prove to be tricky.

That’s what happened when the Sacramento City Unified School district nurses’ union protested a telehealth service called HippoMD that served 3,000 students in five elementary schools, although it had success in improving the health outcomes.

The union was protesting because no one consulted with them before partnering with the telehealth company, and they believed it could be “wasteful when someone other than a nurse serves a telepresenter,” the letter stated.

Scopes of practice and licensing

Abide by things you already know like the medical practice act, and your diagnosing and prescribing authority agreements.

You may be able to skill-up a lower cadre of worker (like a medical assistant) to handle most RPM issues with patients. But again, you’ll need to figure out how to have them perform to the top of their license.

[Lesson #11] Make the economics work for you

Here’s a big question for you: Who’s going to pay for it?

When RPM was getting started, some organizations took the red pill and launched projects to demonstrate that this new world we want to live in is indeed possible. They did this without really considering who’s going to pay for it.

Fast forward to today.

We’re in a very unique time in our industry. Especially in the United States.

In 2015, a bipartisan law called MACRA (Medicare Access and CHIP Reauthorization Act) was signed into effect to both change how physicians are paid under Medicare and impose stricter reporting on improving quality of care.

The goal was to shift healthcare services from a position of volume (payment on the frequency of patient encounters) to value.

The Center for Medicare and Medicaid Services (CMS) broke the payment program into two components: MIPS and APM. CMS continues to test new payment mechanisms to satisfy the triple aim of improving quality, reducing cost, and improve the patient experience.

There are a number of rewards (and serious penalties) for providers to track specific outcomes under MIPS. And the great thing is, remote patient monitoring can help satisfy many of those outcome measurements.

While providers are getting their reporting for MACRA, CMS created a number of billing codes, namely CPT codes under Chronic Care Management to help providers make money ASAP with the growing number of chronic care patients under Medicare.

CMS also issued a revision to a telemedicine code to allow for remote patient monitoring.

In fact, CMS just proposed new RPM billing codes for the FY 2019 Physician Fee Schedule. From their perspective, this train is leaving the depot and you can tap into this new revenue stream today.

How much could you make?

If you had a patient population with 100,000 unique patients and 15% of them as Medicare patients, you’d have about 10,000 who have 2+ chronic conditions (one of the criteria for CCM).

If you use the CPT 99091, the average monthly payment is $60 per patient per month, then your clinic could generate an extra $7.4 million in new revenue.

This does not include the other billing codes available to practices or other quality payments. As well as MACRA/QPP reporting bonuses.

The point is that RPM is good for patients and good for your bottom line.

Why you might fail at Remote Patient Monitoring

This strategy we’ve outlined above will work for any organization, but you might struggle to making RPM a reality. There’s three reasons why your RPM efforts may not be work out.

Reason #1: You don’t have the right workforce to support the changes in workflow

This is a big problem we see now and again. Not having the right staff to perform the work is a real challenge, but think about what a small investment today could generate for your future.

If you’re in a risk-based program where you can’t enjoy CCM billing, then looking to skill-up a workforce of health coaches and medical assistants could help you go the extra mile.

Yes, RPM is people powered but if you’ve gotten this far into wanting to make change, you need to also change the people performing the job. RPM will pay for itself.

Reason #2: You don’t have the business case

Trying to do RPM from an “innovation” standpoint is not going to make it successful. You need to not think about this as a pilot or a research project. You need to think about proving this out in a business case so your organization can invest more time and resources into the program so they can see a fast return on investment.

Stay focused with the use case and make hypotheses on what impact RPM can make on your bottom line and/or operational efficiency.

Reason #3: You give up too quickly

RPM is not an MRI machine or a thermometer. It’s not something you buy once and sorta-kinda forget about it. This is a living, breathing program that requires commitment and gets better with continuous improvement and iteration

Conclusion

There you have it, a guide to remote patient monitoring. Offering RPM is not only a win for your bottom line, it’s also a big win for patients.

If you’re considering remote patient monitoring for your practice, and want us to help, fill out this form and we’ll provide an assessment of where you stand and how to get started.

Thank you again for reading.

Originally published at www.overlaphealth.com on October 15, 2018.