Late last week, the United States Food and Drug Administration (FDA) recently released a policy around device software functions and mobile medical applications. The FDA is looking to narrow its regulatory scope to those functions that “could pose a risk to a patient’s safety if the device were not to function as intended.” There is a separate document for clinical decision support software. The organization is looking to focus its oversight on
- Software functions that are an extension of one or more medical devices by connection to such devices for purposes of controlling the device or analyzing medical device data,
- Software functions that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors or by including functionalities similar to those of currently displayed regulated medical devices, and
- Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations (the FDA suggests creating a dosage plan for radiation therapy and computer-aided detection software as examples)
The FDA does not intended to focus oversight on applications that help patients self-manage their disease or conditions without providing specific treatment or treatment suggestions or applications that automate simple tasks for healthcare providers (click here for the organization’s policy for low risk devices intended for general wellness). The FDA specifically mentions software functions that provide patients with simple tools to organize and record their health information as an example of a software function that is NOT a medical device. The organization MAY exercise enforcement discretion on software functions intended for use in the cure, mitigation, treatment or prevention of disease (e.g., helping patients with diagnosed psychiatric conditions maintain their behavioral coping skills; providing periodic educational reminders or motivational guidance [smokers trying to quit, patients recovering from addiction, pregnant women]; video and video games to motivate patients to do their physical therapy at home; tracking medications and providing user-configured reminders for improved medication adherence; providing patients a portal into their own health information, such as access to information captured during a previous clinical visit or historical trending and comparison of vital signs; allowing a user to collect [electronically or manually entered] blood pressure data and share these data through email, track and trend it, or upload it to a personal or electronic health record; and providing prediabetes patients with guidance or tools to help them develop better eating habits or increase physical activity). For this post, I will focus on the opportunity to help patients organize and record their health information.
In a Medical Care paper published earlier this year, Veinot et al. suggested 10 different macro- and meso-level intervensions for health informatics. The first intervention was “collection and display of information.” The potential to use multiple data sources (claims, electronic medical record information and patient reported symptoms and outcomes) could greatly enhance the value of software that organizes and records health information. Assembling information from these disparate places will require a higher-level of sophistication of data modeling.
Ideally, a healthcare data model would be expansive enough to include evidence-based medicine, clinical observations from healthcare providers, testing results, medications and other treatments, claims information and patient-generated health data (preferences, symptoms, functional status and patient-reported outcomes). In America, we seem to lose more age-standardized years of life per 100,000 people to ischemic heart disease, drug use disorders, lung cancer, road injuries and self-harm compared to other high-income countries. A modeling focus on these conditions may be the most meaningful to improve the lives of our fellow human beings. From a risk factor perspective, high body-mass index, tobacco, dietary risks and high fasting plasma glucuse rank higher than high blood pressure, drug use, alcohol use and high LDL.
Graph databases are the current rage in database management. To my untrained eye, graph databases appear to focus on relationships between nodes rather than the nodes themselves. Graph database advocates focus on the approach’s flexibility compared to standard relational databases. At least two healthcare data models, Health Level 7’s (HL7) Reference Information Model and the Observational Health Data Sciences and Informatics (OHDSI) Observational Medical Outcomes Partnership (OMOP) Common Data Model both appear to be relational databases. Given the rapid changes within our understanding of how different concepts might be added or shifted within a disease-specific model, a graph database may be more appropriate than a traditional relational database.
I am not aware of any data model of an individual’s health status from the patient’s point of view. One starting point might be a global measure of health-related quality-of-life, The International Consortium for Health Outcomes Measurement (ICHOM) developed a standard measurement set for older persons that includes five instruments (Medical Outcomes Study: 36-item Short Form Survey [SF-36], ASCOT toolkit, UCLA 3-item loneliness scale, Barthel Index and the Canadian Study on Health & Aging Clinical Frailty Scale). This survey set could be the basis for generating a care plan to maintain specific behaviors or address specific deficits that might impair one’s quality of life. Those deficits may have medical and non-medical causes. Deficits that might be due to a medical condition merit a diagnostic evaluation consistent with the individual’s preferences for diagnostic certainty and tolerance for the suggested treatments. Those diagnoses with acceptable treatments can then be managed accordingly. Tracking metrics like the SF-36 over time could help inform the individual, the caregivers and other members of the healthcare team about the overall effectiveness of the current treatment plan.
Individuals and their caregivers would want to track this information longitudinally without worrying about if others might be watching. Charitable individuals might choose to share their information after some period of time (e.g., 10 years, after qualifying for Medicare) if there was no risk of that information adversely affecting their health or life insurability or social status. The data could provide researchers and future generations a view into what “normal” aging and disease progression might look like and what to consider when planning for the future (e.g., odds of mental decline, quality of life after starting hemodialysis).
The FDA’s decision to withhold enforcements of its requirements on applications that “organize and record their health information” delivers an opportunity to innovate to provide more meaningful information to individuals beyond what is available in electronic medical record portals or accessing claims records. Graph databases may allow companies and individuals to assemble data in new ways as new information about a single patient or cohort of patients becomes available (e.g., new medical evidence, a new medical condition, a change in an individual’s preferences). Focusing on a member’s overall quality-of-life might be an effective way to orient deficits and remedies to address those deficits in a more holistic fashion than our current disease-centered approach.