We’ve summarized key points from our panel discussion. For more, watch the YouTube video recording: https://www.youtube.com/watch?v=I8m1nh2E958


Mark Friedberg, SVP, Performance Measurement & Improvement, Blue Cross Blue Shield

Lucienne Ide, Founder & CEO, Rimidi and Co-Chair, HEAL Coalition

Leon A. Boston, CEO, MobileODT

Moderated by: Thomas Busby, VP, Healthcare & Life Science Investment Banking, Outcome Capital

How is healthcare adopting Remote Patient Monitoring (RPM) and Remote Therapeutic Patient Monitoring?

COVID has opened the floodgates and allowed the ecosystem to evolve rapidly. A lot of the recent acceleration has to do with the reimbursement of services. We have had the technology for years but reimbursement rates, policies and regulations were not following suit. Therefore, organizations were nervous about tackling the issue and not willing to invest time and resources to do this.

CMS released CPT codes late last year for RPM and more recently, they released CPT codes for Remote Therapeutic Patient Monitoring. There is some overlap in these codes. We’re just beginning the discussion and the good news is that CMS is aligned, although there is still a lot of vagueness in the regulations.

While CMS is restructuring how you get paid for these types of digital services, the FDA and other bodies are reviewing better ways to approve them, notify about new products, and how to build products from the ground up in a substantially more cost effective way. This is generating a lot of interest in the market and prospective customers.

Has RPM been adopted by the clinical community?

There is openness to it in the clinical community because there is a reduced burden to clinicians in terms of physical face-to-face contact. There are also more touchpoints with patients and a shift from an interventional one-time visit per year to multiple touchpoints with patients. RPM will help in many ways with regular monitoring. Consumers are attached to their phones, so we’re there in terms of data collection. But it’s also a matter of validating data. And this is coming at a rapid pace.

For technologists getting into digital health, why is regulated software so capital intensive?

There are significant costs due to quality overhead, beyond the regulatory overhead. It’s necessary to create quality management systems to manage all processes and software. That’s very expensive. Developers may say that 50% or 80% of development costs happen because they are doing regulated software versus unregulated.

The core issue is that there are not enough development tools dedicated to solving quality overhead and how quality software can be repeatedly created that exceeds patient expectations. In software there should be a tool ecosystem to reduce costs in an applicable manner. There are many ways to streamline and reduce the overall cost structure.

For entrepreneurs in digital health, are there certain areas for cost savings that would be advantageous and other areas where you don’t want to cut costs?

Good software development requires you to think iteratively and if it’s highly regulated software, build up to your end product. You learn as you go and may not know what your end product will look like. Have long-term goals, but also short-term steps and make them non-regulated when you can, so you can move forward and build.

From a clinical perspective it’s also an iterative process. Medicine, much like software development and the regulatory world needs to evolve with whatever problem is in front of you. You are putting together pieces of information. It’s important to involve the providers and clinicians so that the people who are going to be using the technology are involved early in the process so that you don’t run into user experience issues.

Healthcare more than any industry needs to start by focusing on the patient and user and ask if the product creates value for the patient or clinician at the point of care. Just focusing helps reduce cost.

Start thinking of quality systems from day 1, not after commercialization. There is a way to develop best practices, not thinking of quality as a side topic. Management should set expectations of regulated enterprises correctly. Many companies hire from the gaming industry and the mentality is to move as fast as possible. They don’t fit into more structured regulated environment. Make sure the team is on the same page, including the business unit and managers and that everyone is contributing equally with shared goals and responsibilities.

Digital health has new certifications and requirements coming out. Are these certifications creating better medical products?

There are unquestionable benefits to working toward compliance. That doesn’t mean you’re developing good or secure software. Regulations can be a bit misleading – they’re not sufficient to mean that your software is secure or good. Make sure you have an interdisciplinary team and shared responsibilities, not one group telling another what to do.

Healthy software must be continuously maintained and worked on and it’s not a done physical product. There is a lot of movement happening to catch up in this area that is positive.

The genesis of digital health was to provide better outcomes, focusing on the patient. Sometimes that can get lost. Medical devices or biopharma have great outcome data. With digital, we don’t always have that type of data set.

How have you seen RPM improve patient outcomes and the ability for providers to provide better care?

It’s a mixed bag. The reluctance with clinicians can be: Can I truly rely on this data? The evolution of these apps, as wonderful as they are, don’t always put the patient at the center. The regulations are fairly old and we’re building on an old foundation. And patients have their own information which can muddy things. Democratizing of information is wonderful for public health and clinicians, but it does come with complications. We need to expand our thinking: What does an outcome look like and why is this important? This is where big data and studies comes in. The regulations will guide us, as will iterative processes.

It’s fantastic that we can empower patients with data. But patients can also be misinformed. What does this data really mean?

If you involve clinicians and patients early on, you can catch some of this stuff and manage challenges related to the data patients may have. Do a lot of user testing and focus groups to anticipate concerns. It becomes a more nuanced responsibility. Take a patient-focused approach from the beginning before you rollout in large numbers. You can caveat language, but you need more than this and can actively provide information to interpret data rather than boilerplate information that most people ignore.

Are there specific areas within medicine for investors and entrepreneurs to invest in versus areas to stay away from?

There are two different sets of regulations. The first is HIPAA compliance and today in digital health that is table stakes – you must be HIPAAA compliant. The second tier regulations are for software as a medical device, which require custom documentation, standards and validation procedures around what the product does.

There is more migration toward the backside – software that makes decisions about patients for better patient outcomes and reducing clinician load. This can be done by taking away tasks when the decision is obvious. On the other hand, when you get into non-human diagnosis it can get challenging not just in regulatory, but also the optics of leaving human out of the loop.

The fear pre COVID was that digital health and technology would replace providers. We need human beings for human care. These are tools that help you make better decisions, not to replace the human component. We are at an inflection point to use digital technology to enhance what providers provide.

Regulated software post market studies are about surveillance to receive input and then launch aggressive interventive action. When planning for the commercial phase and approval of the product, we need to think more deeply on how to perform change control from the investigation in a cost effective way and not overburden the organization.

How do you turn a traditional software developer into a regulated developer?

It’s about setting the right expectations with the workforce about how work is done in the organization by ingraining processes, procedures and documentation into the development process. Remove overhead to minimize frustration for regulated developers. Give them ways to do it with low friction and that continues to explain why the extra work is important to improve patient safety. Make sure the team understands the importance of why we do this and that everyone values it vs just tolerating it.

Through a clinical lens – hire for attitude, the right mindset and diversity of skills. Hire outside of industry as lots of industries have overlap in processes you’re trying to accomplish.

Some companies have a walled garden versus other companies that want interoperability with others in the market. What technologies and pathways will be most advantageous?

It depends on the application. If you’re able, interoperate with software and benefit humanity better by reaching more people and have others help build your product.

I’m a proponent of open standards. Other participants may help you build and apply your products. Even companies with hardware that’s not interoperable by nature, they are trying to make it interoperable.

How do we see patient apps changing clinical trials?

We don’t even know what data we’re going to be tracking yet. A lot of trials and study designs are going to change as we have more apps and RPM as the health system evolves around them.

Regulations that are coming out this year for software will change that as well. What happened in 2020 was a remote foundational shift. 2021 with respect to guidance will be a foundational shift. Post market clinical trials and RWE gathering is more important. It goes back to iterative processes. It’s an exciting time, and we can amass a wealth of data, but if not careful, we may have a lot of data that not interpretable.

When patient provides healthcare data to provider via an app, who owns the data?

It’s a hotly debated topic and depends on the end-used agreement. You can own part of it, not all of it. It depends on how it’s sliced and cut. Eventually we’d like to see a clearer answer. HIPAA needs to evolve with what our technologies are offering now and it hasn’t happened yet.

Sponsored by