Cover RockHealth

This week I've gotten several emails about my thoughts on the House's Energy and Commerce hearing on mobile app regulation by the FDA. While I could come up with my own thoughts on the hearing, I prefer to recap by sending you over to the incomparable Brian Dolan's lists: 5 take aways and 10 threads. Now you're caught up. So today, as promised in a rather polarizing VentureBeat article, Rock Health came out with a slide deck on digital health regulation by the FDA. (Side Note: when did we start calling it digital health? (Second Side Note: When do we get to call technology enabled healthcare just health?)). I loved all the details they gave on how to go through the 510(k) and PMA process - to date, haven't seen a group put out a free "how to navigate" the FDA presentation (so kudos Rock Health!).

FDA 101: A guide to the FDA for digital health entrepreneurs by @Rock_Health from Rock Health - produced by Malay Gandhi (@mgxtro) and Deborah Pascoe (@deborahpascoe).

A Few Comments:

Slide 1: In addition to the Mobile Medical Apps guidance I'd also suggest developers look at the Medical Device Data Systems and Design Considerations for Devices Intended for Home Use.

Slide 3: I’m not sure why the FDA's birthday is relevant - Personally, I would have gone with when the Food, Drug, and Cosmetic Act was signed into law - 1938. FDCA is what expanded the FDA’s regulation authority to include devices and cosmetics. I guess Rock Health doesn't share my love of flappers and the FDCA.

... following FDA regulations will actually make them a better company, with a higher quality process, and open the door to the entire healthcare market. - Geoff Clapp on Slide 23

Slide 4:

Rock Health Question: Why is the FDA looking at Digital Health?
Rock Health Answer: Widespread Availability & Public Interest

"Widespread Availability" and "Public Interest" are why the House Energy and Commerce Committee had a 3 day hearing on digital health. The FDA is a bit simpler - it looks at "digital" health because if something is a device, the FDA regulates it. That’s it.

Slide 5: Really not sure why they refer to the “current” definition of device. Device was codified way back in 1938's FDCA section 201(h) and isn't likely to change...

(h) The term “device” means an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is— (1) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them, (2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or (3) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.

So what’s this really mean? If you’ve got something that treats something with an ICD-9 code and isn’t a drug you’re a device. And if you are, you're subject to the medical excise tax. What won't be subject to the tax? Things that aren't medical devices (as the laughable Hotair puts it: "the federal government is munificently resisting the temptation to tax our smartphones" just like they're not taxing our fax machines. Or, for that matter, regulating our fax machines.).

device formula

Slide 6: Believe me, I really wanted to love this slide. Then I noticed that it wasn’t to scale and got sad.

MMA Vs Other Apps (not to scale)

MMA Vs Other Apps (not to scale)

Mobile Medical Apps vs Other Apps (Rock Health Numbers, to scale)

Mobile Medical Apps vs Other Apps (to scale)

Not such a big piece of the space, now is it? Since there isn't a numbered estimate for the gray area of apps which “might” be regulated, I couldn't scale that space.

RockHealth_mHealthGuidance_7_3.25.13
Slide 7: Again, so close to loving this slide. I just wish patient/consumer Safety had made the list. Yes, they said “consumer confidence” but when we’re talking about FDA oversight, we’re talking about medical devices and patient safety. FDA approval does increase physician confidence, but they’re not the end user/consumer in this continuum.

Slide 9: CMS doesn’t regulate devices. Pay for them, sure, but regulate? Not so much. I suppose we can go to futuristic imagination land where everything is mobile and talk about how a future iteration of Meaningful Use may require a provider to use a mobile application per CMS specifications. Barring that, CMS isn’t regulating mobile. Setting reimbursement guidelines, yes. Regulating? No. I’d definitely worry about the FTC before I even though about CMS – particularity in relation to apps which aren’t even considered devices. More on that regulatory continuum can be found in my HIMSS13 presentation. 
RockHealth_mHealthGuidance_9_3.25.13

 

RockHealth_mHealthGuidance_12_3.25.13
Slide 12:  Once I read this article, I understood what they were getting at with this example.  I think my brain still had a problem with it because their Class I example didn't have a mobile application associated with it. Glooko is a good example of the evolution of MMA stages - originally their system/cable was a Class I device - all the cable did was transmit data in its original form for recording. But they couldn't do analytics on it which means its usefulness was limited. Recently they received Class II clearance for their Glooko Logbooks Chart product. And maybe in a few years Glooko will come out with an app that helps control an artificial pancreas device and have to get Class III approval. 

Glooko Example

In closing, great job to the Rock Health team for interviewing so many thought leaders in this space - really enjoyed the emphasis on the FDA being composed of real people (believe me, they are!)!

Author Note: The views in this blog are strictly mine and should not be attributed to any organization mentioned. I do not work for the federal government and the contents of this site do not represent the views of any federal agency. It is important to note that my ORISE fellowship is with the FDA's Center for Drug Evaluation and Research and I do not have inside knowledge regarding the device approval process.

On March 5, 2013, Eric Wickland crossposted a recap of my session cross-posted to Healthcare IT News("Acronyms abound in mHealth Ecosystem"), HIMSS, ("HIMSS13 mHealth session explores federal policy issues") and mHIMSS ("Acronyms abound in mHealth Ecosystem").

HIMSS13
Copied below:

Thinking of diving into the mHealth ecosystem? You'll need a really good grasp of acronyms. And a healthy dose of patience.

Attendees of the 2013 HIMSS Conference and Exhibition were treated to a primer on the alphabet soup of organizations in "Federal mHealth Policy 101," a Monday-morning education session presented by Jessica A. Jacobs, MHSA, CPHIMS. Her hour-long session targeted the bigger federal players, including the HHS, CMS, FDA, FTC, FCC and the Office of Civil Rights.

It also brought to the forefront the realization that, with so many organizations wanting their share of the mHealth pie, the required rules, regulations and standards aren't showing up with any degree of haste.

To wit: The FDA's final document regarding regulation of mobile medical apps has been expected for several months, and still isn't here.

"I have seen a lot of predictions that say March," Jacobs shrugged. "But who knows?"

Also in the pipeline is a regulatory framework for mHealth that's being put together by the FDA, FCC and ONC. That one at least has a deadline, Jacobs pointed out, though that deadline is roughly one year distant.

Jacobs, who has worked with the ONC, FDA and HRSA and chaired the mHIMSS Mobile Devices and Regulatory Implications group, put together a primer on the various agencies involved in mHealth that touched on their responsibilities. She also noted that many of the agencies share those responsibilities and are working together to make sure the landscape is properly regulated.

During a Q&A session, she was asked about Happtique, the New York-based app store that recently unveiled a standards program for apps. Jacobs said Happtique's program, set to launch this spring, may very well be like the Certification Commission for Health Information Technology's EHR certification program. When asked if mHealth regulations might be too strict, and therefore serve to stifle innovation, she said the federal government is trying to take a broad-based approach so that it doesn't hinder creativity.

The key to the mHealth landscape going forward, she said, is collaboration.

"There are a lot of cabinet players in this mobile health space," she pointed out.

This morning I had the opportunity to present on federal mHealth Policy at #HIMSS13. It was totally a great time and people had some amazing questions. Most of which I hoped I answered...

 Policy Continuum

 Download the slides here. 

mHimss

The mHIMSS Policy Group presented our “Summary of Federal Policies and Mobile Applications" just before annual conference this year. While HIMSS has a version, most of it is copy/pasted below. The awesome summary table can be opened  here.


Introduction

February 2012

Dear Reader –

The mHIMSS Policy and Regulatory Implications Workgroup is pleased to present this summarization of mHealth related federal regulations and policies. For those developing a mobile policy, summaries regarding OCR’s HIPAA and CMS/ONC/NIST’s Meaningful Use will be particularly insightful. Additionally, this guide covers information related to developers and manufacturers, and includes insights from the FTC, FCC, and FDA’s Mobile Medical App Guidelines.

The team, chaired by Jessica Jacobs, includes the original work of Wendelyn Bradley, Nick Falcone, Rebecca Kennis, Lee Kim, Michael Kuriland, Patricia MacTaggart, and Daisy Wong.

  • Wendelyn Bradley, BSN/MA, MS Medical Informatics -- Scripps Green-Scripps Health-Administrative Clinical Project Manager. A Scripps employee for 14 years, for the past 10 she has guided clinical software implementation projects. Currently she leads the Perioperative Optimization project and system-wide clinical system roll out.
  • Nick Falcone, CISSP -- Security Operations Engineer with the Children’s Hospital of Philadelphia, is responsible for HIPAA Security Rule compliance, risk assessment, third party management, and policy and procedure.
  • Jessica Jacobs, MHSA, CPHIMS -- Oak Ridge Institute for Science and Education Fellow stationed at the Food and Drug Administration’s Center for Drug Evaluation and Research. [1] She helped stand up the Federal mHealth Collaborative and currently leads FedTel’s “Technology, Innovations, and Standards” workgroup.
  • Rebecca Kennis, CPHIMS -- System Analyst at UHS Hospitals in Binghamton, NY. She is responsible for managing the development and maintenance of mobile device applications, clinical decision support and Meaningful Use initiatives.
  • Lee Kim, BS, JD -- Attorney at Tucker Arensberg, PC. She is an intellectual property and healthcare information technology attorney and a board member of Western Pennsylvania HIMSS. She previously worked in the field of heath information technology.
  • Michael Kurliand, RN MS -- IS Strategy Consultant at the Children's Hospital of Philadelphia. Member of an IS team under the CIO that is responsible for the overall strategic assessment and planning process as well as industry and trend analysis and implementation development.
  • Patricia MacTaggart, MBA, MMA -- George Washington University Lead Research Scientist and Lecturer at the Department of Health Policy/School of Public Health and Health Services and Adjunct Associate Professor, Health Policy & Management, UNC-Chapel Hill. She is a member of HIMSS Public Policy Committee and advises Security and Privacy track students for ONC’s HITECH funded University Based Training Graduate Certificate Program.
  • Daisy Wong, PhD -- Adjunct Assistant Professor at the Computer and Information Sciences at the University of Alabama at Birmingham. She teaches and also provides research and consulting to heath care analytics industry.

Additionally, the group would like to recognize the support we received from Rob Campbell, CEO of Voalte, and HIMSS in the creation of this document, particularly Tom Martin and Tim Castallo.

Here’s to mHealth!

The mHIMSS Policy and Regulatory Implications Workgroup

 

Office for Civil Rights: Health Insurance Portability and Accountability Act

Who is Responsible:

Individuals, organizations, and agencies that meet the definition of a covered entity under HIPAA must comply with the HIPAA Privacy and Security Rules’ requirements to protect the privacy and security of health information and must provide individuals with certain rights with respect to their health information.

  • Most doctor offices, hospitals, health plans, health care clearinghouses and insurance companies are covered entities.
  • Under the HITECH Act, HIPAA Privacy and Security Rules apply to business associates of covered entities. HITECH Act §13401.
  • A covered entity is any entity that receives federal financial assistance from the Department of Health and Human Services or is covered under Title II of the Americans with Disabilities Act as a program, service, or regulatory activity relating to the provision of health care or social services.
  • Are You a Covered Entity?
  • A “business associate” is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity. A member of the covered entity’s workforce is not a business associate.

What and Why it is regulated:

Under the HIPAA Privacy and Security Rules, covered entities are required to take certain steps to ensure that their patients’ protected health information (PHI) remains private and secure. As stated above, under the HITECH Act, business associates must also comply with the HIPAA Privacy and Security Rules.

  • Protected Health Information: all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic (ePHI), paper, or oral (PHI). ePHI is a form of PHI.
  • Examples:
  • Any demographic data, that relates to the individual’s past, present or future physical or mental health or medical condition
  • The past, present, or future payment for the provision of health care to the individual
  • Data for which there is a reasonable basis to believe can be used to identify the individual
  • Individual identifiable health information such as name, address, birth date, and Social Security Number

The Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity, and availability to those who are authorized to see PHI. The key requirement of the security rule is to conduct a risk assessment and to address the results. The Security Rule is technology neutral, so its standards apply regardless of whether the covered entity is transmitting or receiving electronic protected health information from computer to computer, laptop to laptop, tablet to tablet, or smart phone to smart phone – or any other combination thereof.

The Privacy Rule gives the consumer rights over his/her health information and sets rules and limits on who can view or receive his/her health information.

How and When the Regulation Will be Enforced:

The U.S. Department of Health and Human Service’s Office for Civil Rights (OCR) is responsible for privacy and security enforcement of HIPAA. Currently the OCR is piloting a program to perform up to 150 audits to assess privacy and security compliance. Audits conducted during the pilot phase will begin November 2011 and conclude by December 2012.

Reference:

This summary is based upon the HHS’, Understanding Health Information Privacy site.

Centers for Medicare and Medicaid Services: Meaningful Use

Who is Responsible:

Each Eligible Hospital (EH), Critical Access Hospital (CAH), or Eligible Provider (EP) must demonstrate that they are a “Meaningful User” of a certified electronic health record.

What and Why it is regulated:

This requirement was made law through the Health Information Technology for Economic and Clinical Health (HITECH) Act, which is part the American Recovery and Reinvestment Act (ARRA) of 2009. HITECH promotes the implementation and use of health IT and includes billions of dollars in incentive payments, and eventually, penalizes Medicare providers through reductions in their reimbursements. CMS is promulgating the Meaningful Use rules in three stages under the advisement of NIST and ONC. Additionally, for each stage of Meaningful Use, ONC will promulgate an associated standards rule set.

Currently, Meaningful Use is still in the incentive period. To qualify for an incentive, providers must meet Stage One objectives. Stage One objectives are split into a core group and a menu group. In order to meet Meaningful Use status, all objectives in the core group are required plus 5 of 10 objectives from the menu group for eligible professionals, critical access hospitals, and eligible hospitals. In addition, 15 Clinical Quality Measures are required for eligible hospitals and critical access hospitals and 3 core clinical quality measures (or 3 alternate core clinical quality measures) plus 3 additional clinical quality measures out of a set of 38 for eligible professionals. One of the required core objectives is the utilization of CPOE for eligible hospitals, critical access hospitals, and eligible professionals.

The relationship between Meaningful Use requirements and mobile devices intersect when defining the CPOE requirement of the core group. The Final Rule states that if CPOE occurs through the use of an application on a mobile device, that application must be certified for Meaningful Use as a complete EHR or module. It could be further deduced that any requirement that is fulfilled via a mobile device application would require the application to be certified.

How and When the Regulation Will be Enforced:

Meaningful Use requirements will be implemented in three stages; Stage 1 was defined in the final regulations released in July 2010. The Notice for Proposed Rule Making for Stage 2 is set to be released by the end of the 1st Quarter 2012, Stage 3 is proposed by the end of 2013. While Meaningful Use is currently in an incentive period, starting in 2015, providers will experience a reduction in their Medicare reimbursements if they fail to reach Meaningful Use requirements.

Reference:

This summary was based off of CMS’ Meaningful Use page.

 

 

NIST: Test Procedure for ONC Certified EHR CPOE from Drug-Drug, Drug-Allergy Interaction Checks

Who is Responsible:

This guidance is targeted at eligible hospitals, vendors of ONC Certified EHR CPOE and ONC-Authorized Testing and Certification Bodies (ATCBs), who will use the test procedures to evaluate conformance of EHR technology to ONC’s requirements as defined by NIST.

What and Why it is regulated:

These test procedures define test criteria for EHRs. If the EHR does not meet these requirements, the eligible hospitals (EHs) will not meet Meaningful Use.

This test procedure is organized into two sections:

  • Generate and indicate notifications – evaluates the capability to generate and indicate in real-time notifications at the point of care during computerized provider order entry (CPOE) for drug-drug and drug-allergy contraindications based on the patient’s medication list and medication allergy list.
    • The Vendor identifies specific alerts available in the EHR and available CPOE orders that can be used to initiate those alerts.
    • The Tester enters new medication orders via CPOE and generates at least one each of drug-drug and drug-allergy notifications identified by the Vendor.
    • The Tester validates that the notifications are generated and indicated to the user in real-time during CPOE, are based on the patient’s medication list and medication allergy list, and are displayed as defined by the Vendor.
  • Adjust notifications – evaluates the capability for certain users to make adjustments to drug-drug and drug-allergy interaction checking.
    • The Tester selects and displays the drug-drug and drug-allergy notification adjustment capabilities identified by the Vendor for this test.
    • The Tester adjusts at least one each of the selected drug-drug and drug-allergy notification rules; an example of an adjustment would be changing the level of severity of a notification for all user types or a specific user-type, for instance, causing the suppression of a drug-drug interaction notification for all CPOE users or only for cardiologists who order Digoxin and Furosemide together for the same patient.
    • The Tester validates, in real-time during CPOE, that the selected drug-drug and drug-allergy notifications have been adjusted as described by the Vendor.

This test Procedure requires the vendor to supply the test data. The Tester shall address the following:

  • Vendor-supplied test data shall ensure that the functional and interoperable requirements identified in the criterion can be adequately evaluated for conformance.
  • Vendor-supplied test data shall strictly focus on meeting the basic capabilities required of an EHR relative to the certification criterion rather than exercising the full breadth/depth of capability that an installed EHR might be expected to support.
  • Tester shall record as part of the test documentation the specific Vendor-supplied test data that was utilized for testing.

How and When the Regulation Will be Enforced:

For an eligible hospital to receive EHR Incentive payments from Medicare and Medicaid they must be able to validate the capabilities listed above. An ONC-Authorized Testing and Certification Body (ATCB) must use these procedures when certifying an EHR for ONC.

Reference:

This summary is based upon NIST’s Test Procedures for Drug-drug, drug-allergy interaction checks.

 

Food and Drug Administration: Mobile Medical App Guidance

Who is Responsible:

This guidance is targeted at manufacturers and distributers of mobile medical apps.

  • Manufacturer” encompasses any person or entity that manufactures mobile medical apps in accordance with 21 CFR Parts 803, 806, and 807. Includes: anyone who initiates specifications, designs, labels, or creates a software system or application in whole or from multiple software components. Does not include: developers who strictly operationalize a manufacturers’ design.
  • Distributor” refers to entities that exclusively distribute mobile medical apps. Distributors are expected to work with manufacturers in correcting/removing products, but are not responsible for seeking FDA approval. Common distributors include the iTunes store, Android marketplace, and Blackberry app world.

What and Why it is regulated:

A “mobile medical application” or “mobile medical app” is a mobile app that meets the definition of "device" in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act); and its intended use is: as an accessory to a regulated medical device; or to transform a mobile platform into a regulated medical device. These devices are regulated to protect patients from unexpected harms.

Examples:

  • Displaying, Storing, or Transmitting: If a mobile medical app allows for the display/storage/or transmission of patient-specific information, such as personal health information (PHI), in its original format, it is a medical device. This category of mobile medical apps are primarily used as secondary displays (and not for primary diagnosis/treatment decisions) and will only require Class I requirements. For example, a PACS Viewer (like Centricity® Radiology Mobile Access 2.0 software[i]) or mobile ECG viewer (like AirstripTM RPM Cardiology[ii] device) would be regulated under this criterion.
  • Controlling connected medical devices: If a mobile medical app allows for the control of another medical device, it must adhere to the regulations applicable to the connected device. These mobile medical apps can control the use, function, modes, or energy source of a regulated medical device. For example, an app that controls a blood pressure cuff (like Withings®[iii] blood pressure monitor) or a portable ultrasound app (such as the Mobisante software[iv]).
  • Mobile platform transformation: If a mobile medical app transforms a mobile platform into a regulated medical device, it is regulated under the class applicable to its intended use. For example, if a mobile medical app utilizes a phone’s accelerometer to collect data on Parkinson’s disease such as iTrem software.[v]
  • Interpretation of Medical Device Data: If a mobile medical app is intended to analyze or interpret data from a medical device for the purposes of creating alarms, recommendations, or information, is considered an accessory to the first medical device and regulated under the first medical device’s class. This would include patient monitoring apps such as the LifeWatchTM cardiac monitoring system.[vi]

How and When the Regulation Will be Enforced:

If the mobile medical app falls within a specific medical device classification or augments functionality to a specific medical device classification, manufacturers are immediately subject to meet the requirements of that classification (either I, II, or III).

Reference:

This summary is based upon the FDA’s Mobile Medical Apps site.

Federal Communication Commission

Who is Responsible:

Device manufacturers are responsible to design and manufacturer their devices according to the FCC Specific Absorption Rate (SAR) limits. Some examples of devices which might fall under FCC oversight include insulin/glucose monitors, wireless heart monitors, medical radios, and/or cell phones.

What and Why it is regulated:

The FCC regulatory effort has been focused on protecting human health from negative RF (Radio Frequency) exposure and to prevent potential interference among mobile health devices such as implanted cardiac pacemakers. The allowable FCC SAR limit for RF energy exposure from wireless devices is 1.6 watts per kilogram (W/kg), as averaged over one gram of tissue.

Research to determine the health effect of RF exposure is ongoing by various organizations including the FDA and WHO. There are varied interpretations of reports that links wireless device use and cancer and other illnesses. Therefore, the FCC is closely monitoring these study results but has no basis so far to change the current SAR requirement.

How and When the Regulation Will be Enforced:

All wireless devices sold in the US go through a formal FCC approval process to ensure that they do not exceed the maximum allowable SAR level when operating at the device’s highest possible power level. If the FCC learns that a device does not confirm with the test report upon which FCC approval is based – in essence, if the device it stores is not the device the FCC approved, the FCC can withdraw its approval and pursue enforcement action against the appropriate party.

In addition, Wireless Medical Telemetry Service (WMTS) devices used within a health care facility must be registered with the FCC’s designated frequency coordinator and demonstrate that the devices operate within the WMTS spectrum.

References:

This summary is based upon material on the FCC website.

 

 

Federal Trade Commission (FTC)

Who is Responsible:

The consumer data privacy guidance is targeted at policymakers and business that collect data through computers, mobile devices and mobile applications that can be reasonably linked to a specific consumer, computer, or other device. The policies on advertising apply to advertisers.

What and Why it is regulated:

FTC’s proposed framework for consumer data advocates companies to incorporate consumer privacy protection in their businesses; to provide choice to consumer on the use of his or her data; to be transparent with their data practices; to educate consumers on data privacy practices, and provide reasonable access to the consumer data that they maintain. In regard to consumer data privacy, companies do not need to provide choice before collecting and using consumers’ data for commonly accepted practices, such as product fulfillment.

FTC Framework: Consumer Data Privacy Protection

Regarding consumer data privacy protection, the FTC framework includes the following three principles for companies:

  • Companies should incorporate substantive consumer privacy protections throughout their organizations and at every stage of the development of their products and services.
  • Companies should simplify consumer choice. For collection of consumer data for uncommon practices and uses, companies should offer the choice in a simple way at a time and in the context in which the consumer is making a decision about his or her data.
  • Companies should increase the transparency of their data practices and educate consumers on commercial data privacy practices.

FTC Framework: Advertisements

Regarding advertising, the FTC has the following policies in place to guide advertisers:

  • Federal Trade Commission Act
  • Deception Policy Statement
  • Unfairness Policy Statement

How and When the Regulation Will be Enforced:

The FTC regulatory efforts focus on protecting consumer (particularly minors) data privacy and preventing fraudulent or deceptive marketing/advertising that misleads consumers. It will exercise regulatory authority over products and services regardless of the hardware or platform involved. The FTC utilizes the existing FTC Act and laws to determine violations. There are no additional requirements for mobile applications or devices in their current guidance and regulations.

References:

This summary is based upon material on the FTC website.


[iii] http://mobihealthnews.com/11275/fda-clears-withings-iphone-blood-pressure-cuff/. Withings is a trademark or a registered trademark of Withings SAS France.

[iv] http://www.imedicalapps.com/2011/10/fda-sanctioned-mobile-health-apps-making-appearance/

[vi] http://www.lifewatch.com/siteFiles/1/319/5257.asp. LifeWatch is a trademark or a registered trademark of LifeWatch Holding Services, Inc.


[1] Please note, Ms. Jacobs was not involved in the development of any of the guidances/regulations profiled in this summary and her work does not represent the official views of the FDA, HHS, or ORISE. She was enabled to participate through her ORISE fellowship, funded through an interagency agreement between the DOE and HHS/FDA.