 OK, so welcome everyone to this information session about the design phase of the Hysander program. Quick housekeeping before we get started. This webinar is being recorded. Because we're using Zoom webinar as our platform, you can't turn on your camera or mic unless the Zoom host allows you to. There's going to be a Q&A section, and when we get to that section, we may invite people to turn on their cameras and mics to ask questions. Just be aware that if you do, your voice and image will be recorded and will be published. You can ask questions via the chat channel or the Q&A channel. If you do that, please know that you may be identified by name as we respond to your questions. So if you wish to avoid this and remain anonymous, you can ask a question anonymously in the Q&A window. And if you want more information about our privacy policy, you can find it on the ARDC website. So to begin our information session today, I'd like to acknowledge and celebrate the first Australians on whose traditional lands we meet. I pay my respect to the oldest, past and present of the Ngunnawal people. I'm joining the meeting today from Canberra in the Australian Capital Territory. So today we're going to have a presentation followed by moderated Q&A. As I said, please add questions to the Q&A window or to the chat channel as we go along. ARDC staff are going to be monitoring those channels and collating the questions for the session following the presentation. The purpose of today's webinar is to give an overview of the next phase of the Hysander program and how you can be involved. A number of you will already be familiar with Hysander and its progress, but there are many of you here today who aren't familiar with it. So before I hand over to my colleague, Grace, who will be discussing the design phase in particular, I'm first going to give a brief summary of Hysander and our current progress. So ARDC or the Australian Research Data Commons is a national research infrastructure organisation. We're established under the Commonwealth Department of Education's National Collaborative Research Infrastructure Strategy, or more simply NCRS. ARDC's role is to enable the Australian research community to access nationally significant data-intensive digital research infrastructure, platforms, skills, and collections of high quality data. Hysander is one of ARDC's strategic initiatives formed under our National Data Assets program. Hysander stands for the Health Studies Australian National Data Asset, and its high-level goal is to partner with the health research community to build a national data asset from the outputs of health research studies. The purpose of this data asset is to support data sharing and secondary use of data in order to increase the value and impact of health research and the investment into health research projects. Ultimately, we're aiming to facilitate better health outcomes for the Australian population by facilitating new research and research translation. So prior to the formal launch of Hysander last year, ARDC held preliminary discussions with some peak national health research organisations. Those discussions identified an opportunity for us to help improve data sharing from clinical trials, clinical quality registries, cohort studies amongst many kinds of health research areas in order to improve the impact and translation of research. ARDC subsequently invited these organisations and a few additional key bodies to form an advisory committee for Hysander to provide feedback and advice on ARDC's strategy and the direction of the Hysander program. Based on discussions with that advisory committee, ARDC selected investigator-initiated clinical trials as the initial focus for Hysander's infrastructure and as a proof of concept of what we're trying to do. This area of research meets our criteria for supporting research translation, but it's also one of the more mature health research data communities with respect to data standard methodologies, community coherence and organisation. So what this means is that there's a shorter path between where that particular clinical trials community is up to in their data sharing capability and what Hysander will deliver. And so they were considered a good candidate for a proof of concept for the infrastructure we plan to build. So ARDC as an NCRIS organisation, our timelines must follow their roadmap cycles. So the current Hysander program end date is mid 2023 to align with the current NCRIS roadmap. This initial program period for our proof of concept is thus focused on clinical trials as I said for our starting point, but we expect that come the new NCRIS roadmap which is currently under consideration. The Hysander program will continue well past 2023 and will expand beyond the current focus on investigator initiated trials, but investigator initiated trials is where we're starting. It is also worth noting that ARDC is not trying to build an infrastructure here that we will own or operate, but instead our goal is to build capacity into Australian research organisations and communities so that they can share long term ownership over this national data asset. As you'll see, the approach we're adopting for this program is one of consensus building and co-design with those communities and stakeholders. So as you can see on screen, the current program has four main phases. We've almost completed the first phase, which is our initial consultations. The purpose of these was to engage with key stakeholder groups in the broader research community to build consensus on the purpose, priorities and value proposition for this national infrastructure. These consisted of workshops with health researchers, clinical trialists, research participants and health consumers and other professionals in this space such as infrastructure providers and policy makers. I note that many of you here today have been or are currently involved in these consultations and so thank you for the contribution you've made thus far. In parallel to this, over the last few months, we put out an open call to research organisations to establish what we're calling nodes in our infrastructure network. In the moment, I'm going to explain what a node is and what our infrastructure design entails, but it's important that I acknowledge that a number of attendees here have been part of that application process and are currently awaiting the outcomes of those applications and just to let you know, we should hopefully be in touch very, very soon about that. So the next phase of the program after the initial consultations and the one we're here today to discuss is the design phase. The purpose of this design phase is to establish the specification for the data asset and the infrastructure we will be building. And I say we because as I mentioned, this is a consensus building co-design process that will include the voices of the different stakeholder groups in this space. Once we have co-designed the infrastructure with you, the nodes that I just mentioned before will implement those designs at their organisations and start building this national infrastructure network. So that's that development phase. You can see that will be happening predominantly next year. In the final phase of the program, the final six months, we will be testing and deploying the infrastructure. So that's the quick overview of our timeline. I'm now going to delve into a little more detail about where we're up to for those of you who are newer to Hysander. So as I said, we're coming here to the end of the initial consultations. The first consultation workshops were held last year. These were open workshops, but were mainly attended by clinical trialists and health researchers. The Australian Institute of Health and Welfare were consultants for this process and the workshops established some foundations for Hysander. Firstly, we identified the primary research purposes for a national data asset. These were, as you can see on screen, systematic review and meta-analysis, replication, reproducibility and peer review and secondary research projects and analyses. These were identified as three top priorities because in turn, these things can facilitate policy development, new study design, health technology assessment and clinical guideline development. So the research translation goals that we have for the program. The consultation this last year identified the categories and types of information about clinical trials and the information generated by clinical trials that were required to support these research purposes. There is definitely metadata and documents about trials that are essential to secondary use, but the overwhelming priority that we heard from those stakeholders was the ability to access participant level data. So having pinned down the purpose and information needs for the data asset, we also sought feedback on the concerns and incentives around creating this kind of data asset. Some of these were around the resource cost and changes to work practice, but understandably, the strongest concerns were around how best to provide access to data and how to do this ethically and with the appropriate consent from research participants. However, overall, there was overwhelming support for the Cassandra initiative because almost a complete majority saw the benefits of data sharing, whether that was to broaden the reach and impact of their research and their research networks or to get better information to inform clinical practice and guidelines and their health outcomes, or even if it was just to make sure that they are compliant with their funder and publisher policies. I think in general terms, you can say that people see both the carrots and the sticks in data sharing and an initiative such as Cassandra. But understandably, this is a relatively new and confusing area for a lot of health researchers, and they don't want to have to figure it out on their own if they don't have to. So we also received a lot of feedback and support for Cassandra to involve and coordinate between the different stakeholders, not just the researchers and participants, but also the institutions, the policy makers and publishers too. The feedback received was collated into a set of guiding principles for Cassandra by an editorial team of health research experts and professionals and reviewed by the organizations forming our advisory committee. To take this further, we're currently completing a second round of targeted consultations with research participants, health consumers and trialists to allow them to review our approach. Based on these consultations, ARDC identified three development priorities that form the foundation of our infrastructure design. So the first thing to emphasize is that Cassandra is not going to be a new data repository where clinical trialists have to hand over or deposit their data and documents. We believe that kind of solution would be problematic because it's not always easy to hand over data due to ethics and governance issues, but also research organizations have generally already built a lot of data systems to manage their trials, data and documents. They may be electronic clinical record systems, they may be repositories or catalogs, but in general trials aren't starting from scratch. So what Cassandra will do will be to federate these different systems distributed across Australia and there are three pillars to doing that and that's what's on screen at the moment. So first, and this is the box on the left, there needs to be agreement on the kinds of data that should be part of the data asset. There needs to be a common framework for requesting and granting access to data and there needs to be the appropriate ethics and consent in place. Building agreement on this is what we call coherent data practices. So we have to use somewhat abstract terms here at ARDC so that we're not using jargon specific to any one particular domain. So the coherent data practices is what we will be delivered by the design phase of the program and the design phase. As I said, that's what we're here to discuss. So once these agreed practices are designed, researchers and their organizations will then need to adapt their practices and their data systems accordingly. As I just mentioned, we're currently reviewing applications from groups of organizations or what we're calling nodes. So that might be a conglomerate of universities of medical research institutes, maybe of clinical trials networks who are putting their hands up to lead the way in doing this to implement these new standards of practice. And they're going to be implementing these national standards to form a network of what we're calling coordinated data services. So that lower blue box. Once this node network is established, we can then build the federation layer on top of this. This layer is what ties everything together so that someone looking for trials and their data can learn quickly and understand what is out there and request access to the data. So before I give a concrete example of what this might all look like, I just want to make clear that we are not asking trials to hand over their data and that there will be a governance process around who may access data and how they may access it because obviously to do anything else is going to be inappropriate and highly unethical. Instead, the nodes will be providing nonsensitive metadata about their trials and data into the data asset, including information about whether the data can be shared and how people can request access to it. Okay, so I'd now like to switch to some examples and hopefully this is going to work for me. Okay, maybe Rhys, if you can give a quick nod, can you now see Vivli on screen? Okay, great. Okay, so Vivli is a platform to enable sharing of data from clinical trials based in North America. It's targeted mainly at pharmaceutical trials. My apologies to attendees from Vivli if I'm misrepresenting your platform but it's useful enough now for this description. So as you can see, you go to the Vivli website and you see an interface that allows you to search for clinical trials. You can search by keyword or they have some existing categories or search filters you can set. So I'm just going to randomly click a few here. Hopefully this returns some results. I know that returns zero results. Let's just take this off. So we've got some results and what each of these results is is a different clinical trial. If I click on that page on that link, you can see it's loading some details about the study. And if I click on any one of those links is going to provide the same standardized fields describing what that study is and some additional information here, administrative information, including the registry, the clinical trials registry that the trial is registered with and so on and so forth. So the point there is essentially that we've got one simple easy platform to look across different clinical trials and see what's there and there are mechanisms in Vivli to request access to that data. I actually haven't logged into Vivli here so I'm a bit limited in what I can show you. So what I'm going to do is quickly switch over to a different platform. Now, this isn't in the clinical trial space but I'd like to use this one because it works well as a quick on-screen demonstration. So this is a platform for sharing data from cohort studies specifically dementia cohort studies called Dementia Platform UK. You can see that they don't have the same kind of search interface but what we see on this page is a listing of all the dementia cohort studies that are listed with this platform. If I go and click on one of those studies to find out more information about it, you'll see the tab here available variables and we'll see a submenu here and we can see what they've done is actually for all their participant level data that they have grouped the variables into some categories. I think most of the health researchers here this makes intuitive sense that there's socio demographic information and the history information and so on. And if I click on one of those, it's actually showing me that metadata about the IPD. So what kind of variable is it actually included in this data set and so on. So that's a fairly highly structured and detailed data sharing platform. They're able to do this because they're limiting their scope quite a lot. As I said, cohort studies within dementia research and they have some very granular standards in place for what data is to be shared and the formats for sharing that data. But they're just two quick examples and hopefully now and Reese, I'll just get you to give me a thumbs up again if we can see the slide deck now. Excellent, good. Everything's going swimmingly. Okay, so that was two very brief examples just to get it in your minds, picture in your minds what's going on here because I realized what we were talking about before was somewhat abstract for a number of you. So let's take a look back now at that infrastructure design. And if we look at the Federation Services, so what Federation Services are, that's ARDC-Lingo, a generic name for those vividly type websites that allow people to search for trials and data relevant to their research and those websites give information and direct people how to request access to data. So the way that a service like that works, now like a WebJet or hotels or bookings.com site, what that interface is doing is actually searching across the network of service providers or in our case, organizations, research nodes who hold clinical trials data. So what an end user sees when they use a platform is a catalog of the holdings at the nodes. The platform itself isn't holding participant data or trials documents, that stays with the trial list or the organization. What the platform is doing is displaying the nonsensitive metadata about the trial and its data holdings. So as most of you will be able to guess, the nodes are gonna hold lots of different kinds of data from different kinds of trials. So the way a system like this works is that there will need to be agreement about the standards on the categories of data and how they're cataloged and described in the system. In addition to make the process for requesting data more streamlined and efficient, there will need to be agreement on a framework for that process. For example, what kind of information must an applicant provide when requesting data, who should be reviewing those applications and what are the terms and conditions if access is granted to the data. And to facilitate sharing of data in that way, there's going to need to be an understanding of what ethics and consent approvals need to be in place. There will be an obvious difference here for already completed trials who did not obtain consent when they were running their trial. That's gonna be different for clinical trials in the future. Indeed, the consultations that we're holding and have completed already revealed a strong appetite for the development of a robust standard approach with clear procedural guidance to obtaining ethics and consent for data sharing that Australian trialists could adopt to make this aspect of their research practice simpler and more efficient in the future. So the development of these kinds of standards or, again, our jargon, coherent data practices, the development of those standards, standards that can work at a national scale and being endorsed by the range of stakeholders from researchers and trialists, to participants and health consumers, to institutions, funders, policymakers. These standards are what we will be developing during the design phase of the Hussand program. And when I say we, I mean all of us, not just ARDC, this is a co-design process. So, okay, at this point, I'm now going to hand over to my colleague, Dr. Reese Williams, who will be helping to coordinate the design phase. And it's gonna give you an overview now of our approach and let you know how you can be involved. So, Reese, I'm gonna move us forward onto the next slide and you just let me know as we need to move through. So just keep going, I think, Kristen, to the next one. So the design phase, as Kristen said, the way we're going to do this is with a series of working groups, which is where we'll need, obviously, you guys to contribute. You'll see here the names of the four working groups. And these are the four elements that some of them, Kristen's just alluded to, that really will go into collecting together that sort of coherent data practices. So the information design component, meaning the metadata model, what it is, those metadata fields that will absolutely be required for all nodes to contribute to the catalog, if you like. And the standards of the data collection and the data reporting from the clinical trials. And that includes not just the individual patient data, but all the other documents that are associated with the trial. So the trial protocol, the consent and ethics approval process and whatever other agreed suite of documentation is that forms the data set for a particular clinical trial. So that's the information design group. The data access group is going to be concerned about the flow of data from the nodes to the federated services, what type of access is appropriate, what's the process that will be, that people will need to go through to request that access. That will need to be in broad terms agreed. We'll need to consider things like data sharing agreements, intellectual property agreements, if there's licensing issues, we don't know what sort of trials, but some of them may, there may well be issues around ownership and about conditions under which the data can be shared or not. So that group will have to tackle those issues. I should have said that these four groups will run at the same time. They will run in parallel, which we can do provided we will have that interplay and I'll discuss how that, we hope that will work in a minute. The ethics and consent group, that one will actually run a bit longer than the others. It'll continue to run into the development phase, but I'll come back to the timeframe in a second. Obviously that's a big one and the first stage of that group's work will be to identify the current scenarios around ethics and consent. Obviously everybody's doing those now, but they might be doing it slightly differently using different processes, different forms, different workflows, but ultimately we'll need a set of recommendations and some resources and perhaps some training materials so that every node working within the standard program will be collecting that in a consistent way and at least a compatible way. It doesn't mean everybody needs to use necessarily the same form, the same as you don't necessarily need to use the same database to keep your IPD data, but we will need to do it in a way which means there'll be compatibility and transferability of data across nodes. And finally the technology group will start to delve into some of the details that could be required further down the track. Things like do we need libraries and tools to connect systems together? They don't have to write them, but they will have to identify what those tasks are, what those tools need to be, exchange a metadata, for example, crosswalks between systems. That kind of stuff is what the technology group will do. We can come back to questions if people have got questions, but that's enough for the minute. Next slide, I think, Kristen. The other thing that we, as a starting point, have done is to develop a set of terms of reference for these groups and those will obviously become available when the groups formed in the, which will be in July. But broadly, this is what the groups will look like, will there'll be a chair, which will be an ARDC staff member. The ARDC will be responsible to convene these groups, to manage the documentation and the minutes and the other records and the operations of these groups. So the ARDC will provide the chair and that administrative, if you like, capacity. There'll be a representative of each of the nodes. So if we've got 10 nodes, which will be announced, I'm not sure how many there'll be, because Kristen is involved in that process and not me, but whatever the nodes are, say there are 10, there'll be one representative of each of those 10 nodes on each of the working groups. And then there'll also be subject matter experts for one of a better description. These are people from the organizations that Hissander and ARDC have been working with for some time, people like the NHMRC and the AIHW and the clinical trial centres that Kristen's already mentioned. And as required, we'll have people with expertise in ethics or particularly technology elements. And if the group decides as it progresses that it's short on a particular capacity or a particular skill or particular technical knowledge, we can invite others on to make sure that collectively with the ARDC's knowledge and the node people who are doing the work now and the SMEs, we've got all the things we need to make the right decisions and to have the right discussions. The deliverables for each group will be, will depend on those four groups that depend on the domains in the previous slide. But in general, what we're expecting all the groups to do is to have really productive conversations, gather all the information from the sources they need to provide advice, look for risks, look for and ultimately make recommendations, prepare a document of some description. They'll have to work out the format. But in the end, the whole point of this is at the end of this table, provide a set of recommendations to say this is what we need in each of those domains to end up with our coherent data practices that will enable us to build the system. And in general, the approach will be, as I said, involved discussion. When we say co-design, that means that unlike a lot of projects, we don't know exactly, we know broadly what the scope uses Kristin's described, but exactly what the solution is, we don't know yet, exactly how it will work. We're really relying on the expertise of you, collectively you guys on this call and obviously others who will be involved. So it's a very collaborative and agile process. It's focused on ultimately, we know what the stakeholders want. We've done in our collaboration, in our initial consultations with the stakeholders. We know that that's the focus we need to concentrate on and so that's gonna be up in most of our mind. So it's very much a stakeholder driven, collaborative agile process. I think that's good enough for that one too, Kristin. I've mentioned the timetable a little bit. The next step obviously will be the announcement of the nodes, which is Kristin said will happen soon. I would have thought in the next week or so. And so we will look to start the groups in July and we're suggesting that they'll need, they'll probably meet approximately fortnightly, each group will sort out its own timetable, but that's the expectation. Looking to finish up towards the end of November, perhaps the very beginning of December. So that in anybody's language is a very short timeframe, hence the notion of fortnightly meetings. If they need to meet more often, that's up to them. In between times, of course, as the coordinators of this AODC will make sure that the chairs of the working groups get together outside of that. And if we need to bring two groups together for a meeting, we can do that. We can schedule other sessions as required, but as a minimum, people should be looking to look at a fortnightly commitment of a couple of hours and probably some extra work outside that as required. So if you're, that's the sort of expectation we had, but the good thing is it is compressed into quite an intensive period of time. The development phase we expect to start in December or January, and as Kristin said, run for a 12 months period. But the design phase will be finished by the end of the year. As a starting point for the co-design process, we've actually got quite a lot of material for this. So we're not starting from a blank slate. We've obviously got the user scenarios and the value proposition work that was done as part of the consultations. We've got the input that's coming from the current sort of targeted round of consultations. We'll follow that sort of consensus building approach. And as I said before, the recommendations. And then by the end of the year, we will have essentially will perform a part of a specification to hand on to the developers. We will have technical expertise from developers woven into these platforms. So if someone provokes us to do something that isn't going to work, we will have an idea. So we won't be stuck with the situation that we get to December and ask the developers to do something and I'll say it's not possible. So it'll be that iterative process throughout. And next slide, Kristen. So what we would be, what we really love people to do would be given that background information, register their interests that they'd like to be part of one of these working groups. And it may be that you're on the call now and you're part of a successful node and you'll find that out shortly. Or it may be that you're just interested anyway. And you're part of an SME or any other organization and even if you haven't had contact with the Cassandra program so far and this is of interest to you and you've got something to contribute, we would genuinely love to hear from you. And to register your interest, if you follow that link or scan that QR code, you'll be able, you'll take you to a form so you can provide us with some basic contact details. And that's open to anyone. And if it turns out that there's a sort of two way that you end up putting your hand up as part of the node that doesn't matter, we just love to have the names now so we can start to work through and start to populate the working groups. I think that's probably enough from me but I'm very, obviously take questions. And Q&A reminded that if you have a question, if you would like to put it into the Q&A window, that would be really helpful. And it's not too late to do that or into the chat window. It's certainly not too late to do that if you want to do that now, that'll be helpful. Thank you. Okay, thanks, Rhys. You can hear me out. In fact, I can. In fact, there was a first question, wasn't there? Yeah, there is. Somebody's asked me. Yeah. So. So I can see that. Mark's asked the question now. When I said transferability between nodes, well, actually that's not strictly the terminology I should have used because we're not transferring the data between nodes. What I meant by that was the ability to... How do you say it, Kristen? So the metadata has to be put into a common place. Therefore, all the metadata must be in a common format. And that will be held within a repository. But the ability from the federated layer to know consistently between nodes the same information and what's available. And does it apply to IPD and other things that applies to all the data associated with the clinical trial? So it could be the sort of stuff that Kristen showed in this demonstration, vividly information about the trial protocol, who the cohort was, the age group, the socio demographic, all those things which you'd like to metadata about the trial is the first layer. If you then had applied through an appropriately agreed process to access the individual patient data, then you would be granted access to that through the agreed process. But that data would still be held by the node that the process of applying for and obtaining it will be managed by the federated interface, by that interface layer. Yeah, that's all very inaccurate. Just looking at the wording and the question, I think I'll just highlight there that we're talking about metadata and not the IPD. So that was one distinction. And also just in transferability between nodes. Yeah, worth emphasising as Rhys was that we're talking about metadata from a node flowing into a federation service so that someone could see metadata from across the nodes. However, we're approaching this as a somewhat open architecture. As I said, the metadata shouldn't be sensitive information. It should be stuff that is okay to share, okay to make publicly available. And just depending on the exact technical solution that each node comes up with, there is nothing at this stage which precludes nodes being able to see each other's data. I guess the point I simply make is that our primary focus is on making sure the metadata from the nodes feeds up into a federation service. If that also provides functionality and benefit for the nodes to see metadata from each other on some technical level, then that's a good outcome too. Okay, there is a question there that just went to all panellists from Jason Ferris. He said, are groups like Australian Data Archive likely to be incorporated into the ARDC solution? So the solution becomes the one-stop-shop for all forms of health data? That is a, in a sense, a big picture question. I'm glad that people are thinking a big picture. If you just bear with me, I'm actually just going to open the chat and try and find the wording of that, make sure I'm responding to the correct question. So Australian Data Archive, yes, that's not exactly a general type of archive, but it's more general than some. Will it be incorporated? I guess it depends on exactly what you mean, but into ARDC solution comes a one-stop-shop. So I guess what we're trying to do at this stage of the program is develop, and in this design phase specifically, is develop some standards around data practice and the research practice that relates or feeds into that data practice. If that, no, maybe I'm misinterpreting use of the word forms here. If that results in standard forms, then yes, we would look to share them as well as possible. If it's referring to all forms of health research, yes, the longer-term scope for Cassandra is to expand beyond investigator-initiated clinical trials, as I explained, though we work to the current increased roadmap. So that's why we've got the current, project period set as it is, and putting that initial focus on clinical trials. And yeah, there has been discussion around whether Cassandra could produce, essentially off-the-shelf type technology solutions for clinical trials. So if a clinical trial or the organization that runs it doesn't currently have all the forms or a data repository or data collection tool or whatever it might be, could Cassandra provide that? I think the longer-term, that's something that we definitely want to look at and see how we might be able to support that. As I said, this first project period is around a proof of concept to show that there is that appetite and building capability into research organizations to create some common data standards and practice and infrastructure to support that and show that we can actually do this with clinical trials, it is achievable. Dash, might like to, that sort of leads on to Martin Ebert's question in there, which was obviously, what about prospectively? If there are existing trials, what we'll hopefully be able to do is to, when the system at the federated layer is made, it'll be obvious which ones are available. Martin's asking something similar to what Kristen just talked about, which is, will there be a kind of toolbox of things which will allow someone who's now designing a trial, which may not come online for six to 12 months hence, that'll make it easier for them to have their standard template for consensus, their standard template for the other things they have to collect, the short answer of that is yes. It won't happen tomorrow, but yes, Cassandra will design, if you design a set of common data practices, then effectively, that's what you will provide as well. And that would be the intention of the project. It may not happen in 12 months, but at some point that is exactly what we want. So that actually moving forward, anyone who's working initially in the clinical trial space and then in other types of studies will be collecting by default data in such a way in their particular state, in their particular node, that the data will be compatible with Cassandra, will be, it'll be much easier for it to be accessible. That is the intention. Okay, there's a question there from Alison about, is the ARDC aware of the CLIN trial refer? It's clintrialrefer.org.au. I'm personally not, but... Yeah, look there there are a number of initiatives and technology solutions in this space. And they've definitely come up in consultations with various stakeholders and advisory committee. And part of the work leading up to, to prepare for the working groups and the design phase is to map these all out and have an understanding of what that landscape is and how to best fit into it. So we do appreciate people, even if they are things that we have heard of before, please let us know if it's something, you know, we are not a health research organization despite some recent my expertise, that's not what ARDC does specifically. So, and as I said, this is great design. So we rely on people saying, look, this is what we use already or what we want to emulate or whatever it might be. And we won't be reinventing wheels where we don't need to. But through all the consultations that we've held and including with those peak national health research organizations, there is definitely a gap in the market here that ARDC is hoping to fill to better support Australian clinical trialists. The only thing I'd say is that obviously our focus is on researchers, not so much on consumers. Clearly we have to make sure that this is consistent with what consumers expect from clinical trials, but it's not primarily to be a database of currently running clinical trials so that either a health professional or a patient can find the one they should enroll in. It's primarily aimed at researchers getting the best use of their data and managing the data the best and also making it available to others for either a secondary research use or perhaps a clinical colleague who is working in a similar area. So the focus for us is primarily on primary and secondary use of research data, as Christian mentioned, for things like metadata. So it's about designing of new trials for finding existing trials, which complement each other. And also there's a strong market here, a strong component of this where the data can be used for other purpose. You don't have to be a clinician. It can be used for sociology research. It can be used for data linkage. So that would be my only caveat is that the clinical first site, as I understand it, clinical trial first, is more about a catalog of existing trials. We'll have that too, but our focus will be a bit different to be around very much research focus. Thank you. So did we answer this one? Will any clinical trial registries be linked to this infrastructure? Up, go ahead. You're muted, Kristen. You're muted, Kristen. We love hearing your voice. Okay, so, yeah, but this came up a lot in our consultations. And for those of you who are paying very close attention to the text heavy slides that I was using, ANZ CTR, so the Australian, New Zealand Clinical Trials Registry, one of the organizations represented on our advisory committee. So yes, the efficient way of designing this from a business practice perspective, from a technologies perspective, is to link to the data held in those clinical trial registries. So to, as you said, avoid duplication. And that is very much our intent. The reason why I phrase it that way is that, you know, it is actually up to the working groups in the design phase to make the recommendations around that. And so I'm just using the opportunity to say this, you know, this is co-design. We collect the feedback, but it's really up for the stakeholders and their communities to say, this is what's gonna work for us. Okay, thank you. A question from Steve McGeck and are there plans for variable level metadata per DPUK approach? Sure, I'll jump into that one. But you can answer that one. This is my language. So DPUK is the example I showed before, Dimensions Platform UK. And the reason why I included that example was the Vivly interface that I showed, it really kind of showed quite a high level of description. You know, what is the trial, et cetera, et cetera, whereas the DPUK example that I was able to show without having to create an account and log in and do all that kind of stuff on screen. What they openly show is that description of individual, if people are used to spreadsheet type data, basically the column headings or the variable name, the variable description and a way of categorizing it that way. So that's what that question refers to when it says, would we include variable level metadata? So I think something like that, obviously the more granular you can get, the more powerful your search and discovery is. The issue with that, so obviously, you know, that's something great to aim for, but the hard bit of achieving that is that it requires a lot of standardization and clinical trials collect a lot of different kinds of data. Each trial collects lots of different kinds of data by necessity and it might be, it's likely to be impractical in the next year or two to come up with a prescription of how, of what information a clinical trial could collect and how they should label it and so on. What might be more achievable is to say, well, rather than the variable level metadata, maybe there will be agreement on the groups of metadata. So in that example on screen before we talked about socio-demographic data, family history data and so on. So maybe there could be some agreement around those kinds of categories or maybe somewhere between the two or maybe somewhere higher level again. It's exactly that kind of question or that kind of decision rather that the working groups will come up with. And the last point that I make around that is that not just with this particular issue with the metadata and informatics stuff, but with the ethics and consent stuff and the data access stuff, even the scope, why are we just looking in the investigatory initiated clinical trials? It's because the capacity for scope creep here in this program is through the roof. There is a lot of improvement that people can see that is required and can be made. And it's a matter of picking a starting point and not saying that we can solve everything in a couple of years. Everyone knows that's not possible. What I think is a more valuable way forward and based on feedback, most people seem to agree is we can use this opportunity to map out the different things that could be addressed in an ideal blue sky situation. And then once we have that map, we can figure out the pathway through that so that we can say, well, this is everything we'd like to achieve maybe in the next couple of years. These are the priority things. And if we just achieve this, we're still making some progress here and improving the situation. Yeah. And I was gonna say, Steve, that's exactly the sort of thing that the working group will have to decide. So the co-design process characteristically balloons out to all these options. And then the working group really has to narrow it down to say, what are the priorities? What has to be done as a minimum now? And we've got to decide that by November. And then the other things, as Christian said, become nice to have or later developments, not inconsistent with the project overall. That's a really good example of the sort of decisions that the working group will have to make. What are we gonna do about this? What's the scope? Yeah, what level of details should we be looking at? There's a question, Christian, which is sort of also about Divli, which is, yeah, and you can answer that one. I think I'd say yes, but you can answer it. Yeah, sure. I think Natasha's back online had a quick technical issue, but I'll just proceed. So the question is, do you envisage the Federation services would be similar to the Divli or Dementia examples? For example, would Federation services be a central place to start, search and discovery? So, yeah, look, I mean, I think that's very much the kind of functionality and probably a lot of the feel that we're looking for in a basic kind of Federation service. Hopefully, and I did rush through the examples a little bit and they look a little bit different on screen, but hopefully people could see the commonality between them that you've actually got, they're allowing you to search through health research studies and kind of see the data and documents that could be made available subject to request and approval. And then it's just, there are differences there around the kinds of health research that's contained within them and the way it's described and the application process and so on, but that higher level functionality is common. So, yeah, I think that's really, the Divli is the Dementia Platform UK, there's a bunch of other ones out there. That really is a primary kind of Federation service. So yes, the other thing to note about Federation services and the comment I made before about this being an open architecture. Again, we're going to have to figure out the designs together and what is going to be appropriate, but we don't see the design of the system or the nonsensitive metadata that will be passed on from nodes as being proprietary information or restricted information. This kind of broadly falls in the category of open science and supporting that kind of ethos. So why we would have to agree together, if a new group came in and said, we just sort of a great Federation service, something new and different to Divli or whatever, we would like to build this. Yeah, we'd have to figure out what is our governance process for doing that and we have bookmarked next year as the time to work with the nodes and stakeholders as to what the governance model for the infrastructure will be separate from the data governance. But we anticipate that our design will be as open as appropriate so that people could leverage off the metadata that nodes are providing in a standardised format and could build and develop new technologies to take the functionality further and make it more useful and improve the research value of the whole thing. Okay, we have come to the end of Q&A and we're coming up to time, Kristen. So any last words? No, thank you everyone for attending and thanks for those questions, they're really good. I am just going to flick back one screen again so you can scan that QR code if you want or if you can remember that ridiculously long URL. Yep, we will be in touch. I'll be emailing everyone who registered for this event. I know I was contacted by some people saying, oh, I can't actually attend but I've registered because I'm interested. I'll be emailing you all once we have the recording up and live. I'll be sending you the link to that. I'll also be sending you the information, the URL that you see on screen and any related information so that you can learn a little more and hopefully sign up to be a part of this because it's only going to work if everyone is involved. Absolutely, thanks everybody for your support. Great, thanks all. Thank you everyone. I am.