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.

Blog from Patricia Wagner & Alaap Shah of Epstein Becker Green.

Data is king! A robust privacy, security and data governance approach to data management can position an organization to avoid pitfalls and maximize value from its data strategy. In fact, some of the largest market cap rms have successfully harnessed the power of data for quite some time. To illustrate this point, the Economist boldly published an article entitled “The world’s most valuable resource is no longer oil, but data.” This makes complete sense when research shows that 90% of all data today was created in the last 8/23/2019 Free the Data! ... Better Think Twice ... Legal Issues Regarding Data Sharing and Secondary Data Use | Health Law Advisor https://www.healthlawadvisor.com/2019/02/04/free-the-data-better-think-t... 2/4 two years, which translates to approximately 2.5 quintillion bytes of data per day.

Download to read more...

March 7, 2019 blog by Daniel Kim & Alaap Shah of Epstein Becker Green.

Consumer privacy protection continues to be top of mind for regulators given a climate where technology companies face scrutiny for lax data governance and poor data stewardship. Less than a year ago, California passed the California Consumer Privacy Act (CCPA) of 2018, to strengthen its privacy laws. In many regards, the CCPA served as a watershed moment in privacy due to its breadth and similarities to the E.U. sweeping General Data Protection Regulation (GDPR) law.

Download to read more..

Blog from Alaap Shah and Ebunola Aniyikaiye of Epstein Becker Green.

On February 11th, blockchain advocates, digital health enthusiasts, and patients received positive news from the Center for Medicare and Medicaid Services (“CMS”) and the Ofce of the National Coordinator for Health Information Technology (“ONC”) regarding patient data sharing. These rules, taken together, seek to make data more liquid, which can promote patient access, continuity of care, research, collaboration across the industry and several other activities that previously faced challenges within a health care system built on data silos.

Download to read more...

Decision tree from Epstein Becker and Green: Does the California Consumer Privacy Act (CCPA), effective January 1, 2020, apply to my Organization?

August 12, 2019

New York has joined California, Massachusetts, and Colorado in adopting a law that requires businesses that collect private information on residents to implement reasonable cybersecurity safeguards to protect that information. New York’s law mandates the implementation of a data security program, including measures such as risk assessments, workforce training, incident response planning and testing, and secure data destruction protocols. Businesses should immediately begin the process to comply with the law’s requirements effective March 21, 2020. Notably, New York’s law covers all businesses, employers, or individuals, regardless of size or location, who collect private information on New York State residents.

Download to read more...

ONC continues to re-draw the map of patient care with its Trusted Exchange Framework and Common Framework (TEFCA) Draft 2 that aims to:

• Provide a single “on-ramp” to nationwide electronic health connectivity;
• Ensure electronic information securely follows when/where needed; and
• Support nationwide scalability for network connectivity.

TEFCA Draft 2 is an alphabet soup of abbreviations.  Two of the most important concepts are the Qualified Health Information Network (QHIN) -- the hub and main actor in the TEFCA universe --  and the Recognized Coordinated Entity (RCE). The yet-to-be selected RCE  -- a non-profit, industry-based organization -- will deal with the Common Agreement that creates baseline technical and legal requirements for sharing electronic health information on a nationwide scale across disparate networks.

eHI recently submitted feedback to ONC on TEFCA Draft 2.  We congratulated ONC on:

• QTF - Adding a separate QHIN Technical Framework (QTF);
• More Reasonable Timelines - Extending the timeline for QHINs to update and comply with agreements and technical requirements from 12 to 18 months;
• Positive QHIN Refinements - Refining QHIN exchange modalities and pre-requisites, to better reflect today’s healthcare practice and market realities; and
• Flexibility and Phase-Ins - Incorporating more flexibility to build from existing exchange capability and standards, as well as a phasing-in of appropriate provisions and requirements.

eHI cautioned ONC on:

• Tread Carefully - eHealth Initiative cautions ONC to be very mindful the Congressional intent expressed in the 21^st Century Cures Act that the TEFCA avoid disruption and duplication of “existing exchanges between participants of health information networks.” And, where existing networks that meet needs are in place, ONC is encouraged to build upon them.
• Complex QHINs - ONC’s TEFCA Draft 2 document offers many additional details about the Qualified Health Information Networks (QHINs). eHealth Initiative expresses concern and caution about the complexity of the QHIN concept and its ecosystem. We urge ONC to pay close attention to public comments about whether the QHINs, as currently conceived, will work effectively and build enough value.
• Sustainability – The TEFCA processes, including the RCE and the QHIN, must be financially sustainable and not overly dependent on federal funding.
• RCE Independence – The RCE should have significant independence from ONC with transparent accountability (including to ONC) and governance that engages all stakeholders, and particularly end-users.
• Fees - eHealth Initiative requests additional information around QHIN to QHIN fee details, particularly what constitutes “reasonable and non-discriminatory criteria” that a QHIN is to use if it charges any fees to another QHIN. Effective ONC and RCE communication with relevant stakeholders on fee issues will be absolutely critical.
   

See our attached comments for more details. eHI is in a unique position to comment and offer insight on federal government as the only national organization that represents all stakeholders in the healthcare industry. Stay tuned for more!

Frequently Asked Questions on HIPAA and Health Plans Support Care Coordination and Continuity of Care

2019 is a year of unprecedented regulatory releases and activity by federal healthcare agencies. eHealth Initiative (eHI) responded to two of the year's most significant proposed rules related to interoperability and information blocking on Thursday, May 30. Key issues highlighted in eHI’s CMS and ONC responses include:

Overarching ONC and CMS Issues

• Agency Coordination – Practical, thoughtful agency coordination between ONC and CMS on implementing programs related to these proposed rules is needed.
   
• Promoting Patient Access to and Control over Health Information – eHI expresses support for the ONC and CMS strategy to anchor their proposed rule around fostering innovation that promotes patient access to and control over their health information. eHI emphasizes that patient self-efficacy is critical in value-based payment and patient engagement/education is fundamental to that success.
   
• Patient Matching RFI – eHI supports the intent expressed in the proposed rules to identify additional opportunities in the patient matching space and explore ways that ONC and CMS can lead and contribute to coordination efforts with respect to patient matching. eHI also offers its perspectives and support on patient matching issues such as:
  • Matching solutions involving patients;
  • Adoption of well-tested demographic data standards to improve patient matching; and
  • Working with industry and experts to identify other regularly collected demographic data elements that could be incorporated into the US Core Data for Interoperability (USCDI) to support patient matching.

ONC Specific Issues

• Scope of Electronic Health Information - Given that the electronic health information definitions will form the basis for both action and penalty in our healthcare system, eHI urges ONC to further define and appropriately focus and specify the electronic health information definition for the final rule.  
   
• Conditions and Maintenance of Certification (APIs) - eHI commends ONC for selecting an innovative and flexible suite of standards and associated resources, including HL7® Fast Healthcare Interoperability Resources (FHIR®).

As with the proposed information blocking provisions, eHI urges caution given our concerns about complex and costly compliance, documentation, patient education and healthcare stakeholder risk issues related to the proposed API provisions. All parties will need to undertake significant steps to implement APIs and all stakeholders will need to work together to ensure a measured, secure, informed and realistic approach to this transition.

eHI also registers concern regarding the proposed rules’ API provisions and the associated app and attestation process, which could present risk to both providers and patients. Specifically, according to the ONC proposed rule:

APIs should require a “yes” attestation by the app that patients are provided meaningful notice and control over how their protected health information (PHI) is used to connect to the API.

eHI believes that this traditional "click yes to continue" model likely isn't enough to communicate to the patient the risk managing that data might have or to give confidence to providers concerned that patients understand the risks and benefits of this data use. Healthcare providers and others should be assured that patients comprehend the risk prior to using their data in apps and in choosing using the API.

We urge ONC to evaluate for future certification criteria, ways in which certified health IT can gather and store information specific to a patients’ understanding of the use of the data, drawing as appropriate on elements of the Model Privacy Notice created by ONC.

• Information Blocking - eHI urges a review of the very broad definitions of health care actors related to information blocking, particularly health information networks and health information exchanges. We also register caution and concern about complex and costly compliance and documentation related to the proposed information blocking provisions.  eHI expresses its willingness as a leading, multi-stakeholder national HIE resource to work with ONC on HIE issues as they evolve and grow within ONC program purview.

CMS Specific Issues

• Patient Access Through APIs (Open API Proposal for MA, Medicaid, CHIP, and QHP Issuers in FFEs) - eHI registers caution and concern about complex and costly compliance, documentation, patient education and healthcare stakeholder risk and liability issues related to the proposed API provisions. Significant steps to implement APIs will be required and all parties will need to work together to ensure a measured, secure, informed and realistic approach to this transition.

Cited as particularly aggressive are the API implementation and data availability timeframes - January 1, 2020 for MA plans and QHP issuers in FFEs, July 1, 2020 for Medicaid FFS, Medicaid managed care plans and CHIP managed care entities.

For more information, please see eHI’s detailed ONC and CMS comments attached below.