If you’ve been following my blog to date, you can see the high level of forethought, work, and skill that go into putting together a multi-organizational data-sharing community partnership. I have seen talented, influential community leaders navigate these waters without fear, overcoming all obstacles in their path—only to come up short at the prospect of drawing up the data-sharing agreement (DSA).

There’s a mystique around the DSA. And while I agree the stakes are high, my goal in this blog entry is to convince you that you have more to contribute to this step of the process than you might think.

Step 1: Start With What You’ve Got

In the Quad Cities, when it was time to write our first DSA, we did what I recommend all of you do: we found a DSA from another community and adapted it to our own purposes. We had to change some of the details, of course (the data we were collecting, the kinds of data analyses we were going to conduct, etc.), but in the end, our final agreement ended up quite similar to its original source material.

Adapting another community’s DSA to our purposes taught me an important lesson: that there is a difference between the format of a DSA and its content. We copied that other community’s format, but the content of the agreement was all based on the partnership-building work we’d been doing for the three years previous.

My point is not that you don’t need the lawyers. You absolutely do: in the Quad Cities, each of our partner organizations’ lawyers went over the document with a fine-toothed comb before anyone agreed to sign it. My point is that you should bring the lawyers in only at the beginning of the process, to give you a laundry list of elements the agreement must cover, and at the end, to make sure that everything you’ve drawn up is legally sound.

When it comes to the middle part—laying out the details of how the partnership works—it’s not the lawyers, but you, who have sat through months and months of planning meetings, who’s going to know what to write. If you’ve built your partnership slowly and carefully, you’ll have quite a long list already before you even begin thinking of drafting a DSA.

Step 2: Divide and Conquer

To make this list more manageable (and to create a more practical DSA), I recommend you divide the list into two categories: 1) what you need to leave more fluid, with room to grow, and 2) what needs to be hard-wired into the system.

This distinction allows you to create a neat dividing line in your DSA. Some elements of the agreement might change often: every time, for example, you add a new partner, a new research focus, or a new data set. The rest are things that will change only rarely: only, for example, through a series of long and deliberate meetings, and voting approval from all the partners involved. It’s not that these things are set in stone; it’s that changing them will signal a significant shift in the nature of your project.

We’ll handle this second list – things that should be hard wired into your DSA – below. In the Quad Cities, we put all of these DSA elements into a single document that we call the “Standards of Practice and Operations,” or the SOPO. You can see a copy here, and I’ll refer to it in the rest of this post, so you can see the language and level of detail we used to address each of the elements in our “hard-wired” list.

Step 3: Define the “Hard Wired” Sections 

SECTION ONE: BACKGROUND INFORMATION.

This section of your DSA will include such elements as:

• Why the partnership is warehousing data? (see SOPO Section 1 & 2)
• Definitions of terms (see SOPO Section 4)
• List of partners and partner roles (see SOPO Sections 5, 6, and 7)

It may seem like just busywork putting into writing all the things that everyone has already agreed upon. But, just as I mentioned in the “Don’t just talk and listen—communicate” section of my blog post on partner engagement, it is easy (common, even) for different partners to have different remembrances of what was agreed upon and what parts of the project were assigned to who. Another reason is staff turnover: if a partner gets a new Executive Director, he or she will have a clear document outlining the agency’s role in the partnership. Spell everything out: not only will this encourage everyone to read over and agree to these points one last time before signing the DSA, but it will also make your DSA the final authority—the document everyone refers back to whenever there is a difference of opinion.

This section is also a chance to set the basic philosophy behind the project. In the Quad Cities’ case, for example, our school district partners’ greatest concern was that a public discussion of student performance data would lead to a comparison between districts in the local press. We assured the superintendents that this would not happen; this was such an important point that we included it right at the start of the SOPO, in Section 1.2. The only way our partnership would ever act contrary to this rule would be if we abrogated the SOPO and drew up a whole new agreement.

In the partner roles section of your agreement, list the roles of both partner organizations and of the specific individuals who actually do the work, collecting and processing your data. Don’t forget to include not just what each partner does, but who is responsible for making sure they do it. How often do all the partners get together as a group to assess the progress of the project?

SECTION TWO: STANDARD FUNCTIONS.

This section of your DSA will include such elements as:

• How is data uploaded into the system? (see SOPO Section 8)
• How is data stored in the system? (see SOPO Section 9)
• Who can request data analysis from the system, and what do they have to do to make such a request? (see SOPO Section 10)
• Who can have access to these data findings, and what can and can’t they do with this information? (see SOPO Section 11)

You’ll notice in this section that we go into painstaking detail. Again, the point is to be thorough: to create a document everyone can refer back to if there’s a difference of opinion later on. As with the first sections, above, the point is to get everyone to read, agree to, and sign off on these standard functions, so that each partner is clear right from the start, for example, about how easy or hard it will be for them to make use of the data-sharing project for their own purposes (if at all).

In the Quad Cities’ SOPO, we spend a lot of time on the distinction between an internal and a public data analysis. This is because the main point of our project is to gather data on community needs and test which interventions are best at addressing that need—all internal data analyses. Some of our social service agency partners, however, were willing to participate in the project only if they could sometimes publish these data findings as evidence of the long-range impact of their programs. This led to Section 11.2.2, which allows this sort of public release of data, but only under very specific circumstances and only under the supervision of the Data Warehouse project lead. Again: when you’re dealing with any element that made a partner uneasy, to the extent that you had to negotiate in the finest terms what was and wasn’t allowed, it’s best to put this all in writing in the DSA.

Other items of note here:

• Sections 9.6 and 9.7, which make it clear that, even when it is uploaded in the Warehouse, all data belongs solely to and remain under the control of the partner who supplied it.
• Section 10.2.1, which specifies that the Warehouse data can be used only for the purpose of conducting research. This ensures that all our data use conforms to the research provision of FERPA, which is what has given us legal access to individual-level student data in the first place.
• Section 10.5.3, which limits how small a population we can release data analysis for. If there are only 3 Alaskan natives in our records, for example, it becomes easier to identify those individuals in what is supposed to be an anonymous, aggregate sample.

You’ll notice that, up to this point in the DSA, that there’s nothing here the lawyers can generate. They can tell you what format it needs to be in, but only the partners themselves can fill in the content, because they’re the ones who negotiated these points in the first place.

This is only slightly less true for the final group of elements of a DSA:

SECTION THREE: THE FINE PRINT.

This section will include such elements as:

• Conflicts and arbitration (see SOPO Section 12)
• Indemnification (see SOPO Section 13)
• How this agreement can be amended (see SOPO Section 14)

This is where you’ll rely most on the lawyers. I would never, for example, have thought to put the indemnification section in our DSA—but of course indemnification is precisely what legal contracts are for.

Even in these matters, however, the lawyers can tell you what sort of information you need, but it is the partners who get to decide the particulars. For example, remember that the Quad Cities is a bi-state community, but Section 12.1 specifies that all arbitration must follow Iowa state law. You can imagine how are Illinois partners must have felt at this suggestion, and the negotiations that were required to settle the matter.

The most important passages in all this fine print is Section 14, which outlines how the agreement can be amended. Remember: you wanted the provisions in the DSA to be hard-wired, but not set-in-stone. A decade from now, if the Quad Cities data partnership decides, for example, that the restrictions on public data releases are too strict, this section will tell them how they can negotiate and draw up a new DSA. We’ve already put this provision into use: the SOPO is actually the 2nd DSA our partnership has operated under.

—

And that, basically, is it. DSA’s aren’t exactly a fun read, but for me in particular, it was very satisfying to write one: it was the finalization, the capstone, of over three years’ worth of partnership building and inter-agency negotiations.

One last note: I’ve included a copy of the Quad Cities’ SOPO so you can start exactly the way we did: using a pre-existing DSA as a model for your own. I ask only that you let me know what in the SOPO was useful to you, and what you had to change to suit the particulars of your own project. Working together, we can all come up with a good list of the different permutations of DSAs, making this process even easier for the communities who come along after us.

Community Data-Sharing 101 Blog Series

• The Importance of the Question
• General Warehouse Design
• Partner Engagement
• Building Partnerships
• Picking a Data Steward Partner
• Demystifying the Data-Sharing Agreement
• The Data-Sharing Agreement as a Living Document

To learn more about the Quad Cities’ educational initiatives and how nFocus Solutions is impacting the community, read the case study, The Quad Cities: Making Shared Data a Reality.