Medical device interoperability: essential development considerations to achieve 'meaningful use' for clinicians

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 an array of digital healthcare devices have proliferated across the market. These healthcare interoperability tools provide the ability to push data from devices to patient apps and physician EMRs giving HCPs a more holistic view of patient health.  

Nonetheless, many personal health tracking devices are not as accurate as professional monitoring tools in hospitals and physician offices. As a result, many physicians still do not see the overall value based on time and effort to monitor this incoming healthcare 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, HealthTech vendors should focus on these essential MedTech product considerations. 

An explosion of healthcare data

The average wearable makes 250,000 measurements per day. Magnify that by millions and you begin to understand the scale of big data in healthcare. As more devices emerge, regardless of their value base, there remain significant challenges in providing digestible patient health information that clinicians can incorporate into their workflow.  

Clinicians need data analytics and management solutions that can digest all this information and give them quick insights into patient health. 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. 

However, 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, physicians should be able 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 medical device data standards 

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. As a result, they often do not have the rigor compared to those that have undergone full regulatory scrutiny to meet medical device standards and regulations.

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. 

This is at the simplest level of integration. What about when you include additional care providers? 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. 

How to achieve interoperability in medical devices

We can divide medical device development into three stages: 

1. For MVP release, the solution should be capable of accurate data output while being readable for patients 
2. At the next stage, patients should be able to access and share data
3. Finally, the solution should be able to push data into the EMR provided physicians have control over what data to import. 

At the MVP stage, you want a device to track health data and present it in an app or dashboard. From our research, we’ve observed that physicians generally prefer dashboards over apps. However, don’t make any assumptions. Research your target users and understand their needs 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 HCPs 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 a patient note of 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. This brief explanation provided by the patient may stop unnecessary interventions and save time for everyone.

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 patient-driven data. Use this as your guiding principle no matter what stage of product development you’re in. 

Get more insights into SaMD and MedTech development

Patient-driven data, wearables and other breakthroughs are driving healthcare evolution. These considerations are just the beginning of the SaMD product journey. To help you move faster, we've put together this checklist that will help you move from idea to MVP. We’ve included information about: 

• Notifications 
• Integration 
• System architecture 
• Usability

Create breakthrough SaMD, MedTech and digital healthcare products. Understand what you need to know and download our checklist now.