Regulatory Education for Industry (REdI) Annual Conference 2023 Day 1 Session 4

welcome back from the break we're on the home stretch now our first presentation in this session is on data standards and it will be an overview of the C dur C Burr the data standards program our presenter Ray Wang is the director with the data standard staff in the office of strategic programs next Andrew Potter will present on padufa 7 goals for digital Health Technologies a

regulatory review perspective Andrew Potter is a mathematical statistician in the division of Biometrics one within the bio office of biostatistics the office of translational Sciences and our final presentation in the session will be on the padufa 7 goals for digital Health Technologies with an I.T perspective our presenter Marianne slack is the director with the office of strategic program Ann Cedar please join me to welcome our

first presenter Ray Wang foreign my name is Ray Wang and I am the lead for Cedar status standard staff within the office of strategic programs for today's presentation I will be presenting on behalf of both Cedar and sieber Status Dance Program since we often collaborate on many of the same initiatives and we also share the same goes as set forth in our drawing data standards strategy

plan um so this is just a typical disclaimer the content that I present today should not be considered as a device or guidance on behalf of the FDA my presentation is um also not meant to imply any changes to guidance or regulations those will be announced through the regular channels such as um through a federal registry notice or postings to the fda.gov website now moving on

to the agenda we will start with an overview of the cedar receiver data standards program Mission and its operating framework then go over our strategic goals at a high level um followed by a slightly deeper dive into the projects that fall under each one of these goal areas and we will go through a diagram that helps to visualize help align our strategic goals within the context

of our regulatory review processes and after that I will highlight a couple projects that showcase our efforts in modernizing regulatory submission data standards and with that let's dive into the presentation starting with our mission so as many of you may already be aware the data standards enables the use of Technologies for activities across the regulatory review life cycle you know it helps to make submissions more

predictable and consistent so that they can be used by the agency's IP systems or scientific tools our mission as stated here is to promote electronic information exchange standards and terminologies to enable the effective and efficient review of regulatory submission through stakeholder collaboration policy development and project implementation thank you um next slide this is um so before I start going through our projects I would like to

First provide you with some information on how our data standards strategic goals came to be specifically what are some of the factors that drove the creation of these strategic goals the data standards program operates underneath a set of guiding principles on the left which are to one use voluntary and consensus-based standards development process reduce regulation burden by aligning with existing Health I.T initiatives laws regulations and

mandates and lastly adopt or adapt other standards currently in use when feasible so while these guiding principles provide the context on how we operate the regulatory framework on the right assess the legal boundaries on what we can require for submissions and from a standards perspective how these submissions should come into the agency um and lastly since the main purpose of the Dallas damage program is to

support a more efficient regulatory review process there needs to be alignment with higher level agency and Center strategic plans which is why we're also talk into consideration documents such as the FDA policy roadmap the fdip Strategic plan the Paducah commitments as well as both Cedar and Sievers strategy um and in the middle we have also updated our program vision statement and that is to support fda's

Public Health Mission through predictable consistent and high quality data standards so so these factors drove the creation of our data standards programs both these goals that you see at the bottom of the Swiss slide were taken from the cedar receiver join data standard strategic plan which was updated last year to better align with the particular seven commitments so for the latest set of goals we have

four and they are to improve data standards for regulatory use data standards policy efficient information management and enhanced transparency and stakeholder engagement moving on um diving just a little bit deeper into these strategic goals goal one is focus on providing data standards for a receipt and exchange of regulatory data to achieve predictable and consistent results identify efficiencies to allow that to be systematically captured processed and

analyzed this goal essentially covers all of our standards valuation testing and adoption projects go to is for the implementation and refinement of internal governance processes to ensure proper oversight during the development publication and maintenance of guidance documents that details the use of data standards terminologies and exchange formats for regulatory submissions in other words go to whether it's a guidance text back or some other rulemaking activity

it is the business implementation aspect of data standards go 3 aims to enhance data quality and data governance and effectively populate FDA systems with predictable and consistent data data formats that can be more easily used by our analytics systems and go four which is um Communications it serves to improve transparency and promote stakeholder engagement in the industry's decision-making process regarding adoption of new standards and updates

to existing data standards so this slide um it's an exercise to connect the goals with the portfolio of data standards project as Cedar and sieber this is certainly not a comprehensive list of all projects but more so a sample list of some of our key initiatives while I'll be going through each of these projects in more detail in the following slides I would note that this

presentation is not meant to be a deep dive but rather a overview of the project goals and the Key activities that are currently underway now exceptions to this would be the three projects that I have selected to further highlight we which I will go over later in the presentation so starting with Goal one um the project showcase here are selected for a specific reason so instead

of the typical project that focused on updates and revisions to an existing standard most or I say almost all of these projects here are efforts that have the potential to transition the agency towards standards that are more modern and interoperable the first project listed here is the SPL file project the goal of this project is to move Caesar away from the Aging SPL submission to the

fire standard as fire is more modern exchange standard that is also much more interoperable um next we have the pqcmc standardization project the goal is to identify and standardize data elements terminologies and data structures to enable automation of analyzes of pqcmc data to support more efficient regulatory reviews so far the project team has completed All Phase One development activities which includes about 190 data elements in

module three we also published a Federal Register notice last year and another one in May of this year notifying the public about these data elements and um and also their representation hl7 fire um next we have the pqs I'm sorry the the ibmp initiative and as many of you may already know idmp is a suite of five standards developed with an ISO and is an internationally

accepted framework to identify and describe medicinal products the goal here is to facilitate a conformance to this standard to better support Global standardization of products and substance identification and enable information exchange both regionally and across regions so we have been collaborating with EMA and who UMC for the past several years um through the global ibmp implementation work group we call it gitwick and as a result

this collaboration the Gateway conducted five pilot projects further investigate Solutions identify gaps and the ultimate goal here is just to support a more efficient Global implementation of idmp okay um so moving on to the next slide starting with um real world data standardization effort the goal of this project is to establish a program for reviewing applications using real world data real world evidence generated from Real

World data this project was launched to better understand the gaps between rwd and current accepted data standards at FDA and identify any opportunity to improve the usage of rwd for research and Regulatory submissions now I would add here a key objective of this standardization project is to determine the common EHR data elements and and the formatting that are required for structured data submission to the agency

which will allow us to develop a draft representation of the data structure using both cdisk sdtm and hl7 Fire next on the list we have studied data testing and evaluation project this is an ongoing effort to test new standards and update existing study data standards to determine and establish FDA support this is a part of our business as usual process to ensure that the existing standards

are up-to-date and the new standards are able to meet the agency's regulatory review needs last but not least we have the file transport format assessment this is another join Cedar sieber effort that evaluated the interim and long-term interoperable transport mechanism options for regulatory submissions which included SAS VA XML and Json we also explored approaches to address the limitations of SAS V5 to better understand the level

of efforts that are required for transitioning to a more modern and interoperable standard so um while the project was completed last year with Json coming out as the recommended standard however this is um this is very much a preliminary assessment and much more work is still going to be needed to fully understand the internal and external impacts of a such a transition before any formal decisions

can be made it moving on to the next slide so data standards policy this is goal two um so while there are certainly you know considerable benefits to have data um standards but that wouldn't be of any use if those standards are not implemented right and policy as I've mentioned before is really the business implementation of regulatory data standards it is the Cornerstone by which we

establish and communicate the agency's submission requirements or recommendations so starting with the e-study data guidance that implements the electronic submission requirement of section 745a of the fdnc act for study data contained in various applications the requirements of e-study data guidance were further clarified and reinforced through the two documents below listed below the data standards catalog which specifies the data standards formats and terminologies that are required

or supported for electronic submissions to the agency and then there's the study data technical conformance guy it provides the specifications recommendations and general considerations on how to submit standardized study data using FDA supported data standards located in the FDA data standards catalog so at the bottom two examples of the many policy documents that were either published or updated in the last couple years we have published

the draft rwd guidance back in 2021 and we have recently published a final guidance for idmp I believe back in March of this year so moving on to go three Information Management really consists of a portfolio of project that aims to improve how we manage that internally you know starting with data governance effort to improve how we manage the availability usability and integrity of regulatory review

data and also to refine the agency's internal standards and policies for data usage and change controls data control boards are our governance bodies that focus on specific data domains such as product data or facility data and it works to improve the review process by ensuring that consistent data definitions standards and control terminologies are being used there is also the common product data dictionary effort this project

is still in this early planning phase but the goal is to establish and Implement a framework through which Caesar system can more effectively share product and substance information through common data elements now moving on to go four this goal focused on improving transparency and stakeholder engagement and it really boils down to better and more frequent Communications so in this area we have concentrated our efforts in

collaborative standards development through sdo engagement capturing stakeholder input through public comments um we have our regular you know the regular Publications reporting on the data standard programs project status and also maintaining timely updates to our Project Specific web pages so now we have a better understanding of the data standards program strategic goals our key initiatives and um specifically what are the objectives I'm sorry the objectives

that each project is looking to accomplish so how does all this come together within the context of the regulatory review life cycle and um this diagram attempts to explain just that right by mapping the four strategic goals to the agency's regulatory review life cycle and um each and and the area that each goal was designed to support so starting with Goal one it focuses on collaboration

with um the standard development organizations the sdos to improve data standards and or develop new standards then moving on to goal two these standards are then implemented through our policies which provides industry with guidance to ensure conformance to the require or supported data standards so that they have Clarity on how to submit the SE data to the agency now once these submissions are received by the

agency data Within These submissions are then um unpacked and processed by our internal systems and tools to support regulatory review activities and this is where go three efficient information management comes in as it helps us to maintain and prove oversight of the review data as well as any Associated workflow processes right and doing this process we would identify any data needs and opportunities to further improve

data standardization and those requirements that we identify would result in either changes to policy or establishment of of new projects so um these these policies changes or new initiatives that I just mentioned they connect very nicely with go4 at the bottom which is when we and when we communicate to the external stakeholders on Project progress and solicit public feedback or input and over the years Cedar

and sieber have been actively participating in a wide range of collaboration opportunities with the industry sdos and with other regulators and and with that this wraps up the first portion of this presentation which I hopefully was able to provide you with a general understanding of the some of the key components of Cedar and sieber's data standards program and how are how work is um it's able

to fit within the context of the larger regulatory review life cycle um as for the second part of my presentation I will highlight a couple key initiatives that are core to our data standards modernization efforts starting with the SPL fire project so SPL which stands for structure product labeling it was a data standard that was developed based on hl7v3 the original Focus was on the exchange

of drug product information specifically for the drunk product label and that includes everything that you see on the label and the package insert here on the screen and the package answer would you know to provide you with more information on things like active ingredient purpose of the drug dosage form side effects and a number of other details that are specific to the drug problem so SPL

was able to provide some structure to the data submissions and that allowed data to be a bit more computable and enabled some automation of the downstream review processes and over time we have added additional submissions to the SPL standard and um many of those are not necessarily labeling the other use cases right but since the SPL standard was already in place it kind of became the

go-to option for a while as our needs for standardization gradually expanded to include these additional use cases that you see on the right here and the reason why we are now moving away from SPL to fire is mainly because support for hl7v3 has been discontinued and at the same time D5 standard has proven to be a much simpler and easier standard to implement so over the

years it has been widely adopted by the healthcare industry so it kind of became the preferred standard for exchanging Healthcare data and not to mention that the available pool of talent that can provide technical support for the V3 Bay system is quite limited and this trend will only continue going forward in the future um so a few years back the agency started to explore the potential

transition from SPL to fire our scope included evaluations of all SPL use cases at FDA with a goal of fully replicating the functions of SPF and fire and then determine the fire representations as needed to support each use cases we're also working to ensure that the validation methods for fire messages are consistent with those being used for splv3 and another objective of this project is to

develop a fire implementation guide and that is still very much underway as we speak we have also built and tested a proof of process system that is able to demonstrate the ability to perform lossless conversions of our test data from V3 to the fire standard and vice versa so in terms of progress to date the draft fire IG is still in development the extent of use

cases that it is currently able to support only includes the national NDC labeler Co registering and updating establishment information and uh and a couple other foundational use cases as listed here now our goal is to continue the development of support for additional SPL use cases one point I would also note here is that as the project is continuing to make progress we are planning to engage

industry for their participation in a pilot for SPL submissions in fire um schedule wise this is still very much notional at this point but it is something that we think could happen before the end of 2024. next moving on to pqcmc and the current use case for pqcmc data this pharmaceutical industry they prepare applications or some kind of amendments to the application and then submits them

to yet the FDA and these submission data are stored in the electronic common technical document also known as the EC B structure the ectd um you can see the middle has five modules and the focus of pqcmc project is everything that goes into module three where the bulk of the pqcmc data resides as and as well as module 2.3 memory information so what's being included in

the standardization skill for pqcmc and that includes comprehensive definition of every drug product and every substance within a product the recipes for making batches of the drug product things like quality control tests acceptance criteria and testing results for products and ingredients and batches as well as details on packaging and container another project scope is um it includes a detailed description of the manufacturing process for drug

substance and Drug product specifically how does a manufacturer put everything together to create the products and that would include all the steps mechanisms machines processes involved and um also because oftentimes a product can be produced at multiple facilities we would need to understand what steps are being taken at which facility so moving on um the reason why we are working now we're working to standardize pqcmc

data because there are currently no standards for module three and that means that data we currently receive are not standardized nor are they structured and in the end all we are getting is just a bunch of PDF files and not only does that create a significant amount of manual work for the sponsor to generate these electronic paper files but it also creates a huge burden for

FDA since we need to manually prepare the information before any analyzes or reports can be done so this is just an overall extremely time consuming activity for everybody involved CMC project was formalized to tackle these challenges that I've just mentioned the project once completed will provide a data standard to support the submission of module 3 information so that data is consistent and computable and there are

also a number of obvious benefits in that the sponsors will have much more clear expectations for data format that they can check themselves before submitting to the agency on the FDA side we can expect much more consistent data format and values right and with computable data it can further automate analysis of activities which will lead to faster reviews and then we'll be also able to validate

content and data quality as we receive the submissions um and last but not least I mean there's also the shared benefit of sponsors submitting information only once and this data can be reused for multiple purposes and this has the potential to save a lot of time on both sides by reducing the amount of redundant information that is often needed for unstructured PDF submissions so in terms

of our approach to fire development and the text on the left side has been mentioned in the previous slide where I went over the project scope and the only difference here is that I've separated a mobile development phases with the first phase focusing on drug product and substance definition things like quality control tests packaging details and and so on and so forth and these are essentially

the foundational concept that we need to develop before we can proceed to phase two data elements which has to has its focus on manufacturing process and moving to the right as far as progress goes phase one structuring is complete and we are currently working on phase two data elements the most recent draft of the data elements and terminologies was announced through a Federal Register notice that

was published for comments last month we have also completed our draft implementation guide for phase one and with it being a draft and while we are still working on phase two data elements we are expecting further changes to the IG based on public comments and lastly this is something that's still being planted but we are looking to expand submission testing of pqcmc file messages to include

sponsor participation right now that is uh tentatively being planted for sometime in 2025. and that wraps up the overview of pqcmc moving on to ibmp so idmp is a collection of five ISO standards they are used together to uniquely identify medicinal pharmaceutical products and substance so this set of ISO standards is um it is important as it establish a framework for organizations to have a consistent

approach to Define substance and medicinal products and with standardized representation of substance dosage form and strength information this allows us to generate a pharmaceutical product identifier or what we call Global phpib which will enable the linking of the same or similar products across different regions there are two main benefits of the global idmp and they are to improve drug safety pharmacovigilance and also Medicaid drug shortage

since idmp allows us to establish the connection between similar products across different regions through the use of PHP ID so if there are Adverse Events from a product in a particular region we will know that the same or similar product will probably cause similar Adverse Events in other regions so with this information we can come up with approaches and advance to better address these anticipated risks

of Adverse Events and as for product shortage we can use this information to identify similar products that may help to mitigate the the risk of a shortage in a more timely manner and over the years FDA staff have always actively participated in the development and implementation of the iso idmp standard for medicinal product identification substance identification the development of those standards all had considerable FDA involvement

and which is why the final published standards are in alignment with the agency's requirement and are consistent with how we assign the National Drug code which conforms to the iso 11615 and the assignment of the unique ingredient identified that conforms with ISO 11238 as for unit of measure we have been using ucom which conforms to ISO 11240 and finally as FDA some SPL dosage form largely

conforms to ISO 11239 the grayed out box at the bottom is PHP ID which is we have not yet implemented but we are actively working with global stakeholders to implement this so um so that we can have a more harmonized approach for generating PHP ID so that we can link the same or similar products across different regions of the world back in 2021 we started working

on a guidance for idmp titled identification of medicinal products implementation and use this is a drawing sieber Cedar guidance and it was published very recently um just two months ago back in March and it explained fda's position and progress on aligning the agency standards to The idmp Standard the guidance also highlighted fda's commitment to continue our collaboration with International stakeholders to resolve any roadblocks so that

we are able to ultimately establish a framework for the global implementation idmp and the maintenance of Global identifiers and that wraps up the project highlights now getting to the final slide here I think it's safe to say that moving forward the data standards program is to continue to focus on the exploration and Adoption of modern consensus-based standards standards that are more flexible efficient and interoperable we

will also continue to improve the exchange of data between our agency and without stakeholders and clearly this would entail developing you know adopting new tech new tools or technologies that will make it easier for sponsors to submit data to FDA another Focus evident by our efforts such as the idmp project Caesar and sieber are actively working on and will continue to improve drug safety and pharmacovigilance

through harmonization initiatives with other regulators and lastly I would mention that for anyone who is interested to learn more about the data standards program or any of the projects mentioned today please go through the FDA website and look up one of our several data standards resources web pages for more thank you very much hello my name is Dr Andrew Potter and I'm a the score viewer

in the division of Biometrics one in Cedar's office of biostatistics and today I'm going to talk to you about a reviewer's perspective on data collected by wearable digital Health technology in clinical trials today's learning objectives include describing a DHT and the data that it collects who do we call who contacted FDA with DHT questions list the types of data sets that are generated in the process

of gathering data with a DHT and converting it into an endpoint for a clinical trial and to really gain an understanding of the importance of DHT data so we've been talking about digital Health technology or dhts what is a DHT why are we really interested in this so according to the best glossary available online the link on this slide ADHD is a system that uses Computing

platforms connectivity softwares and sensors for healthcare or related uses dhts have many broad uses we could use them as a medical product we could incorporate it into a medical product for example there could be a medical product that includes a drug and a device that tracks whether the drug was taken and provides information to the patient or the patient in their health care provider about how

that have they taken the drug and is are they consistently doing it we can also use them to both develop and Study Medical Products this will be our Focus for the rest of today's talk or we can also have it as used as a companion or an adjunct to a medical product for example we could develop a machine learning algorithm that allows us to better select

subjects for inclusion in a clinical study so what are some specific uses of dhts as we start to think about them in clinical studies first we can start to think of it as a DHT can instead of just capturing single time point they could generate a rich comprehensive set of data about how patients are feeling and functioning for example if we consider physical activity we may

want to know how a patient is functioning every day not just on days when we have them for Clinic visit it may minimize barriers to actually obtaining this this patient experience data so if we think about again with the physical activity data instead of having to bring a subject in for a clinic visit maybe every four weeks to get some information about their physical functioning we

could provide them with a wearable activity monitor and have that activity monitor capture data about about the patient's daily daily physical function it then gets recorded and transmitted back to the clinical study site it may also allow patients better access about their health so now that we have this comprehensive recording all for patients functioning can we then provide that information to the patient in order for

them to learn more about their health and potentially how to how to improve it or what the goals of the trial were and finally we hope that this can assess study endpoints that are actually meaningful to patients and throughout this talk while we are talking about data you know the technical aspects always remember that endpoints must be meaningful to patients and we have to think through

how do we take these very rich data sources from the HTS and transform them in a way that is capturing a concept as meaningful to Patient patients now we go from now what are some specific examples of DHT data or endpoints that can actually be captured by by these sensors well if we're looking at physical activity we can see that currently we you know have a

snapshot of six minute walk distance and instead we can now start to think of well what about average steps per day in diabetes our current endpoint is hba1c which captures information about a patient's blood glucose averaged over multiple months and instead we could now use a continuous glucose monitor to measure blood glucose levels throughout a day this could then give a much richer data that captures

something more something new about these patients glucose control we can also think about the Duty due date dhts improve our ability to detect rare events such as potentially seizures and we could go from a situation where we would have a seizure diary where a subject will try to report how many seizures they had in a month to some type of wearable EEG that could capture that

data continuously and maybe also capture seizures that may have been not detected by a sub by a subject or we're not properly reported and then also can dhts allow us to capture data from patients they can't report for example scratching an infants with atopic dermatitis and then there may be also new types of measurements that we have yet to think of that maybe machine learning AI

other types of signal extraction can allow us to find potentially such as an activity monitor measuring gate and this could be used to predict Falls so now that we see a bit of the potential of what phds can do how do we think about interacting with FDA on these dhts to really get good development going forward so First Cedar has now released a framework for the

use of dhts in drug and biologic product development here's our nice cover page and the goal of this framework is this is to promote regulatory consistency convene public workshops discuss some demonstration projects that will be coming out and how we're going to identify these as well as steps on issuing dhc-related guidances and enhancing it capacities another very useful resource is our DHT for drug development website

we can see and here is the link to it or you could also search FDA digital Health Technologies for drug development now to also get a better understanding of when DHT submissions are coming in both during the inds and NDA stage we've updated our form 1571 for inds and form 356h for ndas now for an IND the 1571 form has a question 12b that asks does

this submission contain digital Health technology or proposal to collect DHT data yes or no and this will allow us to both track if yes is checked it will allow us to both rack the number of DHC submissions coming in and also understand hey this DH this submissions come in for the DHT we better you know internally put in motion some gears so we can hope so

we can get good comments back to everyone then for the 356h when you've submitted a new drug or biologic application question 25 we also ask does this submission contain digital Health technology data and this is again to track the uptick in these type of submissions as well as have a way to start to flag submissions for in-depth review also there's a draft FDA guidance on using

digital Health Technologies for remote data acquisition draft guidance is now it was public is now about a year and a half old and published in December 2021. this guidance provides some recommendations on how do we actually use the HTS and clinical investigation to hopefully accelerate efficient medical product development and to build off of some other FDA initiatives now we've decided that we're going to use a

DHT on a product to develop a product now how do we get who do we engage with and when to engage well we want to engage as early as possible and we want to think about engaging with the FDA center that is going to actually regulate the medical product under investigation if our medical product is a drug or biologic so for example you're developing an a

new drug for insomnia and you want to both say does sleep improve and there's also next day function improve and you've said well what's the use of DHT that measures a subjects activity and we think that this could both capture something about sleep and next day function in that case since it is a new drug product that we're looking for you would discuss this with with

cedar if it were by Logic it would be discussed with sieber however if this new product was a sleep aid that you downloaded onto your phone now this would be a medical device and you would need to talk to cdrh and their Q sub program now that we know about how to contact F talk to FDA who to hold discussion with an FDA to get a

better understanding of the DHT what's going to be required for it how it's going to be submitted what are some considerations that we should take undertake as we are developing this DHD well first DHT should be fit for purpose when using a clinical investigation fifth for purpose is a conclusion that the level of validation associated with the DHT is sufficient to support its purported use in

the clinical investigation aspects to consider when we're determining if ADHD is fit for purpose is we need to think about what is the clinical event or characteristic of interest that we're going to actually capture with the DHT what evidence do we have that this DHT can actually measure this clinical event what's the population of Interest what's its age its technical aptitude it's education level maybe socioeconomic

status to determine you know do they have access to to Wi-Fi you know if we're going to have a DHT that reports remotely and we're going to want to know how what is the DHT and how does it work for example what is its physical properties it's power needs it's alerts other things that you would often think of if you're going to go in and buy

a Fitbit so you may want to when you we look through a Fitbit if I'm buying a new one I might say well is it big and heavy or is it kind of small and unobtrusive does it have good battery life you know does it last for two weeks before between charges or is it only do I have to charge it every day we're going to

need to consider these as we go into a clinical investigation and this applies to every time we're thinking of using a DHT if participant brings their own if the study sponsor provides them now how do we get to determine being able to determine if a DHT is fit for purpose well we have to look into doing both verification and validation verification is referring refers to do

we actually measure some type of physical or chemical parameter correctly so is the acceleration measured accurately and precisely these blood glucose measured accurately accurately and precisely and this is usually this is usually can be done on a bench this can be done in patients this may be done as part of you know the developing the DHT by the original manufacturer and could be included in Spec

sheets then once we actually have verified that the DHT is providing reasonably accurate and precise measurements we have to go into validate this that step is going to say okay now that we've gone in we have a DHT that we have verification data we now want to go into a clinical population and assess is the clinical inventor characteristic accurately and you know accurately and precisely or

reasonably captured by this DHT this could include determining for a activity monitor is a staff accurately captured in that population or it could be is you know the time spent for in a certain amount of physical above a certain amount of physical activity accurately assessed or it could actually potentially be both this will all this will depend a lot on what is the clinical population what

is the clinical event of interest and oftentimes how the DHT works so figuring out a good validation is very important to come in discuss with FDA early about what your aims are and get agreement on what type of evidence is going to be needed for validation so now we have a valid verify and validated DHT we're going to go into a clinical trial and we're going

to collect data and now what do we do with all this data that's coming in because one of the promises of dhts is continuous data recording that will find new and interesting events and better characterize patients during clinical study so how do how is this data captured how do we start to go from you know potentially millions of data points on a subject into some understandable

you know ideally endpoint but even just some understandable summary of what a patient is feeling maybe during it during a day or how they're functioning every hour during that day so to get some idea of how these data can how these data flow let's consider move a motivating example of movement data from acceleration sensors these acceleration sensors are often used in activity monitors to say how

much is someone moving and here we've got three acceleration traces that cover about eight minutes or a little over eight minutes of data and we have acceleration in G's on the y-axis and time on the x-axis and we have three different acceleration traces we've got the vertical Direction and in blue media lateral in red and dorsiventral in brain and we can see that we have a

lot of data it Jiggles around and this is probably sampled maybe 100 times a second what do we do with this well we can take this data and convert it from acceleration into something called an activity count an activity count is a summary of how much acceleration is happening in a fixed period of time that is believed to be is related to the amount of activity

that that per that the person is doing during that time frame in this example we have seven days of data from a subject from the nhanes data set and Haynes is a national health survey conducted by CDC and at times and Haynes has actually issued activity monitors to participants in order to capture their daily activity here we see minute blocks ranging from Midnight to the next

in particular if we're looking at circadian variation or other kind of diurnal diurnal activity alternatively we could consider a situation where we're actually interested in how much activity someone's doing above a certain kind of threshold so oftentimes this could be maybe moderate or vigorous physical activity or light activity or exercise and a way to start to visualize how do we go from these activity traces into

activity thresholds is to plot the data ranging from time of least activity at a time of most activity and now we can get well in this region this subject was exercise having at least moderate exercise in this anything above this line is the subject has at least light exercise and now we can kind of see that we've transformed from acceleration data to activity counts organized by

time of day into some type of daily summary of those activity counts that describes a feature of how much activity is going on in each minute and these are like I said this is an example subject for men Haynes so now that we kind of have a kind of a general idea of a little bit of the data flow we can now think of this breaking

this into four data sets for the data we have a data set that comes in that's high frequency data is minimally processed and could be sampled at 100 Hertz 30 Hertz some high frequency as a first step we want to take this from potential acceleration into some measure of activity be it activity count be it step and we may decide that you know the minimal type

time frame that that really matters for us in maybe a minute it's been taken a lot in the literature and is you know a reasonably small amount of time we say a minute is our epic length and we create another data set that has epic epic level data that data is going to be taken every minute and for every subject for every day that they've been

wearing the accelerometer them we can go from this minute data into some type of summary data the summary data could be amount of time spent above a certain activity level per day then we go from summary data into analysis data the difference between summary data and Analysis data is analysis data is we're now ready to conduct our final statistical analysis these data this data set should

be ready to be plugged into the final analysis model it may require you know additional transformation from the summary data such as going from daily time spent moderate or higher at physical activity to some type of weekly average time and there may be other additional pieces of data that get drawn in from other data sources into the analysis data finally there is an sdtm domain called

device metadata which in this case device would refer to the type of data that's collected not whether or not is a regulated medical device and this would capture important information about the dhtus such as what's the ID number of the DHT are there any you know error error faults in the DHT what's battery life Etc and this is very useful data and some of this may

need to be linked into the summary data set at the moment FDA considers that we're going to always most likely always need the summary data from sdt and sdtm format the analysis data and device metadata other data sets are going to be very useful in scientifically looking at this and may be needed for fda's review now we can probably get some idea that these data sets

are quite large so epic level data represents these represented in sdtm and in some type of aggregation of the DHT of the DHT data in many cases although sometimes it may not and we can see for one person for one day using a one minute epic length there's 1440 data points for for each day of patient where's the device or if we look at a CGM

DHT that they there is these are captured every five minutes with which leads to a little under 300 Apex still quite large however summary data is going to also be an sdtm and it represents a summarization from the Epic Level data and is often thought we can think of this as a bridge between the Epic Level data and the analysis data set as said before analysis

data contains a DHT analysis ready DHT data and standardized using atom finally we want to think about can we actually Trace every step from in in this data flow so we've got potentially three or four data sets we want to make sure if we start with an analysis data set we can say well this weekly average physical activity can be traced back to its daily constituents

which then can be traced back to its minute constituents this is important to understand do we have reliable endpoints and to support fda's review and importantly sponsors should get agreement on which data needs to be submitted to the NDA in the original application before the submission pre-enda meeting is a great place for this or potentially earlier if if appropriate finally let's briefly before we leave data

let's briefly discuss data standards unfortunately there are no current broad standards for for these data they can have different meanings with the same name and which leads to some difficulties with generalizing results but this is a great place for all of us to collaborate and start to put to pull together data standards that will work not only for patients but sponsors and Regulators as well where

does this data go so we have all of this data where does it go there's plenty of clinical uses for this to really capture new and for hopefully new information on how patients feel their function and you know potentially capture continuous measurements I'm a statistician so statistical uses are near and dear to my heart and I'm kind of one of the things I'm really interested in

is how do we actually take these high frequency data or Epic Level data and efficiently capture features that relate to important concepts of interest to patients do we use clinical and patient knowledge do we use machine learning are there other tools that we haven't yet discovered haven't yet figured out this leads to also analysis more frequent outcomes and then our favorite or least favorite issue is

how do we address missing data and then there's also potential for lots of work on how do we do more efficient validation of dhts now to our first challenge question submarine analysis data sets must be small Excel files human readable or traceable to the HT measurements the answer is D traceable to the HT measurements challenge question two which data sets should be submitted to FDI a

high frequency minimally processed data sets and Analysis data sets B device metadata and summary data sets C device metadata summary analysis data sets and others as needed or the Epic Level and Analysis data sets the answer is C in summary dhts have the great potential to capture novel and important endpoints we need to think about how do we organize these large volumes of data into related

data sets for both ease of analysis and also ease of tracing traceability and we need to make sure these data sets are traceable and we can trace the endpoints back to where they originated thank you for your time and during the question and answer session I will be happy to capture take any questions and in closing dhcs have the potential to gather important data on a

patient's disease but we need to have a plan how to handle the volume of data and make it interpretable to statisticians clinicians and most importantly patients thank you and have a great rest of your day and an enjoyable conference hello all my name is Marianne slack I'm the director for office of strategic programs in Cedar now you've just heard from my colleague Andrew about the use

and handling of DHT generated data from the reviewer's perspective and what I'm going to talk about is the other side of the coin how to support this work from a technical perspective and it's reflected in the Paducah 7 goals for dhts the technical part of them we do have a few learning objectives first is to be able to identify key actions that Cedar's taking to support

the use of DHT generated data and Drug development next is to be able to recognize the types of DHT data relevant to Applications and third is to understand the value and the challenges of DHT high frequency or HF data the performance goals that I'm going to talk about are the ones that are specific to the use of DHT so they're specifically related to that the first

is the ability to be able to track and identify applications and submissions that contain or are anticipated to contain DHT generated data this will help us to determine Trends issues where to focus support Etc and we committed to establish a secure Cloud technology that would enable FDA to be able to handle large volumes of data that the DHT generated data can be so that we could

receive aggregate store and process that data next will be a pilot a cloud-based pilot that is a means to support the submission and review of DHT generated data and I'll just point out that that is a very broad scope and one that we anticipate doing not one but a number of Pilots or increments to a pilot as we acquire knowledge and experience this can help both

regulated industry as well as FDA to really get a handle on data that's generated from particular dhts for particular purposes and all of the mechanics around how to receive that how to handle static versus continuous data Etc and then finally FDA will work to enhance recommend and Implement standards that reduce the handling necessary to make data analyzable I am certain that it comes as no surprise

to anyone here that standards enable one to um to to be more consistent in the receipt and the use and have more reliability or um confidence in the reliability of data if it's following standards and so this makes good sense and um we will continue to March forward with that too now in March of this year we did in fact uh finish up we updated the

1571 and the 356 application H application submission forms we updated our tracking systems to identify when DHT generated data has been or is anticipated to be received for an application we created dashboard views to support reviewers in identifying these applications as well as being able to ultimately do some trending and evaluation it's only been in place for a couple of months but since these enhancements went

in since uh in March we've received 30 applications indicating DHT generated data and most of them are inds investigative new drugs but we do have um and as and ndas and Blas so runs the gamut of the types of applications that we receive before we you know after just a couple of months we've identified some additional enhancements and where we want to go with the the

next version and refinements so this is kind of the beginning of this story now we already have a secure Cloud technology here at FDA um in fact we have a significant installed base of systems and capabilities in the cloud our challenge at present is getting it in the door so to speak while the ESG doesn't have a technical limit on size in Practical terms we can't

receive a very large data set because of the time it takes to transmit our current practical limit our current constraint is 100 gigabytes and the high frequency DHT data can be so much larger than that and actually I know that this is about dhts but that high frequency data is not the only data that can be so much larger your real world data your genomics data

these these are very large data sets now this constraint will be significantly reduced when the ESG modernization is completed and that's going to be great and and we'll talk about that in just a moment and I think that you have already heard or you will be hearing more about that in much more detail the thing is that receiving huge data sets of some some huge data

sets may be something we need to look at differently for the future it may not be the most appropriate thing to receive it through the Gateway but instead perhaps access it where it resides and we'll talk about this with the DHT HF data this needs to be worked through though there's a lot of policy there is a lot of considerations around that so the Enterprise submissions

Gateway the ESG modernization is already well underway we have a nice road map here that takes us through fy25 we've made significant progress this is office of digital transformation particularly oimt has made significant progress you can see that the planning has been done it's in place a proof of concept is underway and the technical and the identity and credentials access management integration is planned to begin

later this fiscal year version one of the ESG is scheduled for fy24 and it will include opportunities for testing with our regulated industry Partners the full up releases most all of the releases are scheduled to be done by the end of fy25 and when the modernization is fully complete challenges such as the Practical ability to submit large data sets should be by and large a thing

of the past with the exceptions that I was talking about but those won't be ability so much as decision um forethought one thing I want to point out here is that in the green box here you can see it says update ESG next-gen website with information Etc that website is coming soon it's not quite ready yet but when a draft is ready it'll be sent out

to the stakeholders to get their input and feedback before it's implemented and that'll be sometime in the summer so coming soon and that brings us to our first challenge question so for everybody out there what is the current limit to submission size through the ESG is it 100 megabits is it 100 gigs is it 100 dollars or is it none of the above wait a moment

give you a minute to think and the answer is 100 gigabytes now I know that I said there is not a technical limit but we do have a practical limit and it is actually our policy to not bring things in that are more than 100 gigabytes because of the increased the length of time and the increased risk of some kind of interruption causing it to fail

so now on to DHT data sets and you heard from Andrew about the different types of data and how they might be important in regulatory review I'm going to do a little bit of a recap in my own words because I think that it's we'll be talking more about HF data but all of this is important it's good context so the high frequency minimally processed data

is the DHT generated data it's uh it's it's it's huge volume and from that the Epic Level data is generated and Epic Level data is the it's the meaningful level of data for analysis it averages it takes chunks of the high frequency data specified increments and averages to provide a measurement for that increment for instance epic data for one minute or one minute epic data for

something that's captured every second would give you a one minute average for every 60 seconds of that high frequency data the Epic can be defined and it is defined and it's defined based on um the the DHT and the type of data that is generating and the purpose that it's being generated for the raw data that HF data is important to help identify what the Epic

should be and to validate it and then you get on to summary data summary data provides a summary statistics analysis data is the data that's constructed for analysis from the Epic data device metadata is also important it provides the information that you need to know how to read this data what was being captured in what form is it in what order is it Etc now that

high frequency data can be received as complete data sets or it can be continuous data that continues to build on the data set and build out the data set Epic Level data I've already said the HF data is huge Epic Level data is less huge but it can still be very large and all of these different types of data are submitted as part of an application

except for the HF data so what about HF data then versus those other types of DHT data well I just said HF data is not required for submission but it does offer valuable insights or it can offer valuable insights because of its size it may remain impractical to transmit to FDA and if it is transmitted for multiple purposes first off because that data the need is

expected to become significantly reduced as FDA advances its understanding about that that particular DHT data submission type um and so there's this huge bolus of data that would be submitted that FDA would then have to manage as a record of records and add to the administrative overhead that may not have the value that is enough to require it to to come in we may not be

making decisions based on that um what we received today also I should say is generally in the form of tabular data but other forms are also certainly possible like waveforms and videos and they can be even larger so if we don't receive it as part of a submission but it can offer the important insight to both sponsors and Regulators then how do we take advantage good

question but before we come up to an answer which is our pilot we're going to go to another challenge question and that is DHT HF data answer the question DHT HF data is not required for submission the largest of the types of DHT data digitized data that can offer valuable insights all of the above or none of the above so let me just give you a

few seconds to think that over and the answer is all of the above okay our first pilot that brings us to our pilot our DHT pilot that I was referencing earlier our first pilot will be in the area of Psychiatry the therapeutic area it'll be a population of a rather small population of about 2 000 adolescents and young adults who are at risk for developing schizophrenia

the study design is a prospective non-interventional Interventional cohort study collected over two years the data sources are compiled from its schizophrenia data compiled from multiple sources as part of a public-private partnership between FDA and multiple other public and private organizations and it was generated through smartphones wearable activity monitors Etc various dhts the analytic platform will be Precision FDA which is a secure high performance Computing platform

designed for collaborative data analytics between FDA and external Partners so perfect for the for the job and we're expecting that this will be getting uh HF and epic data and we're expecting that the volume of this data is going to be on the order of several terabytes so plenty big but not massive now everything is de-identified of course and and this is not intended as to

uh something to contribute to a marketing application so that's that sets the scene that's our our study and then our objectives behind this study behind receiving and placing this data and evaluating it is multi-fold or are multi-fold I should say first is to enhance of course our ability to receive validate clean and analyze external data on a third-party platform so not bringing it in behind the

firewall and then doing it but outside of the submission process we'll explore architectural and business process considerations and for receiving these large externally generated HF data sets that aren't required for regulatory submissions and also the Epic data sets and then we'll explore methodological considerations for informing that future regulatory guidance for submitting this kind of DHT generated data now the benefits behind all of this first off

we think this pre-submission investigation might mitigate ESG bandwidth constraints in some areas through more focused submission requirements it gives us the ability to you know to get down to what is what really should be coming in and how it should be coming in it'll give sponsors and Regulators the chance to access data in real time enabling real-time sampling and Analysis of this data pre-submission and it'll

support sponsors and regulator interaction about the data this is a potential for other data intensive use cases as well such as real world data but also similar use cases in different therapeutic areas we're actually expecting as we really dive into this to identify more and more use use cases as we progress this pilot and when I say we I don't mean just FDA just cedar or

sieber I mean our our regulated regulated Partners on the other side too we we think that this is going to open up opportunities in multiple areas as we learn more and more thing I want to just point out in this first use case this first version of this pilot we're using chunks of data single chunks of data that are being dropped onto the Precision FDA space

but future use cases may include continuously updated data sets so so rolling data and that'll give sponsors and Regulators an opportunity to evaluate methods and challenges for device data exchange so maybe the next phase pretty exciting and that brings me to a third challenge question a little bit of a gimme I think so where is the DHT pilot to be conducted is it the Amazon gov

cloud Microsoft azure Precision FDA or Joe's Garage I'll give you just a few seconds to think about it and I'm sure everybody got this one it's Precision FDA so with that I'm going to leave you with just a quick closing thought it's kind of an obvious one dhts it's clear dhts can and do add enormous value to drug development and the FDA we're fully supportive of

the use of DHT generated data for this purpose it there's we've made a lot of progress but there's plenty more to do there's there's more progress there's more learning there's more maturing to do so this is really just the beginning it's exciting times and I thank you for your time thank you all for the great presentations we'll now move into our final q a panel of

the day if you haven't had a chance to enter your questions into the Q a chat pod please do so now we'll answer as many questions as time allows we have some questions our first group of questions will be directed to Ray Wang and here is the first question is pqcmc intended for ID applications or only marketing applications ndas and Blas AMC could be used to

support the investigational drug safety and efficacy by demonstrating it was manufactured in a consistent Manner and that it meets the necessary quality standards right so um the typical module three information like product composition manufacturing process and quality uh control procedures would be needed to make that assessment so so the short answer is yes in addition to um to just the NDA and bla applications PMC pqcmc

is also intended for inds and that is really because these data elements still fought was in the scope of ectd module 3. all right thank you thank you for responding to that question Mr Wang we do have a few more questions that came in for you and here's the next question for the PQ CMC project since it's requiring the submission of data in the fhir format

how does FDA Cedar plan to transition to the new standard while ensuring that sponsors have sufficient time to prepare for this change thanks for the question um so while we haven't made any decisions on how exactly to transition to the fire standard because the development of the data element is still underway and not not all of them have been validated yet but I would imagine there

will likely be a dual submission approach right meaning that you can submit in either PDF uh which is the current approach or in the the fire format before we fully transition to the fire requirement um and there really isn't a set time frame for this transition at this time but I would imagine it will probably take a couple of years at least and during this time

it should give sponsors um enough time to make the necessary changes to their data collection processes systems and tools and I think this will also give third party vendors more time to incorporate the the fire standard into their portfolio of services so given this period of transition you know the goal again is to provide industry with enough time to fully adopt the fire standards for people

to CMC submissions and along the way we'll continue to publish updates to the fire data elements on our pqcmc webpage you can also you're also welcome to submit any comments on those data elements to our docket on the regulations.gov website and um another upcoming activity I think we'll need to undertake is to conduct a detailed assessment of all the guidances impacted by this transition right and

just to make sure that they're up to date with the fire submission requirements um so so yes there will certainly be more resources down the pipe on how to comply with and um and how to submit the pqcmc data in fire thanks thank you for responding to that question we do have one more question for Mr Wang and here's the question you mentioned the file transport

format assessment project could you speak a bit more to that particularly why such an effort is needed and what do you foresee as the next steps uh that's a great question um so I think early conversations on this project started a couple years back in initially it was because we received a number of comments on how SAS transport B5 is really outdated it has quite a

bit of limitations as many of you may already know in terms of things like variable name and length and difficulties was linking due to v5's tabular structure uh the thought at the time was that you know given the existing options out there that it may be a relative relatively easier effort to transition to SAS transport VA and then we should also at least take a more

serious look at other standards like XML and Json so we eventually kicked off a a project to to do just that right to better understand the implications of the of a potential transition to these candidate standards that I've just mentioned um so as a part of the assessment you know we looked at the benefit that each candidate standard had over SAS transport V5 and that really

shouldn't be surprised to anyone you know all the all of the candidate standards had quite a bit of advantages over V5 like being able to resolve the character limitations or just more interoperable and can more you know efficiently facilitate the exchange of data um and I would say another aspect that we looked at is how a potential transition to SAS transport ba XML or Json would

impact the agency's existing systems and and workflow processes initially we thought the existing systems and tools could accommodate and process SAS transport V5 I mean I'm sorry V8 files since we are already using B5 but that's not really the case right we as we learned that there are quite a bit of technical challenges involved uh so long story short you know the end result is that

the expected overall cost for adopting SAS transport VA or the cost of even staying with the current success transport V5 it's it's not really that much lower than adopting XML or Json um so I think I've mentioned this earlier in the presentation and that is Json was the standard that came out on top as the recommended format for transition um but you know we have made

no decision on this since this was a really a preliminary assessment and and we do need to have more planning and discussions before any formal decisions can be made and as far as um next steps I would say that we have taken an interest in see this um data set Json that was published earlier this year and we are exploring the potential for further collaboration on

testing the standards so more to come on this thanks thank you for responding to that group of questions moving on to our next panelist we've got some questions that came in for Andrew Potter and here's the first question for Dr Potter for form FDA 1571 when do we need to check DHT for example when submitting a new protocol that plans to collect Digital Data and every

time that protocol is emitted but with no change to the DHT so thank you that's that's a great question um the main so the main goal for for the the check box is to track both protocols that have DH digital data collection and then also submissions that have it so for for example the case that was provided where we have a protocol that plants collect Digital

Data but the change maybe is not related to the Digital Data maybe it relates to inclusion criteria that inclusion criteria in that case while the protocol would have dhts which we would know from from the check box when the protocols originally submitted we would font you know that specific submission would not be pertaining to dhts so in that case um at least at this stage this

may of course may change um I we I don't think we would need to actually check the check box however if the change to the protocol may be related to how the you know some of the operations at the sites about how the Digital Data the DHT would be provided to sites I would say that would be a change that relates to dhts and that check

that box should be checked ah thank you thank you for responding to that question moving on to the next question for Dr Potter a little bit of background first validation is typically applied to test data relative to a standard I understand that FDA typically considers clinical data or events as the reference for validation for example FDA has recognized hemoglobin A1c as a validated surrogate endpoint for

diabetes complications based on the dcct trial what is the FDA expectation for adequate validation of summary measures from continuous glucose monitors as surrogates for diabetes clinical events such as severe hypoglycemia thank you that that's a great question um so I will I'm not an expert in diabetes so I'll speak a little bit more generally but specifically I know that this is very very kind of a

very challenging um challenging question about how do we validate validate these markers you know such as clinical events such as severe hypoglycemia with continuous glucose monitors one of the challenges more generally in DHT validating the DHT derived endpoints is what is our reference standard so for you know we you know if we have you know we have you know some and some point we're going to

have some type of clinical event um it could be in diabetes it could be microvascular damage or microvascular damage and you know maybe more severe complications from that but and then you know we could go to an HP A1C however you know we've and an hba1c is measured so I'm remembering right for my diabetes colleagues who know this better than I do it is about three

months of data that go into that now we've gone from a time frame of three months into now a time frame of we could see potentially multiple events during a day and you know what's a good reference standard for for that how do we you know how do we validate it against maybe the the long-term clinical event or is do we need to start thinking a

little bit more broadly about what are validation standards for reference could it be something about how a patient's commenting all patients comments on the how they feel could it be something of a more of a short-term patient function could it also be um you know something as you know we've already have a validated surrogate so we can then you kind of get from our new clinical

event to our validated surrogate um I think it is a very interesting area of research and very active area of research and although I don't have any firm answers yet hopefully I've helped a little bit with saying hey this is this is something that we all we all need to really seriously consider and at FDA we're we're actively you know going through this in both review

process and also looking for research questions on this uh thank you thank you for responding to that question we have one more question for Dr Potter and it's the following question is a daily diary or an e diary considered DHT data so great question um simple answer is it would be considered an electronic Pro Data or an electronic COA data um because however it becomes a

little bit more complicated where an e diary say it's an e diary that is administered using a smartphone now that smartphone and you know in this case that could then be considered a DHT and it may fall kind of broadly Under the Umbrella of the DHT however FDA has oh sorry I need to remember properly there I think there is either guidances or kind of best

practices for epros that FDA has already has released there's also a lot in in the COA literature about epros what's needed for e-pros what are Best Practices there um and that would be probably the first place to look for anything for daily diary or e-diaries uh thank you thank you for responding to that question moving on to our next panelists we do have some more questions

that just came in for Mary Ann slack and here's the first question for Miss Slack is the FDA considering having reviewers access data in situ rather than receiving it through the Gateway hi thanks for that question um well at present we're unable to do so if it's part of a submission we need to receive it through the uh through the Gateway um as I was saying

though earlier during the presentation you know there are some things that that may not it may not be conducive to to bringing them in that way so we are investigating the potential for some data to be accessed differently we have to always consider of course the need for maintaining good records of all material that were used in coming to any conclusions on on any applications and

so I I think that we don't know yet but we are investigating it thank you for responding to that question we've got a couple more questions for Miss slack and here's the next question will there be a pilot for submitting and evaluating real world data and real world evidence I think there will I don't know when we hope so we're looking into this right now investigating

it right now we don't have a plan for one right now uh but it uh it stands to reason that we could do one thank you thank you for responding that question we've got a couple more questions from us like and here's the next question why would the HF data be less needed over time well I may ask Andrew to help a little bit with this

but as he had mentioned the earlier the high frequency data is it provides it provides all of the the finest granularity and it can be used to determine for instance what is the appropriate epic among other things it can be used if there is uh something some kind of an anomaly in what is uh you know what's received that that the reviewer may want to investigate

or the or the sponsor may want to investigate further um it could be valuable for um secondary purposes I know that this isn't you know this isn't part of the submission but it could be valuable for uh secondary purposes uh for for research for other other things but ultimately as we're um as as the as FDA is we get um more experience with the data with

the with Digital Data from particular dhts for specific endpoints um the eight The High Frequency data is it's it's less likely that we need to go back to the high frequency data unless there is some kind of an anomaly uh and and I would ask my colleague Andrew who works in this if he could uh if he has anything else he'd like to add to that

thank you Marianne um that's the captured my thinking about the need for high frequency data as well and how it will kind of change um change over time um and yeah as we get more more and more familiar with a specific type of endpoint will become more familiar with how you know if people say hey we're going to use you know a one-minute epic for physical

activity data we go okay yeah that's app we have a lot of familiarity with it that we're very comfortable with and we feel for for this disease area it's going to really capture you know the the relevant you know aspects of physical activity very well um but that may change you know if it's something where we're looking to make a big set of changes to how

how we go from high frequency data into you know into a physical activity data summary you know it may change and we may say yeah we're a lot less comfortable here we don't quite understand you know how does this capture all of the relevant features that physical activity and stuff so that it can kind of you know hopefully we'll get to a point where we start

going back and forth a little bit uh thank you Marianne and thanks for allowing me to uh add my thoughts as well thank you both for responding to that question we just had a question come in for Dr Potter and uh here's the question is it necessary for a sponsor to have in its possession the DHT HF data for the purposes of traceability even if those

data do not need to be submitted so great question um the short answer is probably it depends um part of the reason I say it depends is hopefully during the IND phase or earlier in the development program the sponsor you know we'll sit down with it with FDA and figure out okay this is how how you know how our data is going to flow from the

HF data to the Epic data to summary data to analysis and you know come to some decisions about okay here's what needs to be submitted and during that process um one of the things that may come up is you know you know when you're working with a vendor for the DHT that you know the vendor will go through and that they'll Acquire The High Frequency data

do you know some preliminary processing to take it to the Epic Level data and then the Epic Level data will be what is shared with shared with the sponsor in you know in that case we can you know we'll probably sit down and figure out okay hey this is how how we can set up a plan so we understand all the steps all of the data

so it we can review it and gain confidence that um you know there we can trace it back all the way all the way back to you know the high frequency data um but I think as we learn in the in this field I think that will be something that we'll get more clarity as we get more familiarity with with this so thank you thank you

for responding to that question and we want to this is all the time we have for questions in this panel and we want to give a huge thank you to all of our presenters for answering numerous questions that came in during the Q a panels