THE FOUNDATION

In my last blog entry, I gave general advice about writing a Data Sharing Agreement (DSA), using the Quad Cities Data Warehouse project’s Standards of Operation and Practice (SOPO) as an example. I mentioned that you can divide DSA components into two categories: things you want to be hard-wired into the system, and things you want to leave more fluid.

It’s obvious why you’d want a partnership agreement to have elements that don’t change: everyone has to agree on how the partnership operates, or else some partners may not end up holding up their end of the bargain. A rock-solid DSA is the foundation on top of which you can base all the work of the partnership.

On the other hand, an agreement that is too rigid can be just as damaging to your project. The partnership cannot adapt as conditions change. The partnership has no room to grow.

There are two main ways to find that happy balance between a DSA that is rock-solid and one that is adaptable: through the creation of agreement attachments and through the creation of multiple, interlocking agreements.

ADDENDA

As I said in my previous blog post, when our partnership created our first DSA, we copied the format from a DSA from another community. This original DSA put a few key elements, not in the main body of their agreement, but in several attachments at the end. These attachments included:

• a) The research questions that govern the data warehouse.
• b) A list of partner organizations and their individual responsibilities
• c) The list of data points to be collected, and the schedule for these uploads
• d) A copy of the confidentiality agreement that all data warehouse personnel must sign to work on the project.

A quick look at (a) will help explain the advantages of putting these sorts of elements in attachments instead of in the main document. It will also show how this two-part structure helps us strike a balance between a DSA that is too strong and one that is too weak.

Our partnership has access to individual-level student data thanks to a provision in FERPA that lets school districts share these data for the sake of conducting research. Because of this, it was vital for the partners to agree upon (and codify in our DSA) exactly what research questions we were warehousing data in order to study.

However, we also knew that, in any good research project, answers often lead to additional questions. DSA’s take a long time to negotiate, vet through the lawyers, and get approval on from all the partners’ boards and oversight committees. Going through this process every single time we want to adjust our research framework would prevent our data warehouse from reacting quickly to new situations that may arise.

Instead, whenever the main body of the DSA mentioned the project’s research framework, it referred the reader to the attachment where the framework could be found. The rule itself never changed, but the instructions on how that rule is implemented could change as often as the evolution of our partnership required it.

Similarly, the other attachments in our original DSA allowed us to (b) add or remove partners, change partner roles, (c) collect new data sets, alter the schedules for data uploads, and (d) alter the partnership’s confidentiality agreements when the addition of a new partner or data set required it. In the broadest sense, the inner-workings of our Data Warehouse project never changed, but with the finer points we were able to make changes where needed—and, more importantly, without having to revise the entire DSA.

FORM FOLLOWS FUNCTION

Or so we thought.

At the time we wrote our first DSA, our Data Warehouse was designed to do just one thing: pool data from multiple school districts. Because of that, our DSA needed to be an agreement between only three partners: the United Way overseeing the project, the institution of higher education (St. Ambrose University) serving as the data steward agency, and the eight school districts in our community.

The problem is, once you build a better mousetrap, everyone beats a path to your door. Once we had a working Data Warehouse, other potential partners—educators, social service agencies, funders—came forward with ideas of other data sets, other research questions, other ways in which our project could serve the community.

Already, before we had even brought our project to full scale, our DSA had become obsolete. The issue was not just that we had more partners: we had more different kinds of partners. Our original DSA had one overall purpose: to make our Data Warehouse FERPA-compliant. That was all good and fine when the only signatories were school districts. However, it provided no guidance for how the partnership should handle data from social service agencies or funders—or, more importantly, how the social service agencies and funders would handle data from the school districts.

The easy solutions would have been just to create a larger DSA. Such a document would have had two serious drawbacks. First, it could easily have ended up being over fifty pages long, with only a handful of those pages applying to each type of partner. Second, the next time we added a new kind of partner (for example, an entity whose data is governed by HIPAA rather than FERPA), we would have to rewrite the DSA all over again.

However, there’s no reason why every element of our project had to be covered by a single agreement. The opposite makes more sense: the FERPA-compliant agencies would sign an agreement that specifies how the partnership handles FERPA-protected data, the HIPAA-compliant agencies would sign an agreement that specifies how the partnership handles HIPAA-protected data, and so on.

Then all that is necessary is that there be a central agreement that sets the most basic, set-in-stone rules and restrictions of all data-sharing activities. In our case, this is the SOPO. The SOPO outlines specifically how data is uploaded, stored, accessed, and disseminated. Notice, however, that there is nothing in the SOPO that indicates what sorts of data will be uploaded. That information now appears in the different partner-specific sub-DSA’s.

This system is infinitely adaptable. We can create new sub-DSA’s for every new situation, group of partners, or research focus, so long as all of these sub-DSA’s always operate within the overall framework of the SOPO.

In addition, if any one particular partner—one of the social service agencies, perhaps—has confidentiality restrictions of their own, they are free to draw up their own DSA for the partnership leaders to sign, so long as this agreement also requires that all partners adhere to the basic rules laid out in the SOPO.

To date, we have only two sub-DSA’s:

• a) The FERPA DSA : an agreement between St. Ambrose University (our data steward partner) and the school districts, outlining the safeguards the University will put in place to protect the districts’ FERPA responsibilities, and indemnifying the districts in case there is any breach.
• b) The Social Service Agency DSA : which each new social service agency signs, agreeing to specific restrictions on how they can use data findings that are based on the districts’ FERPA-protected data.

Viewing these documents along with the SOPO will give you a full picture: we have created a structure where all the pieces interlock, but any one of those pieces could be renegotiated and redrafted without requiring other alterations throughout the overall structure.

CONCLUSION

The Quad Cities Data Warehouse project’s three current DSA’s are only the second, third, and fourth I’ve ever written. There is very little remaining in these documents that came, unchanged, from that original source DSA I cribbed from three years ago. But that was the point: the only way to learn how to write DSA’s is to start writing them. If you let the form of your DSA’s follow the function of your project, you’ll be surprised how fast you learn, and how quickly your DSA becomes unique to your community and your partnership.

(Just be sure that you have a lawyer check over your final product before everyone starts signing.)

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.