Observations on a Telemedicine Shift: An Insider Perspective

Grant Kohler
Grant Kohler

Guest post by Grant Kohler, vice president, Innovation and co-founder, REACH Health.

I began my healthcare career in the hospital setting. While working at Georgia Regents University (formally the Medical College of Georgia), my colleagues and I developed one of the nation’s first telestroke systems. It was rudimentary at first, literally pieced together on an IV pole from existing equipment: web-enabled video cameras, flatbed scanners for CT scans and spare CPUs, with a landline telephone to provide audio. Since then, I’ve worked with many facilities across the country to set up telemedicine platforms. Over that time, I’ve witnessed a variety of approaches to telemedicine.

One major transformation I’ve witnessed more recently: Many hospital systems are now choosing software-based platforms over hardware-based technologies. As I’ll explain shortly, this shift in thinking has important implications worth considering.

Core Technology: Software vs. Hardware

Telemedicine platforms are evolving rapidly with no signs of slowing. It is prudent to ensure that your hospital is in a position to take advantage of the rapid pace of improvements without being locked into a solution that hinders or prevents future technological enhancements or program expansion.

To appreciate the difference between focusing on software vs. hardware, consider the evolution of mobile phones. In 2007, the first smartphone was introduced. At the time, flip phones were considered leading edge. Less than five years later, flip phones were deemed antiquated by most. Why? The cell phone is a hardware-centric device and the smartphone is a software-centric device.

In the telemedicine industry, first-generation solutions such as tele-presence carts and robots began as single-function, hardware-centric devices. Even if they work satisfactorily for their narrow purpose, they lack the flexibility needed to support cost-effective upgrades and expansion for multiple service lines. Also, because the hardware is proprietary, it often isn’t subject to commoditization and is priced at a premium. As telemedicine technologies have evolved, software-centric platforms have become available and offer increased flexibility, including new capabilities and multiple endpoint options.

Support for Creating a Telemedicine Network – Thinking about the Subscribers

The literal goal of telemedicine is to create networks where provider hospitals offer specialty care or expertise to subscribing hospitals. Successful execution produces improved outcomes and patient satisfaction for a larger number of patients and creates economic benefits for both the provider and subscriber hospitals.

Your telemedicine platform can impact your ability to recruit hospitals into your network. In competitive markets where other provider hospitals are vying for the same potential subscribers, a well-designed telemedicine platform provides a recruiting advantage. If a large hospital balks at expensive hardware investments that easily become dated, a smaller hospital will have similar concerns but a tinier budget. Hospitals of all sizes seek to leverage maximum utility out of all investments with a minimal disruption to existing processes and workflows. With hardware-centric platforms, the inherent focus is often on the technology itself rather than the patient. This is unpalatable for most hospitals considering telemedicine, as their primary objective is better patient care.

I use the terms “provider” and “subscriber” vs. the traditional “hub” and “spoke” terminology. This reflects the rapidly shifting dynamics in the industry. While the hub-and-spoke model is still viable for many hospitals, there are other models, such as a triage-based approach, that have proved themselves effective. And the traditional assumptions underlying the hub-and-spoke model don’t always apply. Some subscribing hospitals can provide at least partial coverage by specialists. Transfer relationships can change as subscribing hospitals develop new treatment options in-house. The point: hospitals wishing to implement or join telemedicine networks need to think beyond the hub-and-spoke paradigm.

Support for Multiple Service Lines – Growing Telemedicine

Every healthcare dollar spent is heavily scrutinized. Senior-level executives insist on cost effectiveness. Your platform should be capable of supporting a broad mix of uses (such as multiple service lines and care settings) without the need for excessive investments in additional equipment or components as your telemedicine program expands.

Even if your telemedicine plans ultimately include multiple service lines across multiple care settings, you should consider starting with one service line in one care setting. This low-risk approach will enable you to establish the foundation for your program and demonstrate early success. Then, at a pace that is appropriate for hospitals in your network, you can expand the scope of the program to include additional service lines and care settings. The right technology decisions will enable you to leverage this initial investment. Much like you might install new software applications on a home computer over time, you should be able to install new applications – each specific to a new service line – as you expand. Ideally, these applications should not require additional hardware investments.

As the scope of your telemedicine program expands, so does the range of patients your program can treat. Patients benefit from ongoing access to specialists with the convenience and comfort of staying close to home. Providers of telemedicine consults offer coverage to a greater number of patients, while subscribers are recognized for developing the capability to treat new types of disease. An example of this occurs when hospitals that subscribe to telestroke services become Comprehensive Stroke Centers.

Support for Clinical Documentation and Workflow

Robust telemedicine solutions are designed to enable real-time data entry, facilitate workflows and capture documentation specific to each type of consult.

A telemedicine solution should strive to recreate the bedside experience for each supported service line. That is to say: The technology should facilitate, as much as possible, the same examination the remote specialist would perform in person. The workflow should be based on best practices for each service line, allowing for both subjective and objective input and also configurable to meet the unique needs of each telemedicine program. The technology should be transparent to both the provider and the patient, reinforcing the virtual bedside experience.

Onsite clinicians should be able to capture relevant clinical data directly into the telemedicine system during the consult. Using a standard interface can also help to insulate physicians, program coordinators and others from disparities such as the use of differing EHR/EMR systems at the various hospitals in a network. Producing a comprehensive consult summary at the end of the encounter provides easy access to all clinical information, whether the patient is being admitted or transferred to the hub. Next-generation telemedicine systems take these capabilities one step further and allow for the aggregation and analysis of consult data to monitor performance and identify areas for improvement at the provider, hospital and network level.

A well-designed telemedicine platform can accommodate your specific needs and enable flexibility, growth and expansion as you identify future opportunities. Conversely, a poorly designed architecture can limit or completely impede your evolving objectives. As a result, it is wise to evaluate telemedicine systems with a close examination of both present and future needs for the hospitals in the network and the communities to be served. Once telemedicine is in place, it is important to revisit these needs and goals. While technology decisions are critical to sustaining a telemedicine network, continuing collaboration is equally important.


Write a Comment

Your email address will not be published. Required fields are marked *