When a project or research question requires that your agency gain access to cross-agency data, various stakeholders may raise legal concerns or have questions about sharing certain data fields.

An MOU Inventory Checklist can enable the planning group or other stakeholders to analyze and resolve legal objections to the sharing of particular data up front.

The checklist is designed to help promote sharing administrative data by:

  • enabling agencies to better understand their administrative data elements and characteristics,
  • helping evaluate issues relevant to data sharing for current uses, and
  • analyzing uses that may differ from the original collection purpose.

Figure 1 summarizes the process from development of the MOU Inventory Checklist to integrating its elements into a Memorandum of Understanding/Data Use License.

Identify data sources and custodians, use those data sources to identify categories and data fields and identify program administered in the data source system, then use that information to complete a diagnostic tool citing governing laws, rules, regs specific to authorized access, usage, and retention of data. After you have the diagnostic tool completed, analyze and resolve conflicts and identify access and usage constraints that must be addressed; challenge those notes based on laws or regulations. Then incorporate solutions to comply with access restrictions and define usage requirements and incorporate that into your Memorandum of Understanding slash data use license.

The checklist below lays out the information one would typically aim to include in an MOU.

Table 2: MOU Inventory Checklist


Question

Additional Information

1

Agency


2

Program

The name of the program with custody over the data

3

Data custodian


4

Related program(s)

E.g., programs related to child care may be: Earned Income Tax Credit, Medicaid, etc.

5

Where are the data stored? (system name)


6

Is this the original administrative data source? (e.g., for Social Security number (SSN)-the original source is either the Federal Social Security Administration or the local jurisdiction's data collection.)

Yes, No. If no, what is the original administrative data source and cite applicable laws governing allowable uses and data sharing.

7

Data provenance

What is the history/the origin of the data? Where did they originate? Have they been re-purposed since their origin? Are these the original raw data or have they been curated? If curated, by whom and how?

8

Identify if the data are licensed

Yes, No. If licensed, specify the terms of use.

9

Funding streams related to the administrative data

Federal, State, City, other, identify combination

10

What are the contents of the administrative data that are collected and maintained? Identify the units of analysis and associated data elements that are collected by the program. (See Wulczyn et al., 2017, Appendix C, Table 2: Data Elements by Domain and Source.)

Examples of unit of analysis: person, encounter with program, place, time. Examples of elements by units of analysis: Person (age, sex, race), encounter with program (diagnosis, procedure, assessment), place (address, location, type), time (entry and exit dates).

11

Specify time period of the data requested.

Identify specific months/years of data requested.

12

Frequency of data collection and frequency of update of administrative data file

Daily, Weekly, Monthly, Annual, etc.

13

Identify all legal, regulatory, and administrative policies governing the data; provide applicable citations.

Federal Law, Federal Reg, State Law, State Reg, City Law, City, Reg, Court Consent Decree/Order, etc.

14

Provide text of laws referenced above.


15

Specify the scope of the legal, regulatory, and administrative policies applicable to the data and provide citations.

Identify applicability to data elements, for example: access, legal obligation to share, permitted uses, disclosure and re-disclosure, limitations and restrictions, exceptions, retention requirements, etc.

16

Specify specific categories of data to be shared and with whom (provide text and citation).

Yes, without client consent; Yes, with client consent; Yes, with qualifications (explain).

17

Identify any restrictions (legal, regulatory, administrative, other) regarding who can be an authorized user of the data.

Yes, No, With qualifications (explain).

18

Are their fields within the data file that can be shared while others cannot (i.e., security or confidentiality)?

Yes, No. If yes, list all fields and identify each with a yes, no. Provide citations.

19

Does the scope of the legal, regulatory, administrative policy, or other specifically address release of data with client consent?

Yes, No. If yes, provide cite and requirements.

20

If consent is specifically addressed in statute, regulation, administrative policy, or other, describe how it applies to the specific data (e.g., categories or type of data to which consent applies, time periods, expiration data, how data collected prior to consent authorization are addressed.)


21

Does the scope of the legal, regulatory, administrative policy or other specifically address minors?

Yes, No. If yes, provide cite and requirements.

22

Does the scope of the legal, regulatory, administrative policy or other address individuals who are not competent to consent?

Yes, No. If yes, provide cite and requirements.


23

Does the agency have any existing memoranda of understanding (MOUs) with other agencies, contractors, or third parties related to data sharing?

Yes, No. If yes, provide list and attach copies

24

Does the scope of the legal, regulatory, administrative policy, or other specifically address utilization of data for research and requisite protocols?

Yes, No. If yes, provide citations and specify requirements.

Adapted and used with permission from AISP Expert Panel Report: Legal Issues for IDS Use: Finding a Way Forward