Embedding Guidebook
The Embedding Guidebook is a resource for staff members that will have access to work within external data systems, such as direct access to a state agency database. This documentation does not include specific onboarding tasks for embedding. Instead, the guidebook will help you navigate working across firewalled systems.
Please read closely and familiarize yourself with the unique constraints for embedded work. We include specific guardrails and general guidelines for reference. Nevertheless, the number one guideline for embedded work is ask whenever you are uncertain. In the meantime, there are a few main themes to keep in mind that appear throughout the guidebook:
- Compliance and regulations: The partnering organization will have their own set of rules (e.g., related to data access and privacy). Receiving credentials to access external systems may involve completing forms or trainings for these subjects. In addition to these organizational trainings, we provide more role-specific rules here.
- Pre-approved scope of work: Accessing data (both at Yale and externally) has been pre-approved for specific research activities. While this guidebook outlines how we operate across systems at a high-level, you may benefit from reviewing the scope of work documents related to your projects. The scope may be documented in a Research Service Agreements or IRB approval.
- Knowledge sharing: In addition to data access, you will likely have transparency into the partnering organization’s internal operations. Accessing sensitive information should be approached with just as much prudence as accessing sensitive data.
Navigating Across Firewalls
Embedded analysts get to wear two hats as both a researcher at Yale and an applied analyst in their embedded role. Maybe contrary to expectations, the purpose of embedding is not to perform research. Instead, it augments the research we pursue at Yale. By supporting government partners in improving programs and policies, we can spot opportunities for new research or shape our current research with new perspectives and knowledge.
In the diagram below, we visualize the importance of treating the systems as isolated environments with distinct activities performed in each.
Taking an example from the diagram above. In the partnering organization's system, we may support efforts to link important data across programs or departments. The linkage may inform administrative decisions and policies. By helping make this tool a reality, it also creates an opportunity to request newly available data linkages for continued research at Yale.
Which projects belong in which systems?
All research intended for publication or grant requirements should be performed at Yale using deidentified data extracts. In comparison, applied support for policies, programs, and technical tooling is performed in the external system. The applied support may involve generating evidence to support decision-making, which can feel similar to pure research. We view this work to diverge toward quality improvement activities, which Lynn et al. (2007) define (in the health care setting) as, "systematic, data-guided activities designed to bring about immediate improvement in health care delivery in particular settings."
Any single project you support should not be divided across systems. As a result, we need to be intentional about where we initially pursue projects to avoid future duplication. Nevertheless, we expect some information will need to be duplicated when it’s (1) appropriate to do so, and (2) relevant for both Yale and the embedded organization (e.g., high-level strategic documentation used for decision-making).
Which info can be shared across systems?
As we know, transferring data across systems is not allowed. But what about transferring information? (When discussing "information" below, we assume it is not disaggregated data.)
For information flowing from Yale, it's commonly the case that relevant information will be shareable to empower government powers. However, some situations may still require additional thought, such as sharing preliminary results from separate grant projects.
For information gathered through embedded projects, we err on the side of caution by sharing only what's needed. This is to protect both ourselves and our partners from unintended disclosures, privacy violations, or compliance issues. "Only what's needed" extends the "minimum data required" mindset that's also expected in our role. When running analysis, you know which data's required for you personally to do your job. For information sharing, we need to consider which info our non-embedded collaborators need (e.g., Yale Principal Investigators) to support appropriately.
Common items that are okay to share include information related to your project management, high-level constraints, high-level blockers, and deliverable drafts (by which time all data's aggregated). Sharing information like this typically happens over meetings or emails. It does not involve signing into Yale-credentialed applications while embedded to centralize project management or to share files across the firewall.
Items that you may encounter that are typically not shared from external systems include contractual language, internal memos, or code. If there are instances you think it's appropriate to do so, you should receive approval first. And, per the number one guideline, ask whenever you are uncertain.
Guardrails: Do’s & Don’t’s
We expect everyone to conduct themselves professionally within external systems, similar to Yale systems. However, some daily tasks that typically seem harmless should be approached with more caution in external systems, especially when it’s a government system. We highlight some of these items below.
| Do’s | Don’t’s | |
|---|---|---|
| Compliance Trainings | Do complete the external organization’s HR checklist required for embedded personnel | Do not assume the trainings are exactly the same as Yale |
| Applications | Do become familiar with the tools and applications made available with embedded credentials | Do not log into online applications using your Yale or personal credentials (e.g., Google, Outlook, Asana, etc.) |
| Installations | Do know how to request new software through the partnering organization’s support teams | Do not install new software without prior approval |
| Email & Messaging | Do know that any messages sent on government systems can be viewed by the public through Freedom of Information Act (FOIA) requests | Do not send code, data, internal findings, or other sensitive information (e.g., contractual info) to your personal or Yale accounts |
| Document Access | Do use organizational trainings, documentation, and reports to perform your role as expected | Do not access documents that are not relevant to your work |
| Data Requests | Do understand that you have skills and data access that are useful to many groups, both internal and external to the partnering organization | Do not provide data access or data extracts to anyone outside our team without express written approval from a supervisor at the partnering organization |
| Contractual Information | Do know that the partnering organization may work with multiple contractors relevant to your work | Do not share information about contractual agreements or contractual language outside the embedded organization without approval from a supervisor at the partnering organization |