An integrated web application for decision support and automation of EHR workflow: a case study of current challenges to standards-based messaging and scalability from the EMBED trial

Computerized clinical decision support (CDS) faces challenges to interoperability and scalability. Centralized, web-based solutions offer a mechanism to share the cost of CDS development, maintenance, and implementation across practices. Data standards have emerged to facilitate interoperability and rapid integration of such third-party CDS. This case report describes the challenges to implementation and scalability of an integrated, web-based CDS intervention for EMergency department-initiated BuprenorphinE for opioid use Disorder which will soon be evaluated in a trial across 20 sites in five healthcare systems. Due to limitations of current standards, security concerns, and the need for resource-intensive local customization, barriers persist related to centralized CDS at this scale. These challenges demonstrate the need and importance for future standards to support two-way messaging (read and write) between electronic health records and web applications, thus allowing for more robust sharing across health systems and decreasing redundant, resource-intensive CDS development at individual sites.

The full case report can be downloaded below.  

eHealth Initiative & Foundation (eHI) and Booz Allen Hamilton, released a joint report, Securing Connected Medical Devices, to help industry stakeholders address the challenges associated with the cyber security of connected medical devices. The rise of connected medical devices – which are devices that connect or integrate with other systems (e.g., other devices, tools, networks, services) – represent significant innovations in patient care. These innovations face new and diverse threats not previously in existence. As soon as a medical device is connected in some way – either wirelessly or wired, using a persistent connection or one that is transient, either one-directional or bi-directional – the medical device becomes much easier to disrupt, and the potential disruption much more severe. The medical device ecosystem is at a critical moment where strong leadership across industry, government, and the public is needed to prepare for a secure connected future.

Data and insights platforms are helping healthcare stakeholders manage large volumes of data amongst and between systems, while connecting members of a care team, including the actual patient. The insights gleaned from data and analytics is proving invaluable, and healthcare stakeholders need systems that offer a smooth pathway toward sustainability. Data will continue to be the most valuable asset in managing current and future business models. As organizations grapple with ways to manage the huge volumes of data collected across the healthcare industry, these platforms are helping to create data-centric strategies focused on managing both the entire lifecycle of data and longitudinal, whole person care for any circumstance that could affect health. Data and insights platforms are the waves of the future. Read our report to hear industry perspectives on platforms.

FDA Continues Implementation of 21st Century Cures Health IT Software Provisions

The U.S. Food and Drug Administration (FDA), on September 27, 2019, released final and draft guidance implementing provisions of the 2016 21^st Century Cures Act (Cures) that clarify the regulatory status of health IT software. These provisions, complementing a recent Cures-related proposed rule from the Office of the National Coordinator for Health IT (ONC), culminated years of efforts to resolve the regulatory status of electronic health records (EHRs) and other health IT software. Section 3060(a) of Cures amended Section 520 of the Federal Food, Drug, and Cosmetic Act (FD&C Act), removing some software functions from the definition of a device subject to FDA regulation.

The FDA’s first guidance, released in final form (subject to continued comment), updates a December 2017 draft guidance and provides the agency’s “current thinking” on the Cures device definition and its impact on existing FDA guidance on medical device software. The second guidance, a draft that updates a December 2017 draft (and FDA work that predates Cures), focuses on clinical decision support (CDS) provisions of Section 3060(a) of Cures. It defines which CDS will be subject to FDA regulation as a device and how FDA will approach such regulation. This new guidance is part of the FDA’s broader Digital Health strategy.

In general, software that is not a device would not be subject to FDA regulation. In some cases however, safety aspects of non-device health IT software would be regulated by ONC via the ONC certification process, for example for use of quality management programs and usability testing/safety-enhanced design. ONC also maintains a Health IT Feedback process to handle software complaints.

These new guidance documents have important implications for eHI members, including provider organizations, that develop health IT software. At a minimum, they will affect compliance plans, quality management, product development, and marketing

Guidance: Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act

The changes described in this final FDA guidance are also reflected in conforming revisions to:

• General Wellness: Policy for Low Risk Devices
• Mobile Medical Applications
• Off-The-Shelf Software Use in Medical Devices
• Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices; and withdrawal of
• Guidance for the Submission of Premarket Notifications for Medical Image Management Devices

Section 520 of the FD&C Act states that “device” will not include a software function intended:

(A) for administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow;

Note: FDA has generally not considered such functions to be a device and makes clarifying changes regarding aspects of Laboratory Information Systems.

(B) for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;

Note: FDA clarifies that the exclusion from the device definition applies only to software and not hardware and also does not apply where the function is related to “diagnosis, cure, mitigation, prevention, or treatment of a disease or condition,” with updated examples and pointers to updates in the General Wellness and Mobile Medical Application guidance.

(C) to serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart, so long as—

(i) such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals;

(ii) such records are part of health information technology that is certified under section 3001(c)(5) of the Public Health Service Act; and

(iii) such function is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;

Note: The definition of an “electronic patient record” is narrow, treating the EHR as an electronic version of a paper record.  It is unclear how far it extends to the full range of modern EHRs and likely does not apply to many CDS functions used in EHRs, which are addressed in the separate FDA guidance on 520(o)(1)(E). FDA also indicates that it will not enforce the Cures requirement that only certified functions are eligible for this exclusion. Important for EHRs and similar health IT, FDA also indicates that it will issue future guidance on software that combines device and non-device functions. FDA also provides examples that address apps and other tools that enable patients to interact with EHRs, consistent with the Administration focus on consumer-focused apps connected to EHRs via APIs.

(D) for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or mother device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and finding . . .

Note: Medical Device Data Systems (MDDS), the subject of one of the FDA’s first forays into health IT software regulation in 2011, are now not FDA-regulated devices (software only) and FDA is revising existing MDDS and Mobile App guidance accordingly, including revised examples. FDA also states that, if a multiple function product contains MDDS hardware functions, FDA does not, at this time, intend to enforce FD&C Act requirements.

Draft Guidance: Clinical Decision Support Software

The second FDA guidance released on September 27 covers CDS. It updates the December 2017 draft Cures-related guidance based on comments, notably by (consistent with stakeholder recommendations)  implementing a risk model from the International Medical Device Regulators Forum (IMDRF). Comments are due December 26, 2019.

As amended by Cures, 520(o)(1)(E) of the FD&C Act states that certain CDS software functions are excluded from the definition of device, if they meet all the following four criteria:

1. Not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;
2. Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
3. Intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
4. Intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

FDA uses the statutory CDS definition for this guidance and, based on its interpretation of Cures, identifies Non-Device CDS and Device CDS. Following Cures, the FDA’s primary determinants of whether CDS is a device are its use by a health care professional, the advisory nature of the CDS, and the ability of the professional to do independent review of input data, the basis for rules and algorithms, etc. Developers seeking to confirm or maintain non-device status will want to focus on the latter two criteria, especially for application of artificial intelligence and machine learning.

For Device CDS, FDA proposes a regulatory approach using the IMDRF risk model for Software as a Medical Device (SaMD). It asks if the condition being addressed is Critical, Serious, or Non-Serious (defined in the guidance) and whether the SaMD information Treats or Diagnoses, Drives Clinical Management, or Informs Clinical Management. (CDS that informs and also allows “independent review” is not a device.)

FDA proposes that, if the software goes beyond informing clinical management (i.e., driving clinical management or treating/diagnosing), it is not CDS per Cures and not subject to this guidance and its proposed regulatory flexibility. The FDA uses the IMDRF definition for driving clinical management: “the information . . . will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will be used to guide next diagnostics or next treatment interventions:

• To aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device.
• To aid in diagnosis by analyzing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis.
• To triage or identify early signs of a disease or condition.”

For Device CDS that informs, FDA focuses on the seriousness of the condition, proposing enforcement discretion for CDS for Non-Serious Conditions and oversight (i.e., regulatory focus) on health care professional-oriented CDS aimed at Serious or Critical conditions. Where the intended user is a patient or caregiver, FDA will apply oversight (regulation) to all scenarios except non-serious conditions where the user can independently verify the basis for the recommendation (subject to enforcement discretion).

FDA provides examples for each category of CDS (but not for CDS that is not defined as such in this guidance, for example, because it meets the “drive” criterion”).

Commentary on the CDS Guidance

• The FDA’s definitions of Inform and of Drive (especially with Drive including “guide) are not very different and do not seem to reflect the intent behind the concept “drive” or its plain meaning. It would be very easy for much CDS on the market today to meet the definition of “drive”. It is unclear whether the FDA will rely on the IMDRF “inform” definition in determining whether CDS is a device or only once that determination has been made.
• Many CDS software functions could apply across the full range of condition seriousness, notably those in an EHR or not disease specific, so the actual extent of enforcement discretion may be limited.
• Where it applies enforcement discretion, FDA could choose at a later time to require some device requirements, such as a quality system, while not requiring premarket clearance or approval. Notably, the FDA “encourages developers of CDS software functions that are not medical devices or are medical devices for which at this time FDA does not intend to enforce compliance . . . to implement a quality system consistent with IMDRF’s Software as a Medical Device (SaMD): Application of Quality Management System and to apply good cyber hygiene, such as through software design and cyber vigilance, consistent with applicable FDA guidance”.
• This guidance does not describe how the FDA will regulate CDS for which is applies oversight.

Implications for eHealth Initiative Members and Action Steps

Understanding these guidance documents is important for eHI members that develop health IT software. They finalize (for now) provisions of Cures that limit the extent of FDA regulation of EHRs and other health IT (other than CDS, which remains at a draft stage). They also highlight the limits of Cures-related regulatory relief, whether for EHRs, CDS beyond narrow confines, and certain patient/consumer-facing apps. They will affect how developers approach designing for and communicating the intended use of their products and, especially for CDS, how they enable healthcare professionals to independently review the basis for CDS recommendations.

Health IT software developers should review these new guidance documents, submit timely comments to FDA on the CDS draft guidance and on the finalized guidance documents if issues remain, and monitor how FDA will regulate health IT that it considers a device.

Mark Segal, PhD, FHIMSS, Principal, Digital Health Policy Advisors, LLC. Member and Past Chair of the eHI Policy Steering Committee. October 21, 2019. Twitter @msegal111

eHI thinks Mark Segal is a super cool guy and is providing his opinions for informational purposes only. The opinions presented, do not represent those of eHealth Initiative, our members or the Foundation.

Download this information as 2-page document at the bottom of your screen.

• What is an ICD-10-CM code?
  International Classification of Diseases, Tenth Revision, Clinical Modification coding, known as ICD-10-CM coding, is a system used by clinicians to classify and record all diagnoses and symptoms for care within the United States. Codes are based on the International Classification of Diseases, which is published by the World Health Organization (WHO), using unique alphanumeric codes to identify known diseases and other health problems. ICD-10-CM codes provide a level of detail that is necessary for storing and retrieving diagnostic information, compiling national mortality and morbidity statistics, and processing health insurance claims.

   

• What is an ICD-10-CM Z code for Social Determinants of Health (SDOH)?
  ICD-10-CM codes include a category called Z codes, which are used to describe experiences, circumstances, or problems that affect patient health, but are not considered a specific disease or injury. Z codes identify patients facing socioeconomic and psychosocial circumstances that may influence their health status and contact with health services. Currently, codes included in categories Z55-Z65 document patients’ SDOH in a standardized manner.

   

• How does standardizing the capture of SDOH data codes benefit population health?
  Traditionally, data recorded during a patient visit directly relates to a patient’s health but does not incorporate outside factors that can impact well-being. SDOH data captures information at a level traditional health data sources cannot, and ICD-10-CM Z codes can record this information, giving deeper insights into factors impacting health, such as employment, food insecurity, and housing. Standardizing SDOH would assist in identifying, documenting, and tracking additional markers of health, beyond the physical, and would permit clinicians, hospitals, and health plans to share the information through medical records and insurance claims data.

   

• Are there guidelines for using ICD-10-CM codes for SDOH?
  ICD-10-CM diagnosis codes have been adopted under the Health Insurance Portability and Accountability Act (HIPAA) for all healthcare settings. Guidelines for Z codes are included in the Centers for Medicare & Medicaid Services (CMS) ICD-10-CM Official Guidelines for Coding and Reporting for FY 2020. https://www.cdc.gov/nchs/data/icd/10cmguidelines-FY2020_final.pdf

   

• Why should providers, non-physician healthcare providers, and coders use ICD-10-CM Z codes for SDOH?
  Utilizing Z codes for SDOH enables hospitals and health systems to better track patient needs and identify solutions to improve the health of their communities. The extraction of SDOH data from the Electronic Health Record (EHR) for clinical, operational, and research purposes can facilitate tracking, identification, and referrals to social and governmental services. Rather than a new system or new tool to capture SDOH, leveraging existing ICD-10-CM codes offers an opportunity to expand on the existing system. This practical application brings SDOH into a clinician’s workflow and becomes a part of the patient’s electronic medical record and claims history.

   

• What are the limitations of ICD-10-CM Z codes for SDOH?
  Currently, Z codes for SDOH capture some, but not all, domains of SDOH. Stakeholder groups have requested that the ICD-10 Coordination and Maintenance Committee expand the codes to represent more granular information that would inform more precise, effective, and efficient social interventions, such as “barrier situations” which prevent consumers from obtaining medications and routine and preventive care. Although coding for SDOH is not mandated, when there is documentation of SDOH in the patient’s notes, it is still possible to use Z codes in the same manner that medical coding is done. Coding professionals may not know to scan for SDOH or may be hesitant to use the codes. Additionally, if a code has not been developed for a specific SDOH issue, the issue will not be coded and will not be included in the patient’s overall plan of care, nor as part of the claim submission process, unless it is recorded as narrative text.

   

• Are coding professionals allowed to use non-physician documentation to support ICD-10-CM coding for societal and environmental conditions?
  Yes, coding professionals at hospitals and health systems can report these codes based on documentation by all clinicians involved in the care of patients, such as case managers, discharge planners, social workers and nurses. In early 2018, the American Hospital Association’s (AHA) Coding Clinic published guidance that allows the reporting of SDOH ICD-10 codes based on non-physician documentation. The ICD-10-CM Cooperating Parties approved the advice, with the change effective February 2018.

   

• Where can I find more resources and initiatives around SDOH data and ICD-10-CM Coding?
  • American Hospital Association (AHA) Information sheet on ICD-10 Coding for Social Determinants of Health
  • "Health Disparities: Social Determinants of Health)” (Free online education module by the American Medical Association (AMA)
  • AMA’s Integrated Health Model Initiative (IHMI), Resource Link & Link 2
  • AMA and UnitedHealthcare’s collaboration to support the creation of new ICD-10 codes related to SDOH
  • Centers for Disease Control (CDC) Social Determinants of Health Webpage
  • CMS 2020 ICD-10-CM Files
  • CMS ICD-10-CM Official Guidelines for Coding and Reporting for FY 2020
  • CMS’ Accountable Health Communities Health-Related Social Needs Screening Tool & FAQ
  • Healthy People 2020’s Social Determinants of Health Webpage
  • Humana Food Insecurity and Loneliness Toolkits
  • The National Association of Community Health Centers (NACHC) Protocol for Responding to and Assessing Patients’ Assets, Risks, and Experiences (PRAPARE)
  • American Academy of Family Physicians (AAFP)’s EveryONE Project Toolkit
  • SIREN’s (Social Interventions Research and Evaluation Network) Gravity Project Resource Link & Link 2
  • NCQA Population Health Management Resource Guide

In Summer of 2019, eHealth Initiative and UnitedHealthcare’s National Strategic Partnerships Division convened a collaborative meeting of leaders from payer organizations and other stakeholder groups to address the use of ICD-10-CM codes for capturing social determinants of health (SDOH) data. This meeting marked a significant milestone in the shift to value-based care. Despite the competitive nature of healthcare, the private sector is working together to address factors pertinent to patient care and well-being in a sustainable, scalable manner. The group discussed the need for better education of provider and billing coders on the value of collecting and using SDOH data and identified strategies to accomplish this task:

• Develop a consistent and unified approach to communicate and assist providers and coders in utilizing existing ICD-10-CM codes for SDOH.
• Formulate a strategy and unified approach for providers and coders to assist with adoption and utilization of the proposed SDOH codes once approved.

Attendees agreed that the best strategy to communicate and promote the adoption of ICD-10-CM codes for SDOH to various stakeholder audiences was to:

• Develop this document as well as two-page communication tools for various audiences, including providers and coders. The coder tool, Transforming health care: Why including SDOH codes on claims is critical and provider tool, Using SDOH coding to transform health outcomes are available for use.
• Promote the use of the communication tools at various payer organizations through a high-level communication plan that outlines dissemination to stakeholder groups.

For a brief overview on the topic, check out our eHI Explains ICD-10-CM Coding for SDOH. Links to the provider and coder documents are forthcoming.

Data standards may be wonky, but they will transform health care

A Each of us should reasonably expect that health systems invest as much into providing clinicians with insights to make the right diagnosis or choose the right treatment as they currently invest in determining the right ad to display on a webpage. Although that hasn’t been the case so far, there’s now an opportunity to take a quantum leap to meet that expectation.story with enormous implications for the health of all Americans is likely flying below their radar and that of their physicians. In a nutshell, it’s this: A proposed rule that sets data standards will make electronic health information more accessible to patients and doctors through smartphone-style apps and will transform health care.

Most Americans are familiar with this scenario: During the “conversation” parts of a medical appointment, the doctor faces a computer screen and types information into an electronic medical record system. Such systems store data on hundreds of millions of Americans.

Yet even with all of this data entry going on, it is a struggle for patients to get copies of their records, and an even bigger one to get them in useful, digital formats. Even more alarming, despite the vast amount of data collected by electronic medical record systems, little of it is used to help clinicians make decisions about their patients’ care. That’s unacceptable.

Each of us should reasonably expect that health systems invest as much into providing clinicians with insights to make the right diagnosis or choose the right treatment as they currently invest in determining the right ad to display on a webpage. Although that hasn’t been the case so far, there’s now an opportunity to take a quantum leap to meet that expectation.

The full STAT article can be viewed at this link.  

Implementing Real-Time Clinical Decision Support Applications on OpenICE: A Case Study Using the National Early Warning System Algorithm

This paper presents the design and implementation of a software application, called MEWS, that implements the Royal College of Physician’s National Early Warning (scoring) System on the OpenICE interoperable platform. The MEWS app, as a real-time clinical decision support (RT-CDS) application, does not require the use of an Electronic Health Record System to support its operation. Instead, it is able to receive patient vital sign measurements from any patient physiological monitoring device connected to OpenICE, irrespective of the device manufacturer. Based on the received vital signs, MEWS calculates an overall score indicating the monitored patient’s current status and is intended to direct clinicians to patients showing signs of deteriorating conditions and hence needing immediate intervention. The implementation and deployment of the MEWS app on OpenICE presents a preliminary step to understand the challenge of establishing (data) interface protocols to enable medical device interoperability generally, and for RT-CDS applications in particular, and to establish requirements for bridging the gap of current industrial standardization activities in addressing this challenge.

The full article can be downloaded below.  

U.S. Opioid Epidemic: Impact on Public Health and Review of Prescription Drug Monitoring Programs (PDMPs)

In recent years, the devastating effects of U.S. opioid epidemic has been making news headlines. This report explores background information and trends on opioid misuse, overdose fatalities and its impact on public health. In addition, various efforts to improve surveillance, timeliness of data and Prescription Drug Monitoring Program (PDMP) integration and interoperability are reviewed.

PubMed and internet searches were performed to find information on the U.S. opioid epidemic. In addition, searches were performed to retrieve information about PDMPs and state-specific mandates along with presentation slides and learnings from the 2018 National Rx Drug Abuse & Heroin Summit in Atlanta, GA.

It is clear that the U.S. opioid epidemic has a tremendous impact on public health including the next generation of children. Various data, surveillance & technology-driven efforts including CDCFunded Enhanced State Opioid Overdose Surveillance Program (ESOOS) and use of telemedicine for opioid use disorder treatment aim to improve prevention, treatment and targeted interventions. In addition, PDMP integration and interoperability efforts are advancing to provide prescribers meaningful decision support tools.

The opioid epidemic has a complex impact on public health intertwined with variable factors such as mental health and social determinants of health. Given the statistics and studies that suggest many of the illicit opioid users start with prescription opioids, continued advancement in the area of PDMP integration and interoperability is necessary. The PDMP integrated clinical decision support systems need to supply to healthcare providers access to complete, timely and evidence-based information that can meaningfully inform prescribing decisions and communication with patients that affect measurable outcomes.

While Prescription Drug Monitoring Programs (PDMPs) are valuable tools for providers in making informed prescribing decisions, the variable state mandates and varying degrees of integration and interoperability across states may limit their potential as meaningful decision support tools. Sharing best practices, challenges and lessons learned among states and organizations may inform strategic and systematic use of PDMPs to improve public health outcomes.

The full article can be downloaded below.