Speaker 1  0:00  
Afternoon and welcome to today's webinar, data transfer and use agreements presented by Autumn. My name is Sandy Spiegel, autumns Professional Development Manager, and I will be your staff host for today. This is the second in our five webinar series on agreements and disclosures and we look forward to having you join us each week. All lines have been muted to ensure high quality audio and today's session is being recorded. If you have a question for the panelists, we encourage you to use the q&a feature on your zoom toolbar. If you have a technical question or a comment, please feel free to use the chat. Should you need closed captioning during today's session, the zoom feature is turned on and available on your toolbar. Before we begin, I would like to take a moment to acknowledge and thank autumns online professional development sponsors, Marshall Gerstein, IP and the Michelson Institute for intellectual property. We appreciate your ongoing support. I now have the pleasure of introducing you to today's distinguished speakers. Diana Boban started her career as a cell biologist at the University of Iowa Carver College of Medicine, where she performed bench research for 12 years. After a brief stint in procurement. She finished her MBA and transitioned to us division of sponsored programs in 2010. As a research administrator Diana likes to utilize her understanding of research to solve contractual problems for faculty. She currently is a contract administrator at the University of Chicago and is also the co chair for the FTD FTP sorry, data transfer and use agreements Working Group. Christopher Martin is a contract negotiator with Rutgers, the State University Office for research, and has supported the research office since 2015. He specializes in drafting and negotiating data use agreements, sponsored research agreements, material transfer agreements and master agreements and serves on various data security and privacy task forces and committees within security and use requirements from the United States federal government, and identifies best practices for data stewardship and use. Previously, Chris has spoken at the 2019 Autumn annual conference presenting on chain of custody within the University of setting university setting. Please join me in welcoming Diana and Chris, we are so excited to learn from you both today.

Speaker 2  2:19  
Thank you, Sammy, can you advance to Aymeric Thank you, so that's gonna be the disclaimer. Briefly, all materials available as part of this webinar expressed the viewpoints of the authors or presenters and may not be shared by the presenters affiliated institutions or organizations, and may not be shared by all, the content should not be considered to be used as legal advice. If a party uses or relies upon the information or opinions expressed herein, then the party does so at his or her sole risk in Busan, tech presenters hereby disclaim all warranties expressed or implied, without limitation, all legal questions should be directed to each party's legal counsel. And with that said, we can go next slide for Diana.

Unknown Speaker  3:08  
Hello, everyone, and thanks for joining us today and giving us a little bit of your time. So you're probably here because of the recent proliferation of data use agreements that are being executed between universities across the country. We've seen this a great deal and those of us who are working with the FDP, for data stewardship issues, were answering that call with a great deal of resources and templates that you can use, you can check them out on our website, which is listed at the end of this talk. I'd like to start off by saying that working with data use agreements, it's kind of like peeling an onion, not so much that it's going to make you cry, but more that there are a lot of layers involved. And so often, it is very helpful to revisit information to ensure that you are deepening and broadening your understanding of these concepts. So we'll provide you with a good foundation today. And hopefully you'll carry on and learn more as you go. Now, some of you may be wondering why there is a box of tissues on this slide and others of you are going to wonder why there's a box of Kleenex is and that is to point out that data use agreements can be called many different things they can be called a DTU a data transfer and use agreement they can be called a data sharing agreement. They have a lot of means. The important point is to look at the at the terms and conditions that are contained within the agreement. Additionally, Doa has both Have a technical branded meaning and also a generic meaning. So in the technical sense, a Doa is a specific type of data use agreement that is used for healthcare purposes. The terms and conditions that are required for that agreement are dictated by HIPAA. And a business associate agreement or BA is often required. We're not going to discuss that kind of D way today, but I do bring it up in case you are negotiating with a hospital legal associate, they may get confused and be and want to refer to the technical type of D uA. So you may need to make that clarification. In your negotiations, we will be discussing at the generic type of D way. Specifically the kind for research purposes. These are most often used to exchange human data between institutions. However non human data could be used, could be exchanged under a DEA way. There are many different regulations, that gov that are applicable to these data use agreements, not just HIPAA, you also have the common rule and you have FERPA those are the three most common that we see for data exchange between institutions. There are many others. So please be aware of what kind of data you're exchanging. It is important to note that a BA is not appropriate for a Data Use Agreement. That is for research purposes. This is because HIPAA specifically exempts research purposes from requiring this kind of agreement. So data use exchanges, data exchanges can be very complex in nature, you can have data moving in many different directions between many different parties for one transaction, we're not going to get that complicated today, we'll keep it pretty simple for you. We're going to focus on a one way exchange of data. And we will be tackling the various issues from the perspective of the data provider. Also, throughout this talk, it would be safe to assume that we're talking about human data as we go through this, because that's the most common type of data that you'll deal with. So next slide.

Speaker 2  7:44  
So when we talk about data use agreements, it's useful to relate it to material transfer agreements, because they are very much related in scope and in the relationship of the parties. In a data transfer agreement and Data Use Agreement. A receipt, the recipient party is seeking for a provider to share certain items, either data or materials, and the provider is willing to share that with the recipient party. There is no expectation in these scenarios that the provider exercises any type of control or custodial relationship over the receiving party, and that the receiving party will use the materials as specified in the whatever limitations are in material transfer agreement or did use agreement in this case, to accomplish a stated purpose or objective. This slide has a number of examples where data and material are substantially different from each other. And I just want to highlight the two most important differences in that when you use materials, the materials are consumed by the receiving party. And if they do not consume them, they degrade over time there is a certain freshness with any type of expectation of materials with data data is never really consumed and may change structure or form. But the underlying data will always be accessible and maintain so when a providing party transfers data, they're never diminishing their ability to use the data. The data always remains with the host institution and also the receiving institution. Also data is a lot easier to transfer and then materials. So data can be transferred through email, secure file transfer protocols, or even shared network folders. materials you will have to ship through vendors couriers. There may be packing instructions, insurance requirements, you may even have to fill out custom declaration forms in order to effectuate to transfer materials. Data is a lot more transmitted. For. And because of that data is also a lot faster to be transferred and a lot cheaper to be transferred, we're seeing at least in our institution, that where material would normally be transferred, it is now being asked of providing party to provide the data elements that can be extracted from simple services done to the material. And this like details, other differences, but understanding that data is faster and simpler to transfer is real main takeaway of why it's different than material transfer agreements. Next slide.

Unknown Speaker  10:40  
So when I talk to research administrators across the country, one of their biggest concerns is how to perform the analysis to determine whether a data exchange is permitted, and how to properly structure the D way. So we're going to spend two slides on this. And we're going to look at this analysis from two different perspectives. This first perspective is looking at the various inputs that you will need as you work through this process. We'll start on the right with the green arrow labeled project design. For me, it's it's usually easiest if I understand what the what my PI is trying to accomplish with this data exchange? Who is giving data to whom? What will the recipient do with the data once they have it? And will the recipient be permitted to share the data with a third party? Once I have a good understanding of what my PII wants to do, it's then easier to obtain additional information from them to to perform the rest of the analysis. Next, I like to look at the data type that's being exchanged. What what regulations govern the data? Is it HIPAA data? Is it FERPA data? Will there be any identifiers included? I want to make a special note about coded data, if the if the data recipient will receive a dataset that has a code associated with it. And it is possible to use that code to track back to the original dataset and re identify the subjects who contributed the data. Then there's a special obligation that you need to include in the de UA, where the recipient promises not to ask for the code the key to the code, and the provider promises not to provide the key to the code. The remaining four arrows relate to the issue of ensuring a clean chain of title. And Chris will go we'll look at these more in depth a little bit later. First, you want to ensure that you have all appropriate regulatory or IRB approvals that apply to the type of data that you're working with. It's really important to have a good working relationship with your IRB office and your institutional privacy officer. You know, they may be the same office they may be separate. You usually want to have some sort of clearance mechanism to ensure that you are abiding by all promises that you may have made to a data subject. Moving up. As always, you need to know your institutional policies. Different institutions determine their covered entity versus non covered entity portion of their institution. This is important to you if you are an institution with a teaching hospital. It's also important to know what sensitivities your institution has, based on the type of work performed at your institution that will vary. Next, I look at the data source. I want to ensure that you know whether or not we own the data that we at least have permission to share the data. And that may involve looking at several related agreements you might have, you might be trying to share data that was obtained from another source. So you would need to research and find the original agreement that provided that data to you. If the data were collected under a funded agreement, you will want to check and make sure that the project sponsor did not impose any sort of strange requirements on the data. Next slide please. So now that you understand the the inputs into your For analysis, let's look at how we might approach our PIs to obtain information from them. So we will use the state the same list of six questions that we've always used. Since we were in elementary school, and writing our book reports. First, we want to look at who is the custodian of the data? Do they support this data transfer? You want to ask what data elements are being provided? Are you providing identifiers? You'll want to take this question down to a very granular level, not necessarily to get a full list of data elements that are being provided. But make sure you hit the salient ones make sure you understand, are they providing, you know, dates? Are they providing names? Are they providing, you know, elements of home address? Those are the sorts of questions you may want to ask. Where were the data collected? is a very interesting question. Because you can get at a lot of layers of information here. Where the data were collected could mean they were collected in Europe, which means the European laws around data protection apply. That would be usually GDPR, which unfortunately, we're not going to cover today. If the data were collected on your campus, and you have a teaching hospital, you'll want to know whether it was collected from your covered entity portion, which would make it HIPAA protected, or if it was collected from your non covered entity portion. Where are the data going? You know, not only who is the recipient institution, but where are they located? Are there any institutional or the international laws that might be at play here? Asking when we're the data collected is also very interesting. Often, our PIs will use a data use agreement when perhaps a collaboration agreement is more appropriate. So for example, if the data were generated, or if the data have not yet been generated, and the two PI's are wanting to work together and exchange data back and forth, you might be better served with a collaboration agreement than a simple D way. This is not a hard and fast rule. There's a lot of gray area here. But it's certainly a red flag that to tell you to ask some more questions. Why are we providing the data? Are we providing the data because we're required to under federal data sharing policy? Or are we sharing the data because we want to use this as an initial project that might lead to a more important collaboration in the future. This will help you understand what kind of leverage you have regarding the PIs desires. And then also, I always like to include in my D UA, a description of how the data will be transferred to the recipient. So typically, you know, the data are exchanged electronically, and it's usually done over email. However, I'm seeing more often that institutions will keep control of their data and host it on their own servers. And then give the data recipient a login access and perform the data exchange that way. That is perfectly fine. As long as it's adequate for your work, as long as it meets the requirements of your institutional policies, you just simply need to address it and make sure that it's clear and your your recipient understands this. So next slide please.

Speaker 2  18:58  
We're going to do a little bit of a deeper dive on their clean chain of title. So when you're providing data, you're you should be doing a clean chain of title analysis to ensure that there are no encumbrances preventing or restricting your ability to share the data with the receiving party. The first document you should look for that would probably have the most impact on whether or not there's any encumbrance is the informed consent. And this is the informed consent used in obtaining the data. This could be the gets assigned informed consent form that you would see typical with clinical trial agreements. But it could also be any information that is presented to the participant who's providing the data so the ultimate individual who is where the information is being solicited from to see if there's any restrictions or language in there that may prevent the future use or sharing of the data. Typical with online survey forms is the first page The landing page for the survey may have language in there, restricting the host institution to from providing the data to a third party for future research. When you're looking or when you're trying to dig through the informed consents to see whether or not there are any such restrictions, recommend that you reach out to your IRB, Institutional Review Board, to do an analysis on the informed consent to see if there's any such restrictions. You don't really want to do this within your tech transfer office, this is something that's best left up to this, the ethics boards to determine if there's any type of restrictions. You also want to take a look and see if there's any if the data was obtained through a third party through the use of a Data Use Agreement. This is where you have to ask the researcher how they actually append the data. If they created themselves, obviously, then there wouldn't be a third party to use agreement. But if we, if your institution received it from another party, then you have to look into see whether or not you have that agreement, then memorializes the transfer of data to your institution and see if there's any restrictions on your ability to share the data from there. If you are unable to locate it through your contracts office, feel free to reach out to that third party directly to see if they have a copy of the document that you can use to update your files and to influence and inform yourself on what you need in your data use agreement that's for you. Now, if the data was collected underneath a funded research agreement, you're going to want to take a look at that funded research project to see whether or not there's restrictions on your ability to share data. Certain funded research projects require data suppression of certain data elements. And other agreements also require you to post the data to well known repositories. There are some language in some agreements where they recommend that you direct any potential sharing of data that's supposed to be deposited underneath or into a repository to that repository. So you want to make sure that you check your research agreements as well to ensure that there are no restrictions or best practices related to the sharing the data. If the data was obtained underneath that click wrap agreement. These are the akin to basically the Terms of Services agreements that you'll see for when you install new software. This is where you have to kind of scroll down through pages of text and just hit OK or continue. And you accept the terms. These are non negotiable instruments that are being forced upon. You'll see this a lot of times with some of the data repositories where you can make where they make data freely available. But you have to sign these click wrap agreements to gain access to the data. Normally, under these click wrap agreements, you're not going to have the ability to share data, most of the ones I've come across have restricted or outright prevented the sharing of data that you received underneath that click wrap. It may be difficult to get a copy of a stuck record, click wrap agreements. And if you can't get a copy of it, I believe the best bet would just be to assume that you are not permitted to share that data, and then direct your intended receiving party have the data to wherever you got the data from so that we they can sign the click wrap and grab the data directly. And then the last source is if it's publicly available. If the data is made publicly available, this is something like weather data. Weather data is often made available to the public. If an institution seeking that information from you directly, there should be at least some type of analysis to understand why they're seeking that data from you directly. And then you want to confirm that the data is publicly available, because sometimes there might be suppression requirements or at least acknowledgement attributions that you may need to flow down to the data recipient. So in those instances, if the data has been publicly available, best practice is still to point them to the websites where the data is made publicly available, so that way the receiving party can get it directly from there. But if your institution has to serve as the providing party, you have to do the due diligence to make sure that any type of expectation is flowed down directly to the recipient. Excellent.

Unknown Speaker  24:29  
So now we get to talk about the pertinent provisions in the US. The first five bullets, those center on the data itself, they also they they cover the various things that a provider needs to inform the recipient of, namely, various obligations or limitations that might apply to the data or the recipients behavior with the data. So first, obviously, we need to insert the permitted use of data, the recipient should always have a clear understanding of what they are and are not allowed to do with the data. Since you've done a good due diligence and you understand what kind of data you are passing to the recipient, you'll understand what data security standards or applicable laws to include in the agreement. If the if the if the recipient is prohibited from sharing data with with third parties, that should be clearly indicated in the agreement. If you use the FTP template, the there is an attachment that addresses this and you simply check the appropriate box. Re identification of subjects of the data is generally discouraged. The default in most contracts, in most EU ways will be that it is prohibited. However, in those rare instances where it is an integral part of the project, you will want to put special attention around limiting what the recipient is allowed to do in regards to obtaining the subjects information, are they allowed to contact the subject? Are they allowed to simply know who the subject is that sort of thing. If the recipient intends to merge or link the dataset with another data set, that should be clearly identified in the description of the project and the permitted use of the data. I always like to say that this should be easily understood by a layperson, so that everybody understands what is in and out of scope for this contract. And then, because you've done your due diligence, and followed Chris's wonderful advice and ensured a clean chain of title, you should be able to give the recipient a representation that you have full authority and right to share the data as it is, as it is provided.

Speaker 2  27:24  
Thanks. The next one is data disposition, a termination or expiration of the agreement or the Data Use Agreement. You'll find that if you do your due diligence correctly, and there is your part, you receive the data from a third party, you're going to obviously flow down the data destruction requirements, down to now your receiving party to maintain compliance with your original data use agreement. If you created the data, and obviously there is no controlling document, you may still want to refer to the informed consent to make sure that there's nothing there that will influence what you might need to put into this terminology, or into this section. When you're thinking about at termination expiration, what happens to the data, most likely there's going to be required to destroy the for the receiving party to destroy the data. The question then becomes what standards do you use to determine destruction, whether or not you're going to have the receiving party certify that the data was destroyed. And then you might want to put in language to address Bona unknown copies of the dataset. So these are Disaster Mitigation copies or cloud computing backup servers, where instances of the dataset may be accidentally captured and stored. Without the knowledge of the receiving party's principal investigator or to your party as the provider. There are some instances where at termination or expiration of the Data Use Agreement, destruction of the data may not be possible. This is if you're depositing data into a larger repository, where the terms are as soon as you deposit it can be retained by the repository repository and shared by the repository, where sometimes the receiving party will be merging the data into a larger dataset. And it would not be reasonable or practicable, for the receiving party to locate the individual data elements that you provide it to that merge dataset to be able to destroy it from their retained version. In which case, if that presents itself, we would normally like to see that the years there's no specified expiration of the Data Use Agreement and only say that upon termination that the data could still be retained, as that would acknowledge that the parties understand that there's no effective means to locate and destroy the data that was actually transferred. Next provision want to happen there's Breach Notification In mitigation response, this is usually required for anytime there's human subject data, or anytime the data is highly proprietary. This is something along with in tech space where a lot of data analytics or data elements give certain companies more competitive advantage over others. And have you used that as a trade secret that you normally you'll see termed as, when you have see a breach notification requirements document or when you're going to insert it, the expectation is that there's always a reasonable duty on the receiving party to determine whether or not there's any breach in their data systems. And that if there is a breach that they would take immediate corrective action, they need to inform the disclosing party or you should have be required to disclose that there is a breach to you. The normal, accepted standard, and it's customary is somewhere between two to five business days after discovery of the breach, that the receiving party will provide notice to the disclosing party, and then sometime thereafter, the receiving party should specify in a report what corrective actions have been done, and the nature of the breach. This should have some basic information about what data elements were disclosed, and potentially to whom. You also want to make sure in that report, that the receiving party also specifies whatever type of corrective action they have done to cure the potential breach, and also to mitigate the response or damages. Then you also want to put in a provision, that's a disclaimer of the accuracy of the data. Basically, you're going to provide the data as is condition like you do in most other agreements, especially in pas. Most datasets contain some inaccuracies, and they're usually undiscovered. So you want to make sure that in your transcript, the data and disclaim any type of accuracy or completeness, that may be represented to the receiving party to the dataset. And then lastly, the liability for use and storage data. This is what normally is thought as the indemnification clause but I know some institutions are not able to indemnify so you can word it as a statement of responsibility with the receiving party acknowledges that they are responsible for all costs damages penalties, liabilities related to their use and storage of the data. This is very similar to what you would see for material transfer agreement where the receiving party would take obligations for all costs and damages associated to their use and storage of the materials you transfer to them. For health information, it is increasingly more costly to do the investigatory work in case there's a data breach. So you want to make sure that as the providing party if you're providing health information, that the receiving party acknowledges that they are going to take on the obligation, the financial impact to do the breach, notification and investigatory work. Because if you're it's subscribed by law, if there's over a certain amount of lives or individuals impacted by the breach, that there needs to be a notification requirement. Next slide. So right now we're going to talk about some unpopular provisions in data use agreements. And in order to really kind of flesh out this slide, it's useful to understand some attributes of data. And data is a recommendation of facts. And facts cannot be owned by a party. The way though the facts are displayed, organized and presented is different, because that infuses some of the author's or creators intellectual, creative and artistic thoughts into how that's being displayed to the recipient. As such, when you're thinking about a Data Use Agreement, the way the data is organized, the way the data is presented, that is the artistic creation of your institution. So you can present and preserve and protect that embodiment of that intellectual creation, that creative creation, however, how the recipient uses the data presented in that and how they analyze it, and what inferences and analytics judgments or innovations they create from that is separate and distinct from the artistic and creative contributions or thoughts of your institution in providing that data. So It's unreasonable to restrict or to demand ownership of new IP, new innovations that are created by the receiving party's use of the data. Mainly also, because as a providing party, you're not restricted or prevented from then using that data as well. What is customary and can be put into a data use agreement is that the providing party is made aware of any innovations or new technologies developed to the use of their data. And that if the data is used for any publication purposes, that the provider is cited as the provider of the data in that publication. Another popular provision is references to specific technology standards. And this can be either technology specific or company specific. This is just a growing realization that technology evolves. Year over year, we're getting more and more advanced. Anecdotally, I was able to research that in the late 1990s, a high end desktop computer would be able to break what was considered the industry standard for encryption in just over 2000 years. So it would take that desktop just over 2000 years to break that encryption. Currently, if we're still trying to break that encryption standard, a current high end desktop would be able to do that a little over a week. So what was considered best in class then, is not best in class now, and I know 20 years is a long time. For that comparison. The thought is that it does evolve year over year. So you do not want to specify what the current best in class standards are now, you'd rather refer to as, again, best in class what's reasonably exercise or maybe even cite to what other academic institutions use to protect similar situated data, something like that, where it's a flexible standard that allows and acknowledged for the evolution of technology standards to be interpreted in the in the development and application of that.

Speaker 2  37:11  
That provision. Also, I've seen ingredients and we should avoid using it is naming different companies. So one of the common ones I've seen is saying that people who use Citrix to access the data or a Citrix I think VPN access to data or remote access, you want to avoid mentioned company specific, because through often the company is acquired or renamed or rebranded themselves. So that way, the recital to them has to then be reinterpreted. Also technology can get outdated. Sometimes the companies are built upon different technology platforms that can be that can become outdated. So, you want to have use references to standards that will evolve with the agreement, and can be interpreted on a continual basis. So that way, it allows for a continual improvement of the standards being developed around the production of data. You do not want an hour on a question this at the bottom is you do not want to use a Data Use Agreement as a short form way to establish a collaboration agreement with another party. If the parties are going to be collaborating on the analysis of data and sharing of data, you should be instructing them to develop a are your institution should be developing a collaboration agreement. In the collaboration agreement, you will obviously address things such as joint IP, and joint publication, amongst other things. In a Data Use Agreement, you're really not getting joint IP joint publications. It's one directional, it is the receiving party that's receiving the data and will be analyzing the data at their own direction. So those terms do not come into or are not typical to a Data Use Agreement. Those should be in a collaboration agreement. If you see a reciprocal Data Transfer Agreement, be highly suspect. That's usually the first step into trying to navigate around a collaboration agreement. And you may want to direct the university into exploring that as the best contract vessel for this relationship. Sometimes there is an underlying collaboration agreement that addresses joint IP joint publications, except that they did that collaboration agreement was silent on the sharing of data, in which case then a reciprocal data transfer agreement would obviously be necessary and recommended. Next slide.

Speaker 2  39:51  
These are varying factors that impact the value of data. And I think it might be useful to just go to the end Make sure first to understand the hierarchy of how data is processed. So the top picture you have is a large pile of unsorted Lego blocks where it's a different amalgamation of sizes and colors. This is akin to us having raw data. This is data that has yet been touched. It's difficult to do any type of analysis on it. It is very unorganized. The one right below it is sorted data. So this is where the Lego bricks are then sorted into different piles by color, again, allows for some analytics to be done on there to be your data that's sorted. But it's not the most user friendly. The one below it is arranged data. So these are data bricks that are correlated by size. And by color. This level where you're at that range, dataset level, is where you're going to see most of your data sharing. This is where you have your data elements are organized, they have the same units, I'll click to call it. So like if you're doing blood pressure, it's the same measurement requirements. Like if you're doing temperature, it would still be all Fahrenheit or Celsius, world Kelvin, if you're doing physics, that's the level where you're gonna be doing your data sharing. And that's level where most data analytics and analysis is done. When you get down to the presented visually, again, that's now the infusion of some type of creative thought process, and intellectual capacity in the creation of that end result. So that is where your IP is installed. And usually, that's not the level that's going to be shared with other individuals under a data sharing agreement that will be under a publication. To the right now we You see, there's a list of different variables that can impact the value of the data. Some are innate to the dataset. So when you've created the raw data, it those are predetermined. So that's the size, the rarity and the freshness. There are others, though, that you can increase the value of the dataset by exercising some level of control and some efforts. So that is, you're increasing the usability of the data. And that may be as Diana pointed out, if you're posting the data on a shared portal that has built in analytical tools, then all of a sudden, now your data becomes a little bit more valuable because you make the analysis easier to do. Also, if you have a robust can attach a chain of title or clear use in your previous agreements that you use to aggregate the data. It makes it easier for you to share the data and more comforting for the receiving party to get the data from you. Because you're able to make those representations with some greater authenticity, it increases the value of the data. Also, if you are compiling data from other foreign jurisdictions, so again, if you're compiling data from or aggregating data from, say, GDPR covered countries, and you're hosting it locally within the US, it makes it easier for other institutions to ask you for the data, as you comply with the GDPR standards on getting the data and aggregating it here locally in the US. And then you'll have some province to ensure that you still maintain compliance with GDPR, but still share it with your other USPS institutions, there's a value there as well. And then lastly, there's accuracy, which to a degree is inherent in the data itself. But likewise, there are some variables that you can vet to make more accurate. After you determine what the value of the data is, it begs the question of do you charge a party, the recipient and sharing the data with them. Needless to say, there's no best practice on this yet. You want to, obviously, take a look through your clean chain of title analysis to make sure there's no restriction on your ability to charge for the data. But then when you get to that point of whether or not you want to charge, you should take a look at the optics of whether or not it would be beneficial for your university to actually charge for it. You might want to take a look at the stature of your of the receiving party as it may, if it's a for profit company, it may be more palatable to charge for the sharing of data. And then when you get to the cost, there's a decision on whether make Do you charge reasonable commercial value? Do you charge cost in the creation of the data and the maintenance of the data? These are things that the university your university needs to decide on a case by case basis. And we really can't really use Excel In or venture, what's best practice for each party at this time. Next slide. Here are, as Diana refer to some of the resources, Diana, do you want to go over any in particular?

Unknown Speaker  45:15  
Sure. So at the top of the list, we're really proud of the data stewardship website, we've got a lot of resources there, more will be coming. So please, you know, keep checking every few months to see what is new. If you want some information about HIPAA govern data, we have two links here, one from the CDC and one from NIH. They're both excellent and will help you understand what data protections are required for that type of data. Additionally, there are links here for common rule guidance for data that is about human subjects, and probably gathered under an IRB approval, but not subject to HIPAA. And then FERPA guidance is at the bottom. This is educational data. And there are some special rules that apply to that data. So when you get a DUI, a crossing your desk that deals with FERPA data, you know, this is this will be your resource. Next slide, please. So we want to thank everyone for your time here today. We hope you found this helpful. And we hope that you are now ready and eager to take on the next DUI that crosses your desk. And we'll turn it back to Sammy, so she can go over the questions for us. Yeah, absolutely.

Speaker 1  46:43  
Thank you both so much for going through all of the detail. We have a couple of questions that have come through the chat and the q&a. So the first the they're kind of related in the chat. So I'll tee them up both together. So it doesn't the FDP have reciprocal DNA template? And is it bad to use this, or perhaps some clarification on when to use a collaborative agreement versus the FTP, reciprocal de UA agreement? And I just saw a quick chat go out to the thread as well. The slides will be available in the autumn Learning Center. But I'll go over all of that in a second. So clarification on collaborative research agreement versus the FTP reciprocal, do you a agreement.

Unknown Speaker  47:31  
So I will take this and Chris, feel free to chime in, I would say it is absolutely not bad to use the FTPS reciprocal DNA template. I understand the confusion on this topic because it is a confusing topic. Like I said earlier, it can be a gray area when you're dealing with a data exchange versus when you're dealing with a collaboration. So Chris ended his discussion with talking about when you could charge for data, another time that universities often charge for data or not charge for data, but they will often ask for reimbursement of effort to prepare the data for sharing. So this would be a nominal fee, that would be you know, to basically cut to defray some of the cost of preparing data to share with another institution. If you see that charge, and it is particularly high. Or if you see one party imposing a protocol onto another party, you might want to ask some more questions, because those would be clues that perhaps you have a PII who is trying to use a D UA instead of a research agreements. So what it really comes down to is, are the parties performing work? Or are they sharing data? And that can be that can be a difficult conversation to have. Yeah,

Speaker 2  49:09  
I agree. If you see abnormal charges are abnormal term terms. If you see something along the lines of that looks like services or collaboration based, something like weekly meetings, monthly meetings. Again, that would be my indication that this is a something that needs a collaboration rather than a reciprocal Data Transfer Agreement. Especially maybe you also can see the parties or like three parties that have existing relationships, you know, with the PI's, then again, this may be something more akin to a collaboration agreement. For the FTP templates, obviously, yes, you can use the FTP templates. There are reciprocal data transfer use agreements. They're one way once the website is all the forms are fillable PDFs. And we, the FTP working group was heavily influenced by By the terms and provisions in the bottom up MTA. So a lot of the provisions, you'll find their expectations are one to one to the UB MTA. There are a lot more fillable fields with data because there's some nuance to it, we have basically a description of filling out data. Don't make the assumption, though, that every institution subscribes to using the FTP DT UA, I know firsthand of a couple institutions that are not willing to use a the FTP form when they're providing data. There are some provisions regarding there's no indemnification specified in the agreement. And then likewise, there might be some type of they want to see additional language related to securities. What is asked, though, is if you do use the FTP, DT UA, any other templates which are one way reciprocal, there's also attachments on to it, that if you alter any of the terms, you remove the FTP header from it. So that way, the receiving party knows that at least some point one term has changed. And that way, they're just not, you're not potentially displaying that this is the original template when you actually did modify something with a lot of our sub award agreements, and well FTP developed sub award agreements. So that says, When NIH gives save money to one institution that now has to award it out to a bunch of other ones, to do a project. There's also an attachment to now that agreement that allows for the data transfer. It's a short one pager versus the due to a through FTP, which is what six pages Diana

Unknown Speaker  51:34  
about that? Yeah, something like that.

Speaker 2  51:37  
So again, it's a short form, it specifies it, what needs to go in, I would say, try to acquaint yourself with it. They're highly usable. They're very user friendly. I have rates of success in both receiving and sending out using FTP DTA. For projects, they seem to be routinely accepted by most parties.

Speaker 1  52:03  
Thank you both. Um, another question that I have here is that when we're allowing data recipients to have access to data, via our own servers, are there any special issues that we should be considering?

Unknown Speaker  52:17  
So yes, I would say the first stop you would want to make is with your institutional IT department to find out what sort of process they have to allow that sort of a login, most universities do allow it, but check your institutional policies. The other thing is, you could handle this a couple different ways. I see seen well, I've personally handled it where I use the FTP template and simply in the section where you detail how the the data will be transmitted, you simply make a statement that a login will be provided and the recipient will be permitted to access our servers. I've also seen relationships where it's a simple one page agreement, less of a Data Use Agreement and more of a an access agreement and it access agreement. And the thought behind limiting or removing the data protection terms there is that because as the provider you have control over when the the recipient can access the data, what they can see. And you can cut them off if you decide that you no longer want that relationship. So there are two ways you can go about doing that at least. And, you know, find the one that suits your institutional needs the best. Yeah,

Speaker 2  53:50  
I would just add, if you're the provider, and you're giving access to your platform, to share data, you're not going to put into a language in there about the storage of data that you're going to want to receive important to acknowledge any type of damage or liability because at that point, the data has never been stored or transferred to the recipients being made available. So you could still allow for that the use of the data, you'd want to have the recipient bear all obligations costs, liabilities related to that. But beyond that, you know, it's it doesn't make sense to have it where they're gonna acknowledge storage because they're not going to be storing it. Also, if you're on the recipient side of it, you also want to make sure that whatever tools available on that platform is acceptable. And also if you want to have that data available to merge it with other datasets, you really have to make sure that whether or not that platform can cross talk with other platforms, so that way you can merge the dataset. We have gotten into institution or instances where our researcher has either agreed or permitted a shared access. Again, log into our store refers to seeing that they only have read access only just to find out that it wasn't sufficient for the party's research purposes just to have that level basic level of read access. Also, a lot of times with accessing the servers, there's usually a cost associated with it. And it's not insubstantial, because normally you're paying a third party provider to ensure that it meets certain security requirements. So there are costs with in higher costs with having usually getting access to a secured cloud server, or cloud providers secure provider for where you're storing the data.

Speaker 1  55:38  
Great, thank you both. It looks like we have time for maybe another minute or so if attendees have any final burning questions that they want to submit. While we wait for that, I guess I will just ask Chris and Diana, each of you if there's kind of one big takeaway or point that you want attendees to leave today, remembering or driving home, I know we've covered so much, do you think that there's one kind of one highlight or important facet to think about before we let everyone go this afternoon?

Unknown Speaker  56:08  
I will jump Oh, go ahead, Chris. No, no, I

Unknown Speaker  56:11  
was gonna say You go right ahead. I'm still trying to ruminate on it. Sorry.

Unknown Speaker  56:16  
Both. I would say that what I normally tell people as they are learning to negotiate data use agreements is that start with the project being performed. Once you understand that, it is a lot easier to know what further questions to ask what other additional information to gather, and then you can start to structure your DUI.

Speaker 2  56:46  
Along that, I would say when I'm training, at least in office staff on data use agreements and how to negotiate. The one thing I want to echo is don't check common sense at the door. So sometimes what is legally required for the protection of the data may not be sufficiently the law may not have been sufficiently caught up to what is reasonably expected. And I've used the example of sometimes classroom recording that is somewhat de identified, but at the same time is somewhat readily identifiable. And even though there's informed consents and everything, it allows for a potential sharing of it, or at least in a workplace scenario, you still want to have protections on even though you may fit all the legal requirements, if they may not be sufficient to adequately protect what the reasonable person would think that the data will be protected with. So do not check common sense at the door, even though you may hit all the legal requirements, you may want to evaluate this totality of the circumstances and say, Should we be requiring more? Is it worth it for the university to require additional restrictions that are maybe small and reasonable. But additionally, it would behoove the university to observe and so that you should always be in a position to make sure that what you're asking for is reasonable both as the providing party and the receiving party. And I view this as a good data use agreement will allow for a reciprocal transfer if you reset or basically replicate the same terms and just change the defined parties at the preamble that if you're willing, as a provider to accept the terms being passed down to the recipient, as if you were the recipient, then to me that's a hallmark of at least a good starting point, or at least a good agreement to use for the transfer of data.

Speaker 1  58:37  
as well. Excellent. Thank you both so much for that, and I don't see any additional questions that have come through. So I will say on behalf of autumn, thank you to both of you for such an informative discussion. And thank you attendees for joining today and participating your q&a. As a reminder, a recording of the webinar will be available on the autumn Learning Center within a few days of this event and is included in your registration and the copy of the slides will also be provided there. And the session from week one if you've registered for all five sessions in the series is already posted in the autumn Learning Center for you

Transcribed by https://otter.ai