This post looks at some lessons learned from remote monitoring projects in Europe. This and subsequent posts are based on my last eight years of supporting these projects combined with some thoughts from my implementation experience of technology systems in many different scenarios over the last thirty years. I hope that some of it will be of value to the readers wherever they are in the healthcare industry delivery chain.
This post looks at some lessons learned from remote monitoring projects in Europe. This and subsequent posts are based on my last eight years of supporting these projects combined with some thoughts from my implementation experience of technology systems in many different scenarios over the last thirty years. I hope that some of it will be of value to the readers wherever they are in the healthcare industry delivery chain.
Overview
I’m finishing up support of two long-term projects based in Europe that are focused on using remote monitoring technologies and integrated platforms to support chronic disease management. One of the projects, United4Health, is a follow-on to the Renewing Health project. Renewing Health’s goal was to determine if remote monitoring systems used in clinical workflows in the support of chronic disease management were more or less cost effective and clinically efficient than traditional clinical workflows. United4Health’s goal was to demonstrate the use of remote monitoring systems in the management of chronic diseases at scale, i.e., implementation of a remote monitoring system as part of the standard of care.
A typical clinical workflow (after the initial diagnosis has been made) involved a patient seeing a clinician at their office or clinic at some pre-determined interval, every 6 months, for example. During these encounters some physiological parameters were measured, some questions answered, and then if needed a therapy adjustment given to the patient. If there was some type of emergent situation that occurred in between those office visits, either the patient visited the emergency room or scheduled an appointment to see the clinician. This type of traditional workflow is typically a reactive system versus proactive system: intervention occurs either when the patient sees the clinician at their regularly scheduled interval or when the patient condition has worsened to something that is considered outside of the normal physiological range.
More Read
This is costly both to the patient and the healthcare system because you are intervening periodically to bring the patient’s condition back into a normal range. With the exception of acute patient initiated interventions, intermittent followup visits were found to result in possibly large corrections versus continuously monitoring the patient and applying small corrections. These costs include the following: for the patient, physiological deterioration at a faster pace and what that means to their quality of life and their family around them; and for the healthcare system, higher utilization of higher cost and higher technology workflows for exacerbated situations. I’ve seen different statistics over the years citing between 70-80% of healthcare service costs being due to 20% of the population who has chronic conditions. Reducing that portion of the population using that large of a proportion of healthcare resources while either maintaining or increasing those patients’ health and physiological condition would possibly free up the resources for other needs.
The premise of remote monitoring systems is that if you can ‘quasi-continuously’ monitor these patients who have chronic conditions, then their quality of life would not deteriorate so quickly, possibly get better and their usage of the healthcare system would decrease resulting in decreased healthcare costs. The idea for this continuous monitoring is not new – doctors have been advocating that we monitor ourselves and moderate our behavior for many years. For example, if you want to lose weight, you are supposed to weigh yourself at some regular time interval (every day or every week) while also monitoring or controlling your food intake and exercise. It is a well-known adage that what gets measured gets managed or improved.
The ability to ‘quasi-continuously’ monitor patients has become cheaper and more prevalent due to the near ubiquitous penetration of the telecommunication infrastructure and mobile phones around the world, and the miniaturization of sensor technology. It has been hoped over the last few years that the ability to shorten the time intervals of monitoring key parameters for these patients using ‘the internet’ would allow for finer control of their condition. It is also hoped to help nudge these patients towards more self-management of their condition. A prime example of this is where patients with diabetes self-monitor their glucose and self-administer insulin when they need to maintain their glucose balance. This type of monitoring can extend to other chronic conditions which use other physiological parameters to determine the patients’ condition.
In the case of a remote monitoring system, you need to work with clinicians regarding an effective workflow which can monitor, detect and suggest intervention mechanisms for a particular chronic condition. For example, if a patient has chronic heart failure (CHF), a well-known parameter to measure is their weight. It has been shown that if a patient gains more than 3 to 5 pounds in three days, there is a high possibility their condition is deteriorating. This is usually due to fluid building up in their body which puts extra stress on their heart (the clinical term is decompensation). Quick intervention is key as the patient could end up in the emergency room or hospital needing expensive care. Having the patient weigh themselves every day at the same time and graphing that to see the trend with upper and lower limit range lines would allow intervention to occur earlier for that patient. The patient gains better awareness of their situation and it directs clinical resources where they are needed versus generally across all of the patient population of interest. A simple diagram showing this workflow, the different interfaces, and players is shown below.
United4Health CHF Telemonitoring System Architecture
When looking at the remote monitoring system architecture diagram above, it can be divided up into several functional boxes which drive specific capability requirements at the input and output of each box. The furthest downstream box is at the patient home (shown on the left side of the diagram) and the furthest upstream box is at the healthcare enterprise (depicted as the different clinical specialties on the right side of the diagram). In the middle is an aggregation and analysis functionality which acts as a control point for this system. This is also where ‘value-add’ services can be used to either automate or further aggregate information from other services for analysis and intervention upstream or downstream in the system.
The clinical workflow and system architecture, components and specifications are driven by the requirements of specific chronic conditions. In the case of diabetes for both the Renewing Health and United4Health projects, the requirement was fairly simple and the time sensitivity for a response wasn’t as critical as that for chronic obstructive pulmonary disease (COPD). In the early stages of the clinical workflow for COPD in the United4Health project, daily video teleconferences were required between the clinician and the patient. This drove a larger telecommunications bandwidth requirement at the patient home. Moreover in each clinical workflow, there was a requirement that the patient answer a series of questions regarding their condition besides reporting or having a medical device report a physiological parameter measurement. These questions usually served to further augment and add context to the parameter measurement of interest.
The choice of the physiological parameter was also key and had limitations. In the case of CHF, weight measurements were important, but clinicians also wanted heart rate, 1-2 lead EKG and blood pressure measurements reported. For diabetes, the main parameters measured were glucose and weight. For COPD in the United4Health project , they used pulse oximetry and a standardized questionnaire as well as daily video teleconferencing during the early stages on the protocol. The use of pulse oximetry for COPD in the United4Health project was driven by limitations to the use of home spirometry and experience from the predecessor Renewing Health project. In the next post, I will go into detail about the COPD case as it was the most challenging chronic condition to manage based on what type of remote sensor was available that could provide a clinically relevant measurement, i.e., an actionable data point for the clinician to decide upon intervention remotely.
United4Health and Some Key Findings
During the United4Health project, I visited eight different European regions in seven different countries participating in the project and observed their remote monitoring systems and clinical workflows. This resulted in several reports comparing and contrasting their systems. These can be downloaded at this link (see deliverables D5.1, D5.2, D5.4, D5.6 Annex 1 and soon to be published D5.8).
Each of these regions differed greatly with regard to their healthcare delivery system and situation. To be part of the project, they all had to agree upon a common workflow and system architecture and gaining this agreement took almost two years. The common denominator between these disparate sites became the workflow and system architecture which allowed for some scientific rigor to the clinical and economic research part of the project. Remember the main purpose of the project was to demonstrate at scale the implementation or deployment of remote monitoring systems in support of chronic condition management. The United4Health phase shifted the focus to how and what are the determining factors for a successful implementation of a remote monitoring system and integrating it into the standard of care applied across the broad patient population.
Every single region also had different telecommunications infrastructure at the patient home and at the healthcare enterprise, electronic health record availability, as well as assignment of different duties with regard to patient care at different points within the workflow. There were also vast differences in the market availability of telehealth systems, acquisition practices for those systems and/or reimbursement mechanisms for the clinicians using these systems. Moreover, the regulatory environment was different as well. For more discussion on the regulatory issues, I recommend a review of the deliverables D5.5 and D5.6.
In general, most regions had issues with implementing the systems due to acquisition limitations and market availability in their area for telehealth systems. My role in the project was to encourage the use of health data and messaging standards in their acquisition specifications early in the project. However, many regions already had some rudimentary telehealth system that they had used in previous projects and would merely be upgrading that system or if they did do an acquisition, many of the vendors told them that specifying the standards would drive up the price of the system. This was an interesting predicament and became relevant near the end of the project.
Telecommunications capability at the patient home both limited and determined the fidelity and depth of the remote monitoring or telehealth service.
All regions struggled with the quality of the telecommunications capability at the patient home or in the patient neighborhood, if they used mobile phones to send the requested data. This limitation constrained the type of data (mainly the timeliness and size of any data package transmission) that could be collected from the patient. In many cases, feature phones were predominant network hubs, which meant simple text-messaging using standard phone number keypads were the patient interface mechanism.
Interfacing the remote monitoring systems downstream at regions with more established EHR systems highlighted issues with community versus hospital based services both in seamless handoffs between services and scaling of those services.
The regions that had well established electronic health record (EHR) systems tended to understand what was needed to field a telehealth system, however, their challenges dealt with integrating the system and its data into their existing EHR offerings. The regions that had no EHR system were usually implementing the infrastructure from the ground up.
In Galicia, Spain, they contracted part of the remote monitoring service where the patient home and network transmission were managed by the service vendor, who would install the home ‘kit’, the necessary bandwidth and educate the patient with regard to how to use the system. Additionally, the vendor provided an aggregation and analysis application for the clinician to use when interacting with the patients and their data. Since this region was using the system to support their patients with COPD, they had a centrally located COPD nurse (her workstation was located in the regional emergency services dispatch office) who set up daily ‘tele-consultation’ appointments with the patients based on where they were in the protocol scenario. Interestingly, this region had a fairly robust EHR system, however, they did not allow automatic data interfacing between the vendor provided telehealth system and the EHR system. The COPD nurse would review the values collected by the telehealth system as well as the information gathered during the tele-consultation and then she would enter that information into the EHR separately. They deemed this clinical validation step important in maintaining data veracity in the systems they controlled.
Galicia also looked at how they would integrate the teleheatlh service into their existing healthcare system workflows. They realized that their specialty clinicians had to separately call admissions and discharge to initiate the remote monitoring protocol versus having it available as a one of several discharge instructions in their EHR ‘checklist.’ As part of a follow-on effort, they recognized this and have added remote monitoring as one of the choices the clinician has for discharge instructions/therapy for a COPD patient and additionally, by making that choice electronically, it will send an automatic message to the telehealth system vendor to alert them to set up the system in the patient home and educate them as well as add the patient information to their aggregation and analysis application used by the COPD telehealth nurse.
In the future this region will be distributing the aggregation and analysis software to the general practitioner offices for use by their nurses in support of the COPD patients (versus having one centralized nurse manage the patients). They anticipate this service being scaled further across their region, so they believe the capability also needs to scale cross the region and be administered similarly to other services by the general practitioners. The system they’ve procured can also support other chronic condition management protocols, so they’ve decided that diffusion of the technology outside of the EU project parameters is beneficial.
The region described above is not an outlier. In another region, NHS24 in Scotland, although their implementation took longer, once they implemented the system it was immediately scaled to all of the patients in the region. In their case, they had already established a portal system for patients to manage their diabetes, so for their implementation, they relied upon a vendor using their telehealth system to interface with the portal to Scotland’s NHS24 My Diabetes My Way portal.
NHS24 required a strict adherence by the vendor to their interface specifications, and by doing this, they were able to ensure a fairly clean integration and immediate scaling. This was not as easily accomplished for NHS24 in their CHF and COPD management services as these services did not have a standardized back-end for a telehealth vendor to interface and the services are clinically managed within local regions of Scotland with their general practitioner offices (which are separate privately run businesses who contract with the NHS24 to provide services for a number of patients in their area at a capitated cost per the patient population in their area). In this case, the different regions procured different solutions which were not integrated into an overall region-wide EHR system.
Several of the regions relied upon or assumed patient-owned “BYOD” medical devices would be the sensors used for remote monitoring
In four of the regions participating in the United4Health project, there was an expectation that patients would have their own medical devices or simple remote sensors and/or cellular phones to either allow them to enter the vales they measured into a web portal or connect via short range networks to a hub for transmission to the telehealth central server. This “BYOD” policy was intended to drive down acquisition costs as well a logistics (service, training, upgrades, etc.) for the healthcare provider. In some of the regions, the equipment was issued to the patients and was constrained or locked down to only run the clinical application. At the end of the project, the issued equipment was retrieved from the patient. Another issue highlighted was that in order to gain the ‘trust’ of the clinicians, use of validated or verified equipment was desired and there were ideas to include specific sensors, phone and applications on a type of ‘formulary’ for clinicians and patients to use when prescribing or purchasing these items. Another way to manage the ‘remote’ portion of the system was to outsource the service, as seen above.
Having dedicated clinical staff to manage the system was of paramount importance for garnering clinical trust in the system as well as success outside of any technical issues.
As I traveled to each of the regions and spoke with the people involved in implementing these systems, I found that each region needed to devote staff (usually nurses and in one region clinical engineers!) to manage these systems. These dedicated personnel worked to train the patients, manage the technical system, help to establish and then maintain the protocol and any follow-on actions, and work with the various clinicians who provided care for these patients. Their skill levels needed to be quite diverse and they needed to be ‘evangelistic’ in some cases with regard to the provision of the remote monitoring service. The difficulty usually came when trying to scale this service to be the standard mechanism within the healthcare enterprise. Many regions experienced resistance from clinicians along all spectrums in the care continuum as many times this service introduced fairly large changes. Nevertheless, as the project neared an end, almost every single one of the regions had plans to extend the remote monitoring service to other chronic conditions and had found ways to integrate it into their standard of care.
Summary
The United4Health project demonstrated that while technical issues can be barriers in the beginning, it is the cultural issues and resistance to change are the most difficult aspects to overcome. Success with these remote monitoring pilots is highlighted by the fact that most of the regions in the United4Health project will be continuing to deliver the remote monitoring service after the end of the project. This means they’ve found internal sources of funding for the service because they see a value in providing this type of service as part of their overall basket of ‘products.’ Contrary to the desires of some in the industry, remote monitoring and telehealth haven’t ushered in a revolutionary change in the delivery of healthcare, but rather a more evolutionary change.
In the next post, I will go into more detail about one of the chronic conditions treated in the United4Health project, COPD. This will entail a conversation I had with a pulmonologist at the beginning of the project regarding the limitations of remote sensor technologies.
