 So welcome everyone to the 14th meeting of the sensitive data community of practice. This community of practice is co-coordinated by the ARDC, the Australian Data Archive and Arnett and today, well, we'll start, hang on, yes, by acknowledging and celebrating the first Australians on whose traditional lands we meet and paying our respects to their elders past and present. For me, that is the Nga Wajap people. And I just like to let you know that we'll be taking notes today in the community document. I've put a link to that in the chat. If you've come in after that link went in, I'll put it in again in a second. But you should all be able to edit that. It just gives us an opportunity to pop in notes and into that gray box. And I'll also take notes of any questions and answers that show up in the chat. I'd like to pop those into the community notes as well so we have a record. So today, we're going to be talking about external IT support for research teams. So I think we're all aware, researchers and researchers working with sensitive data finding more and more that their research projects involve the involvement of external IT teams. And I think that's can be an interesting relationship to navigate to make sure that everyone's getting the most out of the project. So today, we're hearing from three people who have worked in various external IT support roles who are going to talk to us about how to get the most out of that relationship. So I think I will switch over. So that's Helen, Andrew and Luca. Helen, were you starting us off? Yeah, for sure. We didn't formally discuss this. Are you happy with that? Sure, yeah. All right, cool beans. All right, I will share my screen. Okay, awesome. Thank you, Nicola, for the introduction. Yeah, so the external IT support professional network is a really interesting one with really sort of varied skill sets and approaches, I think, to collaboration with research teams. But it's quite infrequently talked about. And I found at least chatting with various research groups that there's a fair bit of mystery around the process of engaging with external IT support, what to expect from that process and what sort of what you can ask for and how engaged that IT support would be. So the three of us today have quite different, I suppose, professional roles. And so hopefully you hear sort of some different perspectives on that interaction. So this is me. I'm Helen. I'm a manager at Notitia, which is an analytics consulting firm. You can have a Gander at our website if you like. I've got a lab science background, so genetics and biochemistry, wet lab research, and I started doing more and more coding. And nowadays my day-to-day work is full-time software development and analytics. So in terms of where I would sit on a project, it would be somewhere between the sort of IT infrastructure and software development side of things with some sort of database management as well. So I'm also one of the co-organizers of our latest Adelaide, although we haven't had a meet-up since pre-COVID. But if you'd like to be involved in like a programming group sort of relevant to lots of research data transformations and please do get in touch. What I've got down here is kind of a sample of some of the clients that we usually have at Notitia as a consulting firm. So you can see here that we're pretty healthcare focused, although we certainly have different sort of clients as well. But we've got sort of publicly funded research groups, privately funded research groups, government groups, and also just private businesses that operate in a really similar way to a research group in that they're effectively doing internal research projects. So something that all of these groups have in common is that they've got patient identifiable data. So it's very sensitive and the content of the sensitive data fields varies between the organization. But generally it'll be sort of row by row patient identifiable information and each organization or research group will have different members who will sort of have ethical permissions to access different components of that data. So what I've got here is the sort of difficult transformation journey, data transformation journey that we go through as an organization, as external IT support. And in the interest of time today what I've done is pulled out a few key points here to talk through that I think are particularly relevant to research groups that are handling sensitive data and want external IT support in order to be able to achieve that. So what we've got up the top here in the sort of grainy tail part is the sort of core data management process. So ideally a research group would come to us when they've got sort of an idea for a project but they haven't done a whole heap of planning or and haven't sort of already bought any kind of tools for starting the process. So then we'd be able to go through and plan everything really thoroughly and make sure that everything's configured really well for for what they need security wise. However, what actually happens 99.5% of the time is that a research group will have something set up already and they'll hit some sort of a wall where they realize they need assistance and then they'll get in contact. So at that point in time and the first thing I've got here is being realistic about money. So especially for research groups you've got very specific funding kind of boundaries and it's really important to have that discussion up front particularly because there'll be some security solutions that are really only plausible if you have a consistent amount of funding over the period of time that that data is available to use and often that's not actually the case for a research group. So more often for a research group there'll be sort of more funding available at the start and then funding will get a bit sort of fuzzy towards the end of a project and keeping that in mind at the very start means that we can make sort of a security setup that can manage that process that doesn't need consistent or increasing payments. So something I'd say to keep an eye out for is if you want to use a certain software tool in order to be able to provide certain secure access to your data to either your own clients or other researchers or something like that it's worth before committing to something like that it's worth getting external IT support to be able to talk through what that actually means because oftentimes something that seems good doesn't actually serve all your requirements but it can take up a lot of the budget. So the second point I've got here is developing a joint data security understanding. So this is kind of leading on from that first point being transparent in terms of who you've got involved in the project, what they need access to and sort of what you're trying to do with the project. So oftentimes security-wise there'll only be a couple of people who truly need access to the entire data set. So if what you want is to make sure that you're sort of following your ethics agreements by ensuring that only the people in your team who absolutely need every part of the data have access to it and all of the other people have a much more limited type of access you still want to make sure that the limited access is appropriate for those members and isn't going to cause them sort of unnecessary problems. So there's a million different ways to get people access to various types of data and it's all very doable and sort of time blockable so long as you plan sort of early on and talk through each step of the process. So I know it's tempting to sort of to only consider maybe the first year of your project in terms of setting up IT support but actually if you give the IT support a really broad understanding of your project they're going to be able to meet your needs a lot more easily. So really walking through each step of the of the research project is super helpful there. So the next point I have is to agree on a visual output type for a communication focus. So in terms of maintaining a relationship that might go for say three to five years for a research sort of funding block you want to make sure that you're communicating regularly and positively and it's really easy for that to not happen. So if you've got external IT support it is external and I suppose they're handling a what can be quite a siloed part of the research project but as soon as something goes wrong or needs to be changed you need to be on the same page and so it's important to have some kind of focus for both the research team and the IT team so that you can both communicate effectively. So something I really like to use is a a really kind of clean and simple map of the infrastructure of the project so it might show the service that you have or the databases that you have what sort of fields are in each and then what that's used for. So say you're reporting or your website or your papers whatever that happens to be and then which of your team members has access to what maybe with some indicators of vulnerabilities around ethics agreements that way you can all like literally have a printout or share your screen and be pointing to those parts as you're talking through whatever you're thinking about that makes it a lot easier to communicate any issues or questions about ethics agreements or updates that you do have between an external IT team and your research team. Something else you can use if you're interacting more regularly with your IT team and they're doing some analytics for you it can be really good to have some kind of shared internal website or dashboarding page or something like that where you've got a joint view of say like a series of charts or something something simple that you all understand the meaning of that you can go back to to communicate some basics so if someone's confused about where data is coming from or how it's being used or what you can see you've got sort of a visual cue for that that you can all look at at the same time. The final thing I would say is expectation management and goal communication so in terms of security it's easy for people to get quite frustrated and often that's where actual security breaches happen so if they don't understand why they need to update their password and then they end up writing it down on a post-it note and sticking it to their screen or something like that that is the easiest way for people to make big security breaches. So there might be a series of processes that your external IT support team have asked for you to follow but that's not actually going to be useful over like a five year project unless everyone appreciates why that's happening and feels free to complain if they really hate the solution. So setting up that type of communication where both the research team and the IT team understand why the security protocols are in place really helps especially over a longer time period to to make sure that the security systems stay solid and don't get kind of messed with as part of the process. Yeah so that's that's my kind of summary of a typical engagement process for me so I'll hand over to you Luca. Sure just to follow the schedule we have Andrew I was wondering if you would like to go otherwise I'm happy to go now as well. You can go that's fine. Sure I'll share my screen thank you Andrew. Okay I believe everybody can see that I do notice the black box sorry I'm actually projecting from a Linux machine I think it does have issues sometimes we assume. Hello everybody thank you for having me today I'm Luca Dykes I'm a researcher and systems architect here at Samaritan's Australian Health Medical Research Institute I also have academic status down at Flinders University and I do some work with the Commission on Excellence Innovation and Health. I'm talking a little bit today about one of the projects we've recently been funded for with an NHMRC partnership grant and the process that we've had to go through in terms of allowing us to work with sensitive clinical data in an essay government computer network and so we've recently been awarded the $1.2 million to run the RapidX AI project which is a real-time project looking at artificially intelligence predicted risk of myocardial infarction in 12 emergency departments in South Australia really with the goal that this is a real-time clinical decision support system so patients will arrive in the ED we'll collect some information about them by interfacing with a range of health data systems and then providing a real-time risk assessment and provide this back to the clinician at the point of care. So you can imagine that this is quite sensitive to work with because we need to be able to interface with quite a number of data systems and then actually be able to have that computational infrastructure work with sensitive data be able to interface be able to work with clinicians in a very sensitive setting. So I was really keen to talk a little bit more today around the process that we had to go through with Digital Health Essay which are the governing and administering body of IT support and digital systems here in South Australia inside Essay Health. So I've just got a basic rubric here that's part of the business request just one of the initial things we had to go through and we engaged with Digital Health Essay. It's fairly general it talks about business value and clinical value and risk assessment and those kind of things. I was quite keen to talk a little bit more today about the process map and the actual engagement we had to go through with that but unfortunately a lot of the documents and a lot of the communication I have surrounding that are actually classified as sensitive and office use only or actually classified as sensitive and I just kind of wanted to raise that something that I feel really personally about and I'm sure the ARDC Alliance of this is the transparency of these processes. So a lot of the documents that we have had to follow in terms of the security assessments we've had to go through are not readily available and it's something I'm trying to have communication with Digital Health Essay about making a lot of these documents much more publicly accessible so that when external parties or in this case an academic party comes to work with the health system or work with the government there's a very clear line of process around what we have to go through. But very generally what we have to do in terms of meeting security is there's a mapping from SA Health Security Requirements to ISO 27001. It's not a complete compliance to ISO 27001 but it's a fairly significant subset of what we have to do in terms of computational infrastructure. So I thought today I'll talk a little bit more around the actual computational infrastructure we've had to set up in order for us to deploy these systems that work with clinical data. So we've set up this project called the Hard AI Project which is an overview of our systems architecture and really a system implementation that we've hosted on a publicly available website. So I've just linked the website up above there. And following on from some of Helen's comments we have a whole range of our system architecture, some de-identified network architecture, some project timelines, some project governance and a whole range of information that we want to make publicly available and share that information. So please feel welcome to go have a look at the Hard AI website where we do have a range of information about our systems and the projects we work with. So we've been really quite lucky that we've had approval to deploy a Microsoft Azure deployment on the South Australian Government computer network SA.gov.au. So as of this Monday actually just this Monday this week we have deployed to Microsoft Azure. We've had a subscription set up that's part of the SA Health Enterprise Agreement with Microsoft and it sits on the SA Health Active Directory Tendency. So we did a lot of work working with Digital Health SA and senior stakeholders to have approval to have a 24-sider range network address allocated to us from StateNet and we have now deployed to that network address range. At the moment we do host that on a StateNet network address range but we don't have a physical connection to StateNet at the moment. What we've been asked to do is to set up our environment on StateNet and then have a third party security assessment and once we pass our security assessment we will create an interface to StateNet. The way that this will work is we'll actually connect to StateNet through a hub model, a hub spoke network topology where SA Health and SA Government will manage a hardened network edge VWAN interface that we'll actually connect to via network peering. So that gives us a really consistent way of actually interfacing with StateNet and that allows a lot of that management of that actual edge network infrastructure be managed by SA Health and SA Government directly. A few of the security promise that we have had to do in order for us to work with clinical data are really a couple of key things. One of those is no exposure to public internet. So we do that through two mechanisms. One of those is with the PAZ services that we use on Microsoft Azure. So with our databases and with our sensitive data source and our event buses, they're all Microsoft PAZ services and we connect to those directly using Microsoft Azure Private Link. That enables us to connect with those PAZ services over the Microsoft backbone network so we never actually leave the Microsoft network. The other aspect is that we don't expose any endpoints or any public IP addresses to the public internet. To actually access any of our data services, you have to go either internal to our network or you have to go through StateNet directly. Really with the mechanism being that anybody that wants to access these data systems should do so through StateNet. They should seek credentialing inside StateNet as an SA Health credentialed entity. So for example, we've had ID or an Active Directory account and through that mechanism they'll be able to access our service endpoints. So it gives us a very clear delineation of where our responsibility is in terms of managing infrastructure and where the management of governance and liability and the legal aspects of what we're doing. So from that perspective, that is being managed by SA Health and SA Government. So all data that we manage is encrypted both at risk and in transit. So it's encrypted everywhere and basically we set out to implement a zero trust network. So I'll just go over very briefly some of the technology that we're using. Probably one of the key components of our technology is that we're using Microsoft Azure Red Hat OpenShift. This is a converged best practice solution for systems orchestration. It's effectively a Kubernetes abstraction. It's a higher level implementation of Kubernetes and it has a lot of additional constraints around security in particular. For the purposes of this meeting, I have talked a little bit in this slide about how Red Hat OpenShift complies with the Stride model, really around spoofing, tampering, repudiation, information disclosure, and denial of service. I think there's one artifact that I left off this slide. But for example, some of the things that Helen had mentioned is that we do operate with the least privileged model in terms of how we allocate permissions. We do implement an integrated identity and access management system. We use encryption for all systems components. We do logging for all interaction with our system and we provide that logging back to SA Health. SA Health manages a central Splunk repository for Logstore and we forward our logs into Splunk. Essentially, in this system, no sensitive data is stored directly and all sensitive data is injected into the system. In terms of security from an availability point of view, we maintain effectively a distributed service mesh. We have ability that our system self-heals if we have any actual physical infrastructure or logical infrastructure go down. It will have an automatic failover in the sense of it being like an active-active distributed system. Those systems will essentially always have some mechanism of being redundant and that says a massive catastrophic failure in multiple data centers. In addition, we do things like real-time monitoring and loading as well. We've really tried to align with what we've seen best practice in other areas like banking and insurance. Areas that use Microsoft Red Hat OpenShift are similar areas in government. In South Australia Department of Premier and Cabinet use Microsoft Azure Red Hat OpenShift. I believe Victorian DPC also uses a similar implementation as well as New South Wales and Queensland Health. Any additional information around these kind of implementations I'm really keen to hear about. I'll just go over a little bit just in terms of what our testing class looks like. This is what Red Hat OpenShift looks like with its central dashboard. You can see we've got a range of real-time monitoring and just an overview of the kind of applications and services that we deploy. For example, here's a range of pods and just looking over to the right you can see for each individual service component we have real-time monitoring of memory, CPU usage as well as a range of logging that we saw for who interacts with those services. Here's just a lower level view of the service information that's been used for one particular pod and you can see it actually is down to almost a second that we do recording of our system usage. And here's again that same pod just showing the log output from this one particular pod. So all of this information is stored, it's backed up on Microsoft Log Analytics and that gives us a really good way of having an audit history of all the work that we do. Just a couple more slides to talk about how we interface with these systems. So in this slide on the left I show the SA.gov.au domain. I'm really looking at the SA Health DNS. So that's really when somebody is on the SA Health domain or on state net, this is how they interact with us. They do recursive DNS from the SA Health DNS and then they would be able to find our DNS at the heart AI DNS. So really showing how that interface works on state nets. This is all essentially overlay networks on state net as subnetworks. And really probably the key thing here is the fact that we're doing a service proxy, reverse proxy paradigm that allows us to have a hardened edge networking implementation and then a service proxy, a service reverse proxy that we can scale up to have high availability. Also shown here is how we're doing identity and access management. So we're using an OpenID Connect and OAuth2 stack using Red Hat Single Sign-On. This approach allows us to do identity federation with SA Health HAD active directory accounts. So with our systems we also support users coming to access our systems but logging in with their SA.gov.au identity. We can actually federate with that. We're also looking in the future to provide federation to the Australian Access Federation such that the institutions can also access these systems by federating with us over state net by exposing that network. So more details to come about that. In relation to what users have to do to access data at one of our service endpoints, they really are required to pass in one of these OAuth2 access tokens. So these will be validated at a service endpoint. We'll be able to then log who that person was, validate that they have the right level of permissions to access at endpoint, provide a range of security assessment, security constraints around that. And we do that for all of our service endpoints over encryption as well, such that any mechanism or any interfacing that is done at that service level is recorded and monitored. So that's what we're working with. This is really my last slide. But at the moment we've had approval to store quite a lot of data. At the moment we have about 300 million records from a range of different data systems. These are administrative records, emergency records, pathology records, pharmacy records. We have a huge amount of clinical data that we're using for research and making sure that with the support we've had to go to cloud, making sure we're doing the right thing with this. We've been very fortunate to have an opportunity to go to cloud. And I think we're one of the first groups in South Australia in the health system to go to cloud. So we're taking this very seriously. We're working very closely with Digital Health SA and our stakeholders to do that. Actually just this Friday, I believe Andrew and I have a meeting here at Samry to talk about the relationship between the institutions as well, because we'd love to make these resources available more generally. So that's a very high level overview of the work we're doing. But yeah, thank you for joining us and thank you for your time. Thanks Luca. I'll just take over screen sharing. So I'm just going to talk on five main topics. Just going to introduce myself and give you a bit of background of who I am. I'm going to talk about when the best time to engage ICT is in some of these projects. What kinds of questions we ask when we're doing those engagements? Some of the solution options that we look to implement and then I want to talk about cloud versus on-prem which ties in quite nicely to what Luca's just talking about. So I'm the applications team leader at Samry. I run a team of software developers, business analysts, project managers and application specialists. Previously I was the lead software developer at Samry before I started in my current role. So I was really doing a lot of coding on basically one project but now I'm a lot broader. Prior to Samry, I worked as a senior technical consultant at Enterprise Content Management software company and before that I worked in defense for a few years. So I guess the common thread throughout all my engagement so far has been dealing with sensitive data has really been front and center. So when should I engage ICT? I guess the short answer is early and often. So earlier is always better and there's probably a few key time points that I suggest. So one is like when you're brainstorming and thinking about an idea for a grant. The next is when you're actually starting to write that grant. When you get the tick and you get funding approval, that's a good time to engage us as well. When you want to kick off the project and then wrapping up the project as well is really important but it's probably overlooked a little bit. And actually doing the design for your project or your grant, ICT can help you estimate costs in the technology space. We can help you identify any roadblocks or any high-risk items that you're thinking about doing, things that we might need to like investigate a bit more. And it can also help us to start thinking about technical solutions to your project. So if you bring in a grant and you're not going to find out about six, nine, 12 months or whatever, we can start planning around our own capacity just if we think that there might be enough demand to do something new in our space. So when I engage with projects around this kind of stuff, there's really two main categories they'll look at. One is data, one is access. So by data I'm really interested in like what kinds of data you're looking to store. So if it's just, you know, server responses in text or as an image or as lots of images, video, how sensitive is the data? So, you know, is it identifiable? Is it just anonymous? Something that you've collected through SurveyMonkey or something like that? How much is it going to be? So if you're pulling data off an instrument, it might be like terabytes per day or it could be very small. So we've got to understand that. How are you going to receive it? So is someone going to rock up with a USB flash drive and give it to you or are you going to pull the data off an instrument or whatever? We have to understand that. Then during the course of the project, are you going to give the data to someone else, either like throughout the project or right at the end? If you're going to do that, we need to kind of come up with the best way to do that transfer. So, and that will be informed by the sensitivity and the size of the data. And lastly, you know, how long do you want to keep the data for? So in your ethics agreement, you might say something like we're going to keep the data for 10 years after the study closes or you might say you want to destruct it right at the end or you might want to keep it forever. So we need to understand that straight up so that when we can plan around, you know, backups and all kind of stuff. When it comes to access, I guess we're really interested in the categories of people that are going to be participating in your projects. So if it's all just internal staff, then that makes it a little bit easier because we can try and authenticate people against, you know, our own corporate directory. So normally active directory in most places. If you've got external people, we kind of need to understand their relationship to us. So if they're just people that are part of institutes or part of institutions, then that makes it easier because you could do something like the Australian Access Federation to authenticate everyone in to the same bit. But if they're overseas or commercial entities, then that makes it a little bit tricky. So we've got to understand that. Most of these details or these questions that we would want to talk to you about are way more complicated or low level than what you put in ethics applications. So just because you have an application or grant ready to go, we need to understand the next couple of levels down so then we can give you better costings and better estimates around time frames and resources. And also, I just encourage you, if your institution has a data measurement plan or information classification policy, definitely consult with them as you're preparing your grant. When it comes to solutioning, which is kind of my favorite part of this process, there's really like three broad categories of solutions that you'll be looking at. So one is you go and pay someone to run the thing for you. So SACS Institute has sure, which you might be aware of, that we should basically like a self-contained managed environment where you can do secure data analysis. We might pull a few off-the-shelf components into a coherent solution for your project. So one example that we've done in the past is you can have your survey or data capture stuff in RedCat and then do an exploit out of that into a stats program like SAS or R or SATA and then you can do your analysis there. Lastly, we might end up creating a custom solution for the ground up. So you might hire some software developers and get some shiny new servers and build some software that does exactly what you need. So when it comes to choose, I guess the answer is it really depends. So how much time you got? How many resources are you going to have to do it, both personnel and I guess funding as well? The initial ongoing cost structure, so how much money are you going to have in the first year versus the future years, which is I think what Helen talked about in her presentation. I guess also OPEX versus CAPEX is probably something as well because not all grants allow for both or there might be purely a CAPEX grant or purely an OPEX grant. How novel are the requirements? So if you've got some pretty special stuff you want to do, then that might take that managed server stuff off the table straight away. It might also take that integration of off-the-shelf components off the table as well, in which case you kind of look left with that custom solution, which has its own risks but also its own rewards and data sovereignty is another thing. So if you are looking at a managed service for example, you have to be really careful about where that data is being stored from both from on-premises cloud stuff, but also which countries are being stored in. And the ICT people that you're engaging with can obviously guide you in all this and they're going to be really key people to consult with. Last slide I want to talk about is cloud versus on-prem. So Luke has given a really good example of what you can do in the cloud now, but historically I think sensitive data is often had a requirement to store data on-prem. It's not necessarily something that you should just be by default copy-pasting into your ethics application. I think you really need to consider it really critically about whether you want to box yourself into that kind of stuff because a properly configured cloud instance is if not equal to or better than an equivalent on-prem service. So you've got a whole different set of risks obviously, but you can bolt it down. Luke is just a really good example of that. To be, I can't say that anyone would have a real problem with the story in the cloud. And there are added benefits. So you can get a better cost outcome often, particularly if you've got development environments or test environments that you don't need to have up all the time, but if you're hosting it on-prem and you bought a server, that server's there and it's going to be sitting there, but if you've got test environments in the cloud, you can turn them on when you need them and turn them off when you don't necessarily have to get charged when that's off. Availability, obviously you can do a lot of stuff around geographic redundancy and speed of deployment is great. So you can have an idea and set it up and get it done on the same day. You don't have to go out and procure a server and wait weeks or months for it to get racked up. And a lot of those environments are already certified to protected status already and they've got a little table there from protected security about that means, but it is, you know, like you can store reasonably critical data in those environments already without doing much extra classification or yet work. It's my last slide. Do you want to hand back over to you, Nicola? Yes. Thanks. Thanks all. So we have some time now for questions and discussion. I'm just going to check the chat and see if we've had any questions so far, but if anyone would like to ask questions from our presenters, we can pop them into the chat. I had one to start us off because, Andrew, you mentioned that at the level of involving, at the point of involving external IT support, you really need to have that sort of lower level understanding of what's going on beyond what might be in an application. And I was curious from your experience, maybe from all of your experience, how often it is that you find that research teams maybe aren't at that level of thinking yet and how you negotiate that. That's a great question. I ask it as a former researcher, so I'm really, you know, making fun of myself. Sure. I think in a lot of cases people have thought about it, but they might not have put it down on paper. So what I would typically do external to a grant application is actually write up after I've engaged. This really drives the cost discussion or the cost estimate discussion and the resourcing discussion. So what I would typically do is go to that next level down and actually start documenting what I think the solution would look like and all of the caveats and risks and opportunities that would be there and put that back to the researchers before they submit their grant. Then we have got a shared understanding of what we think that next level down is. And then when we come to the next part of that engagement, whether it's going from brainstorming to submitting or from submitting to approved or whatever, we can revisit that document and then flesh out that next level so we can get a better understanding of what it is. And even just putting stuff on paper does start to tease out some of those questions. So I don't think anyone intentionally just goes out and doesn't think about that next level down. But I think it's helpful to start documenting that stuff because then you can kind of have a shared understanding between the researchers and ICT about what you're going to actually deliver if you're successful. Yeah, 100%. I agree. I think it doesn't, I suppose we'd ideally like the researchers to come and have a chat at that early stage before you 100% know everything. But at the same time, yeah, exactly. Writing, drawing out a diagram of what you're thinking sometimes really clarifies some vulnerabilities or sort of missing parts that haven't been thought through yet because the whole process, I mean, often doesn't even need to be fully thought through in order for the grant to be written and accepted. So you can very easily get quite far down a research project without actually having planned all of those steps and going back to sort of budget and communication. If the whole process hasn't been sort of clearly talked through together and mapped out, it's really easy to sort of fall into communication pit holes where there'll be the assumption that this sort of end point can be reached. But without the intermediate steps, which might require either time or funding or something like that. So yeah, so I mean, yeah, my personal preference is for diagrams for the either on a like a whiteboard or sent to each other over email of what that process looks like so that everyone can make sure they're on the same page. And then yeah, following up with a sort of document to go through each point really break it down. And then that can be sort of sent around by the research group as well to their collaborators to make communication easier. We've had a few requests Helen for would love to see examples of diagrams that you've used please Helen and then someone would be good to see the level of detail required and visual projects and system representation. I mean, I'm sure that maybe specific diagrams are specific to projects that themselves are sensitive. Yeah, I had a look so I've got one that I've just like quickly de identifying. So it's a, I mean, I suppose each diagram is really specific to who you're talking to and what this setup is what you're talking through what the project is, but also yeah, I think Andrew is talking about and Luther is well about roles and responsibilities. So it's going to look different if you want the external IT support to be effectively guaranteeing that you're meeting ethics requirements, then you're sort of handing over in entirely conceptually the sort of sensitive data management process to them. And so it's really important that you're both the research group and the external IT support both constantly on the same page and really communicating well and frequently about that. Whereas if the research group wants to just hand off sort of a silo of the project to an external IT group, then it's going to be on the research group to be doing a lot of that documentation. I personally would, even in that situation, still recommend that you go through the whole process with the IT team. And in that situation, if you just want to hand over a tiny part, your diagram will look sort of much smaller or much more specific. But also then that does mean that the research team has to be on top of all of the other components and how it maps to everything. So it does mean that you probably need some pretty strong internal IT capacity if you're going to do that. So in general, I wouldn't recommend it. But yeah, I'll show my screen and just show you this example one. So it is very specific to this project, but hopefully it'll give you an idea. So what I've got just as an overview here, you won't be able to really see much yet. It's just like this particular group has three different servers that they're working between. And we came in at that stage of the project where they already had a setup that had been sort of provided in a mishmash of internal and external collaborations. So the first thing we did was to map those out. And part of the purpose of this diagram was to indicate that the setup was a bit more complex than the research team realized it was and that the vulnerabilities were actually sort of scattered throughout the IT infrastructure. So I'll zoom in a bit so you can see. So this is the sort of their basic development process. So because the development process is so much part of the, I suppose, the security limitations and requirements of an IT-based project. In this particular case, I included the sort of development steps that they have so that everyone from their team was on the same page about what their internal members were doing IT-wise, which helped us then to be able to be like, look, if what you're wanting is for this particular section to be updated, what that involves as an external team is for me to do these three steps, which are reliant on a particular member of their team to approve before that can happen at all. So that was really helpful in that case because often the person who's funding the external IT support is not the same person who's doing any sort of local data work. Usually it'll be like the lab head or someone's senior in the group and often they'll not be the same ones doing the kind of data analysis within their team. So that communication between the person, I suppose, funding the external team and their team members was important for this part. So what we've got here is, yeah, a couple of different environments. Again, this is really focused on these kind of like flow steps and what they currently have set up. So what we've got is these are all sort of, in this case, automatic steps that are happening behind the scenes and sort of times in that process where we can intervene and do various things, steps that are required that are manual versus automatic, flagging anything that was not as they expected it was and off using this diagram as a discussion point, we then wrote down like a vulnerabilities list together and sort of a to-do list for next steps to improve that environment to do what they actually wanted it to do. For the other diagram, I can send around this document which had that transformation one. So I'll send that to you, Nicola. Fantastic. Thanks Helen. So I have a couple more questions. What can researchers do if their IT support, external or otherwise, isn't as nice as you three or become blockers? Any advice? Well, Andrew, you may be the best at this one, but I can maybe speak a little bit from experience. So we had a bit of certainly a lot of challenge with getting our systems set up, particularly on the SA government network. And what we found was I think one part of it was actually building the relationship with IT. So trying to understand what their requirements were and what their needs were. So when the discussion was about security, really what were they looking for? How could we actually come to them and have the discussion about what was appropriate for them? I think another part was also the kind of backing to use a word. So we did end up building a lot of relationships with clinicians and stakeholders and administrators to really start talking about what the value was in this case of going to cloud, really raising the discussion of why were we going to cloud? What was actually the reason for it? And then how were those reasons mapping to the IT requirements? So I think we're able to actually have that conversation from both an IT and technology perspective, but also from a business value and a research perspective. So initially, it was blockers for quite a while. It was actually really difficult for us to engage. SA Health is a huge entity of 50,000 employees. But after enough time and after really figuring out what were we asking for and why were we asking it, we were actually able to then have that conversation and it's going much, much better. And I think the people that we thought were blockers were actually really lovely people. So yeah, I think that was just a story that we went through. But maybe Andrew or Helen's also got some stories as well. Yeah, I guess an approach you can take potentially is so if you come along with a fully designed system that you want IT to implement, they might look at it and go like, well, we can't do this or this or this or this because we're not just set up to do it. So you might have to just take a step back and try and think about what you're actually trying to achieve from a like a requirements, almost like a first, first level requirements step, and then let them, I work with them to guide you through what they can do, what the art of the possible is, because often, you know, someone might be saying, oh, coming to you and being like, we want to do something in Docker and Kubernetes and blah, blah, blah. And your infrastructure or your IT team might be like, we can't do any of that because we don't have any of that set up. So you need to go back to the drawing board. So if you're in a bit of a constrained environment, you might want to think about not getting going so far down the path that you've got a technical solution for us, you really want to bring it back to what we're actually trying to achieve from the business perspective and be led by the ICT team around how you actually achieve that at the technical level. That would be my suggestion. Yeah, absolutely. I think a lot of the difficult relationships happen because there's so much stress, really. Also, IT professionals can't necessarily do, you know, like they'll have a set of skills, but they won't necessarily have done everything that you might like to use. So just having an honest conversation about what their limitations are in terms of, it might be timing or it might be skill set or it might be infrastructure limitations. I think that sometimes people are surprised to say if they want to store data that that would cost money. That often does surprise people, but it's a sort of a practical situation. You need somewhere to put it and either you're paying for someone's time to set that up or you're paying for the sort of physical place that that is stored. And that might be more of an ongoing cost if it's more of around the sort of physical storage, or it might be more of a short term cost if you're paying for the person. But all of that type of stuff. Yeah, exactly. If you come to IT with a request for a sort of a complete idea where you want to be really specific about how the actual IT part of it works, there might be limitations around that that make that setup almost impossible with your combination of sort of funding and sensitivity restrictions and things like that. So it's something that we will hear a fair bit is I heard in this conference that this dashboarding solution was really secure and I want that. So that's what we're going to go with. But they're not aware that the pricing that they've seen on the internet is just for like a single user license and that to then share it with other researchers or to do anything interactive for all the things that they want to do that require quite a high level of security and control, they have to pay a lot more money. So yeah, so not coming in with a really fixed idea. It's great to say I saw this thing at a conference. I really like it. Is there something like that we can do that's much more manageable for an IT team? But if they're being grumpy, you could actually just ask why. Like is this too strict? Like is sometimes the IT people you're asking are for the building and they're not necessarily supposed to be for like research projects in which case you might be asking them to go like really above and beyond and work a lot of overtime for something and you don't realize that that's not actually their job. So having a frank discussion about like I want this to be a good relationship. This is what I want out of this project. Is that actually something you can do? I think that would be a really good discussion to have. So thanks. Any advice on how non-technical researchers can find vendors or IT specialists that are used to working in the research space? To the uninitiated, a lot of commercial IT or data vendors on the market seem very business focused as this matter. Have opinions on this one. Unvised opinions? Like completely unbiased. You are first? No, and I go for it. All right. Look, I mean, I think word of mouth is really powerful. Talking to other people in your building and your institute or around the traps based on like other people that are involved in this forum, for example, can help. I think that something that sometimes gets overlooked, you talk to a vendor, they get, they send you, sell you some PowerPoint engineering or something like that and you get really excited. Then when the rubbish hits the road, you get a little bit, it doesn't match what you thought you were going to get. What I would strongly recommend people do is ask for referenceable customers from them and sit down and you know, if you're trying to do a data research project and they give you customers at a bank and that's what they think is their best referenced customer for you, then that's perhaps not a good fit. But if they can give you someone else that they've worked with in the past and you can talk to them and explain what you're trying to do and they can explain what they did and they give you a glowing recommendation, then that's a pretty good, you know, probably going to be a pretty good fit. But if you just talking to the vendor and you don't get a second opinion on that same vendor and then if they can't provide you with any referenceable customer that are in that same space as you, then that would be a warning sign for me. Yeah, totally. And I also think, I think sometimes people expect to be confused by the conversation with someone external from IT and that some people can be predatory and use that to their advantage. So if you're, I suppose, treated the same way as you would any contract that you were considering, if they, they should be trying to make you feel comfortable and they, you should be able to understand all the parts of the process and you should feel comfortable saying that you don't understand or that you are uncomfortable with part of the process or you don't think that sounds good. And they should work with you and be positive about it. And if they're not doing those things and they're just saying we'll fix it for you, that's a, that's a bad, I think, I think a lot of people get into trouble because they expect it to be confusing. So they just accept a confusing explanation. And then they can't pick up any warning signs. So the person should be, it doesn't matter how complex the solution is, the person should definitely be able to be like, this is, like this, if this is your ethics application, this is how we're handling this part. You know, the reason that that works is this and this and this and you should come out of that feeling really confident. And if you don't, then they're not the right person to be working with. Yeah. So in any kind of engagement when there's like a technical asymmetry in the relationship, like you take your card or a mechanic, if the mechanic can't explain to you why they need to change your doodad, whatever, I'm not a carpenter. But if they can't explain it in terms that you can actually understand, then I'd go somewhere else. Yeah, exactly. Brilliant. And thanks. One last question just quickly. We've got a couple more minutes. Do you see initiating engagement between IT and researchers as only the responsibility of the researchers? Yeah. Sorry. There's a lot of researchers at Samrine and I'm one person, but I'm trying to build as many relationships as I can with everyone that I meet. And if people know you, then we'll likely to think, oh, I need to just reach out to Andrew right now because I think we're at the point now when we need to have a chat because this is what we're thinking about doing. I think that, yeah, so, you know, IT can't, I think it's unrealistic to expect them to reach, be constantly checking in with every single researcher or every single research group, but at the same time, we have to build those relationships so that then people feel comfortable coming to us, not like they're going to come to us so we can say no to them because that's not the intent. It's never going to be the intent, right? Yeah, that would be my take on them. Yeah, I've got a thought of that as well. I actually also, I try to really approach researchers here. My background is in bioinformatics, and I do see a lot of the research also at Samrie where it could benefit from some IT support, from automation, from scaling up, from some more high performance approaches. So I think IT can look into what's happening at the research space and think, what can be done there to innovate? How can we support that and actually bring that discussion to them as well? I found that to work really well with a few of the people that I work with, and I think very often the researchers also don't know what's possible, and you can really bring some innovative ideas by having that discussion. So I do see the potential for a two-way relationship.