How to overcome provider device fatigue and craft user-centric, interoperable MedTech? How to build game-changing, interoperable MedTech and digital healthcare with Star? How to build the process of MedTech product development with connectivity in mind?
In the past six years, the number of connected wearables has tripled to reach 1.1 billion worldwide. While consumers are most familiar with Apple Watches and Fitbits, blood glucose, blood pressure (cuffs and daily wearables), heart rate, sleep and oxygen saturation level monitors have been transformative. They’ve provided the ability to push data from devices to patient apps and physician EMRs giving HCPs a more holistic view of patient health.
As more devices rapidly emerge; regardless of their value-base in healthcare, there still remain significant challenges in providing digestible information that clinicians can incorporate into their workflow.
Many personal health tracking devices are not as accurate as professional monitoring tools in hospitals and physician offices. Therefore, many physicians still do not see the overall value based on time and effort to monitor this incoming data.
We’ve arrived at a critical inflection point. Both consumer and regulated wearable products have immense potential, but many medical device vendors may not be in sync with what HCPs want and need to see. To win physician buy-in and patient adherence, vendors should focus on these essential product considerations.
Explore the importance of interoperability
Learn more about the importance and opportunities interoperability creates in this article.
An explosion of healthcare data
The average wearable makes 250,000 measurements per day. The benefit is that HCPs can get a much richer sense of patient health between visits. However, it’s an enormous amount of data. Even summarized, a physician may have hundreds of data points for each patient to sift through.
Clinicians need solutions that can digest all this information and give them quick insights. In most cases, and unless a patient is having a hard time managing their conditions, physicians only want to see or (or be notified) when a patient falls outside target data ranges set by the physician and patient.
For example, a doctor may set a patient diagnosed with prediabetes (A1C level of 5.7% to 6.4% and blood sugar levels consistently between 7.0 mmol/l and 8.2 mmol/l) a target range between 6.0 mmol/l to 6.8 mmol/l. The doctor will want to be notified if a patient exceeds the range for a few days in a row so they can make an intervention or suggest an office visit. But they don’t need a daily notification that a person has stayed within the targeted range.
We need to think about information, how it’s presented and who receives it. These same updates are certainly useful for patients to understand how their lifestyle and medication decisions impact their lives and hopefully be encouraged to adhere to a treatment plan.
HCPs need synthesized insights. Moreover, they should be able to control the types of data they receive and adjust accordingly for the needs of each patient. In short, include the ability for physicians to drive the kind of data results they want to have imported into the EMR. Likewise, give providers flexibility and autonomy in setting both the types of data they receive and see and how they are notified about it.
Consumer device calibration and identification of clinical-driven data
This issue of data quality constantly surfaces with consumer healthcare products. For example, while a kilogram difference in weight isn’t a major issue for at-home scales, this type of fluctuation in areas like blood pressure or blood glucose levels could lead to serious chronic health issues going unnoticed. Or, paradoxically, it can also lead to false concerns receiving too much attention from over-taxed healthcare professionals.
Even though consumer medical devices may have to go through conformance testing before they can be approved as medical devices, it is important to note that this does not mean that every blood pressure cuff or heart rate tracker will provide the exact same results.
Imagine an at-home blood pressure cuff that consistently provided a slightly elevated reading. Should the at-home cuff provide a reading of 140/90 (signaling Hypertension stage 2), it would be an immense cause of false concern especially when the physician’s office cuff measured lower (135/85). One way to maneuver this is to calibrate consumer devices with an in-office reading. Combined with the right software, it will then be possible for HCPs to record the calibration difference and to only be notified when there is an actual cause for concern based on the calibrated result.
This leads to an even more important distinction. Clinicians need to see the difference between patient-driven and medical-grade data. Patient-driven data is meant to augment clinical data. It allows providers to see concerning trends between tests, especially as most clinical tests are run at less frequent intervals. Of course, both have their place in the EMR, but it should be easy to differentiate between them. At Star, we strongly believe that this difference should be presented via a graphical representation of data instead of columns to facilitate quick comprehension and analysis.
Busy as they are, clinicians have an interest in patient-driven data. So this is an opportunity for MedTech companies who develop SaMD solutions to include a calibration tool that allows physicians to enter a differential calibration result to better utilize the patient-driven data they receive.
Interoperability should be a priority from day one
If we consider that the purpose of patient-driven data integrated into a physician EMR is to augment the results taken from clinical devices in a hospital, physician’s office or lab, patient-driven data must be received using healthcare data interoperability standards like HL7 v2 or FHIR. All EMRs utilize these integration standards, so this will ensure that whoever is responsible for patient care can easily receive data. The result is that when a physician is looking at the patient’s clinical outcomes, both patient-driven data and clinical data can be displayed together.
This is absolutely critical for medical device development. A patient with a chronic condition’s Circle of Care team will likely include a family physician, specialist and an assigned nurse (sometimes referred to as a Chronic Disease Nurse or Patient Outcomes Nurse) who all need access to this remote patient monitoring data. Although it is still a physician’s responsibility to receive and review incoming laboratory, diagnostic imaging and consultation reports, some physicians do not want or have the time to see incoming patient-driven data. Nurses will thus manage this data and ongoing interactions between the physician’s office and the patient between visits.
And this is at the simplest level of integration. What about when you include additional care providers or hospital systems? Interoperability of health information systems and flexibility are essential and these considerations should be taken into the features roadmap.
For example, a physician can assign notifications of patient-driven data to only go to the assigned nurse, who will then review and determine which information should be imported into the patient’s EMR record or when the patient should come in for a visit. At the same time, physicians have mentioned that when it comes to patient-driven data, once they set the parameters of the data they wish to be notified about, they might want to set a critical notification that would come directly to them. This would include when a result hits a dangerous abnormal value.The needs of each patient are unique. So as MedTech product builders, we need to consider how to create a dashboard and solution that allows physicians to opt in or out of some of these features and set parameters accordingly.
Moving towards your MVP: features for now vs. later
We’ve covered some essential considerations for creating software as a medical device, MedTech and digital healthcare products that fit into provider workflows. At the MVP stage, you want a device to track health data and present it in an app or dashboard. We have noticed from our research that physicians generally prefer dashboards over apps. However, it’s important to understand the needs of your target users to determine the right fit.
From the beginning, it’s essential to have the system ready in medical device interoperability standards for data entry (SNOWMED, ICD10, LOINC, etc.). When all health data is codified using these international coding specifications, it will ensure that when health data is exchanged, it will be consistent and accurate therefore reducing the risk of medical errors.
The data pushed to a dashboard needs to be presented so that clinicians can quickly see data trends versus ready health data in report structure only (graphical views). Likewise, the data results must be presented and formatted, ensuring units of measurements are included in the display.
Data filters and notifications need to be present so clinicians can quickly see concerning data. Do not expect clinicians to remember to check portals on their own.
Similarly, physicians should be able to launch portals directly from EMRs, with an API that will automatically log them in and search important patient data. Time is always an issue. Physicians do not want to locate critical information online, log in, and search across patients even with an intuitive dashboard.
There must be enough relevant information that will be informative to the clinician. For instance, if a patient is tracking their blood pressure or glucose levels, and there are several days in a row where the results are outside of the normal ranges, allowing the patient to add notes greatly helps the physician.
For example, if a patient is on vacation and not adhering to their diet, it should be easy to distinguish between significant causes or trends of concern. Without the patient note explanation, if there were several days in a row where the data was outside of normal ranges, the physician would likely call the patient in for a visit to ask the nurse to call. This explanation provided by the patient may stop unnecessary interventions.
Some may question if these features are truly MVP or nice to have, but many physicians will not accept a solution as viable if it causes them more work to understand or utilize the patient-driven data. Use this as your guiding principle no matter what stage of product development you’re in.
Discover more about Star:
Star HealthTech Practice is passionate about improving people’s lives with digital products that are a pleasure to use. We’re delivering connected and interoperable products for HealthTech and MedTech submarkets that help improve people’s lives globally.
