Design and Implementation of a Secure Computing Environment for Analysis of Sensitive Data at an Academic Medical Center

Abstract

Academic medical centers need to make sensitive data from electronic health records, payer claims, genomic pipelines, and other sources available for analytical and educational purposes while ensuring privacy and security. Although many studies have described warehouses for collecting biomedical data, few studies have described secure computing environments for analysis of sensitive data. This case report describes the Weill Cornell Medicine Data Core with respect to user access, data controls, hardware, software, audit, and financial considerations. In the 2.5 years since launch, the Data Core has supported more than 200 faculty, staff, and students across nearly 60 research and education projects. Other institutions may benefit from adopting elements of the approach, including tools available on Github, for balancing access with privacy and security.

Introduction

As academic medical centers generate and acquire data for clinical care, education, and research, they need infrastructure to enable secure analysis. Faculty, staff, and students require access to sensitive data from electronic health records (EHRs), payor claims, clinical trials, genomic analyses, and environmental sources, while institutions need to protect sensitive data in accordance with federal regulations, such as the Health Information Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH), third-party data use agreements (DUAs), Institutional Review Board (IRB) protocols, and other privacy and security measures. Analysis of sensitive data using physical desktops and laptops managed by institutional information technology (IT) departments represents a source of risk, particularly in the event of equipment theft or inappropriate disclosure. Institutions need approaches that balance risk and flexibility to support faculty, staff, and students.

One approach to address the problem is a secure virtual computing environment. To our knowledge, very few studies have described infrastructure for secure analysis. The University of Utah described its adaptation of high performance computing (HPC) infrastructure to store HIPAA-regulated patient data for analysis by faculty and staff (1). Over a three-year period, the protected environment, which restricted access per IRB protocol, grew from three to 58 users. Although the study described technical infrastructure and early usage statistics, it did not detail the process for managing regulated data or plans for financial sustainability. As part of a broader illustration of privacy principles, PopData British Columbia described usage of a secure remote computing environment for access to health data (2). However, the system allowed access only to data sets previously de-identified through a separate process; no identifiable data was permitted. Furthermore, the study presented limited details of the technological approach. Neither investigation described use of resources to support education.

Additional description of successful secure computing environments to support research and education can inform practitioners and academic evaluation efforts. Compared to studies of clinical data warehouses (3-10), considerably less is known about the design and implementation of secure computing environments for sensitive data. This case report aims to describe a successful approach to secure computing for sensitive data at an academic medical center.

Methods

Setting

Weill Cornell Medicine (WCM) is the patient care, biomedical research, and biomedical education campus of Cornell University. Located in New York City on the Upper East Side of Manhattan, WCM has more than 1,000 faculty physicians who practice in the Weill Cornell Physician Organization, a multispecialty outpatient group with more than 20 locations across the New York City area, and who have admitting privileges to New York-Presbyterian Hospital (NYPH), a long-time teaching affiliate. For documenting patient care, clinicians use EpicCare in the outpatient setting and Allscripts Sunrise Clinical Manager (SCM) in the inpatient setting. In addition to patient care, WCM has more than 400 faculty members with primary appointments in basic science departments. More than 20 core facilities provide instrumentation and services to advance discovery efforts. In education, Weill Cornell Medical College provides undergraduate medical education, and Weill Cornell Graduate School of Medical Sciences offers seven doctoral programs and five master’s programs. Of note, the Department of Healthcare Policy and Research (HPR) provides master’s tracks in biostatistics and data science, health informatics, and health policy and economics. Additionally, Cornell Tech, a partnership between Cornell University and the Technion - Israel Institute of Technology, is a technology- and business-oriented graduate school located in New York City with health-focused programs. Across the tripartite mission of WCM, the Information Technologies and Services Department (ITS) provides end-to-end physical and virtual electronic infrastructure, and the Samuel J. Wood Library, a division of ITS, works closely to deliver information resources.

The initial motivation for our work was HPR requiring a secure computing environment meeting HIPAA standards and other regulations to analyze identifiable data from Medicare, WCM/NYP health systems, and other sources Although Cornell University provides a secure virtual analytical environment in Ithaca, New York, the facility is not part of the Weill Cornell Medicine HIPAA covered entity and thus not suited for many types of patient-oriented data.

System description

The Data Core from the beginning has recognized the need for strong communication with the user base in order to be agile, quickly meet user needs, be scalable, and financially sustainable. To accomplish this, WCM turned to faculty librarians, who work with research and clinical faculty, to take on data stewardship roles. The data steward who interfaces with users on a daily basis also is part of the library, and carries the strong customer service mentality that has long distinguished the library culture. This focus on user responsiveness and communication has created a service today that is responsive to user needs, to researcher reporting requirements, and to faculty using the data core with student classes for instruction. Because user needs are quickly accommodated, they more readily recommend the service and are willing to reimburse for resources they consume.

In describing the Data Core in this section, some common terms are employed in specific ways. First, users are end users, who engage in research or instructional activities. Second, service providers are internal to the Data Core, in roles that emphasize either curation (administration, metadata, policy) or operation (mostly technical support). Third, data providers are external to the Data Core and set the terms for the data sets they make available for investigator use.

As shown in Figure 1, the Data Core management framework seeks to maintain and document two primary states: the service itself, and project-wide confirmation of correct function at points of major change. The service state is addressed through two main life cycles (sensu ITIL models); one for projects and the other for infrastructure. The project lifecycle encompasses provisioning, operations, and deprovisioning for both users and data, with often repeating subcycles during operations (for example in elements such as access renewal via quarterly reviews). Of particular consideration during project deprovisioning are data use requirements on final handling or destruction. Infrastructure has a similar tripartite rhythm for hardware and software, with perhaps more explicit practice of additional ITIL lifecycle elements in design, transition, and continuous improvement.

Figure 1.

WCM Data Core management framework. Yellow boxes indicate the two primary states that are maintained and documented within the service. The actual service state (left panel) is comprised of two life cycles, each of which undergoes multiple iterations of the basic workflow indicated in the orange boxes at the bottom of the panel.

Function confirmation is based around a workflow consisting of the following elements: identification and definition of success, identification of testing that will evaluate whether the definition of success has been obtained, and establishing deadlines by which both the change and function confirmation are to be resolved. These conditions are determined in collaboration with the users, although standard project changes may merely require communication and acceptance of the established workflow.

Users

Authentication

All users are under central institutional identity management, which automatically suspends access on termination of affiliation. Users authenticate to the core with two factors, first with username and password in the identity management directory, then with a linked, external second factor in a commercial, cloud-hosted application (Duo). Present use of Active Directory has given ready capability for infrastructure integration, but a SAML layer is intended to facilitate use of native credentialing for external collaborators and thereby leverage more of the depth and timing available in their own institution’s identity management.

Authorization

Authorization has one common driver--HIPAA’s minimum necessary--and additional drivers that differ for users and service providers. For service providers, the key principle is segregation of duties: the curation team brokers user requests and approves system changes, but curation cannot execute those requests or changes, which are performed by a separate technical team.

Within this framework, user authorization is in turn built around two principles, applied to the extent required by data governance: users can only access data via the core; and from the core, they can access no other resources. These restrictions are effected first by selective group membership for users in the central directory, which allows for timed access for the duration of a course or research study, rapid removal of access in offboarding, and triangulation of data in central log aggregation (done with Splunk); and secondly by network limitations for computation and storage resources.

For even the most restricted projects, the one potential exception to such exclusivity is, when allowed by the terms governing project data, read-only access from multiple projects to on-premise instances of specific common data sets (e.g. a national index of providers). This arrangement allows efficiency in providing common data sets and uniformity of reference content, giving important curatorial control.

Process for requesting access

All new projects are initiated by a principal investigator, through whom all new users must be explicitly authorized. Additionally, for each project, all institutional review board (IRB) protocols and third party Data Use Agreements (DUAs) must unambiguously authorize the requested users for data access. The incumbent user must also sign a Data Core User Agreement (DCUA), agreeing to acceptable conduct within the Data Core environment.

The terms of the DCUA are usually bound over a one-year period, allowing Data Core staff the discretion to evaluate appropriateness of continued access of users, even when other governance documentation authorizes the user for a longer period of time. The DCUA indicates the specific institutional network fileshare and directories the user is authorized to access. This reinforces the intended design for data to be located in locations where it is replicated and backed up, as well as reducing the likelihood of files being placed somewhere in the system that becomes accessible to non-intended users. The user further consents to ensure all exports are de-identified (“disclosure proofed”), to operate within the parameters of all data use agreements, to notify the Data Core of any change in employment or affiliation status of users (or any change in project role), and to maintain valid governance documentation while utilizing the Data Core. The DCUA is also used to explicitly call out ITS’s monthly server patching schedule, so the user can acknowledge the temporary disruption to access and analysis that occurs.

The agreement is administered through the Qualtrics survey platform, allowing efficient dissemination and return of signed agreements, as well as maintaining an archive of all signed agreements. Access to the DCUA via two-factor authentication provides additional assurance that the agreement was read and agreed upon by the individual user, and not a proxy.

The Data Core monitors the ongoing validity of existing governance documents. All project governance documentation must be kept up-to-date, and the Data Core notified of all amendments, with an accompanying updated copy of the documentation. Governance documents are monitored to ensure that PIs are aware of pending expirations, and that the Data Core are informed as to any intent to renew the authorization. Failure to provide updated documentation prior to expiry of the existing governance leads to immediate suspension of all user access on the project, until appropriate authorization is again received.

Data

Process for storing data

Data are stored on a mountable fileshare system, allowing mobility of project data to the most appropriate computational environment. For security, connection to the fileshare is capable only from the designated computational environment. The fileshares are locally and remotely replicated on a daily cycle, as well as having four daily snapshots of the fileshare recorded and saved for a 30-day period, to allow data restoration to the nearest 6-hour time point over the previous month. The fileshare associated with each project is provisioned by default with three directory types. First, a read-only source directory exists into which all data are imported through the life of the project. This ensures the data integrity is maintained throughout the life of the project. Second, a work area directory exists for each user, which provides user-specific read/write permissions. Third, a shared directory has read/write permission for all users of the project, allowing the sharing of files between collaborators.

Process for extracting data

At various stages of the project life cycle, it may be necessary for a user to export a file (eg. figure or script file) for publication or dissemination. The user will therefore request to the curatorial staff for export of files from the Data Core, indicating the name and path of all files required.

The requested files are copied by the technical staff into a separate fileshare on the Data Core that is accessible only by curatorial staff. The contents of each file is then investigated to determine whether it contains protected information, or is otherwise prohibited from dissemination according to data- or project governance. Data tables are investigated to ensure the data type and unique values of each column comply with HIPAA safe harbor standards. All files are searched using regular expressions matching common PHI data elements (SSNs, dates, zipcodes, and email addresses). Finally, files are manually screened across their entirety to check for consistency of content type, identify additional tables, and inserted content. Evaluation is performed by an informationist certified to evaluate data against the HITRUST common security framework (11), which is built on the security standards of HIPAA (12,13), PCI (14,15) and NIST (16). The evaluation procedure is performed within a Jupyter notebook (17), allowing interactive searching of the file contents, and also full reporting of the contents identified. The final evaluation of each file as to the presence or absence of protected information, as well as its suitability for export according to the project governance, is also saved within the notebook.

This enables the data core to employ both methodologies established by the privacy rule (13) to achieve data de-identification: the “statistical” or expert method and the “safe harbor” method. These two methodologies have generally not changed since the privacy rule was implemented (18,19). Files that pass the export evaluation are then delivered to the user using a secure file transfer service.

Hardware

All resources, including network and host protections, are drawn from enterprise systems already architected both for the isolation and security of a covered component (WCM) within a HIPAA hybrid entity (Cornell University), and also for elasticity of expansion or contraction according to need.

Storage

Storage is provided at both block and file level, with mirroring to a remote site that can be used directly in the event of a significant failure. Block is provisioned when performance, software, or user profiles require it, but it is more expensive and is under progressive effort for reduction or elimination. File storage is provisioned for each project in three standard structures: read-only source data, writable individual folders for each user, and writable shared work. Both types of storage are given versioned backup, and deactivated storage can have an additional and separate archive copy.

Compute

Primary computation occurs via connection to a virtualized Windows desktop environment, to mimic that of most users and applications, which can be run from a remote site in the case of significant failure. Secondary computational environments for other platforms are provisioned as requested, e.g. for databases or non-Windows software; these are also normally virtualized with similar continuity arrangements, but still reached only through the Windows environment. Within the primary environment, each user has default shared access to four virtual CPU and 16 GB of memory, which has proved sufficient for most software and calculations but can be augmented on request. Currently, all resources are considered in use upon provisioning; however, all aspects of the environment are slated for review of self-service provisioning and more affordable on-demand usage.

Software

Standard

The majority of projects are provisioned within a Windows Server environment, affording the users a familiar interface for their work. Within the Windows environment, Microsoft Office Suite, Python, Anaconda (and accompanying standard libraries), R, and R-Studio are available. Due to the high demand for standard statistical software such as SAS, Stata and Stat/Transfer, the Data Core is able to purchase these licenses with often substantial bulk discounts, with the savings in license cost passed on to the PIs. The university similarly provides discounts for other packages such as SPSS, Atlas.ti, NVivo and MATLAB, which can also be leveraged for the Data Core. The tasks of license file installation and configuration, and license renewal, are managed by the Data Core centrally for all projects. Users are thus freed from the administrative burden associated with software management.

Custom

Package installations are performed on request, with updates as self-service as data access will allow. Full development environments are not yet a consideration. Unique software requests, requiring configuration between the Data Core project environment and an SQL database server, have also been established for some projects. This involves a series of consultations between Data Core curatorial staff, technical staff, and the users. First, the providers clarify the users’ required analytical/processing outcomes, which may include suggestions for software and workflows required. The technical team then determines the software and workflows which are consistent with project governance, security and technical provisions, and realistically achievable. With the users, precise definitions of successful execution are established, and a series of tests that confirm appropriate functionality are prepared; ideally prior to the receipt of the research data. The workflow then undergoes a series of iterations of testing and feedback, until success as defined previously can be reliably obtained, with clear instructions on what must be performed by whom in order to achieve it.

Process for monitoring system state, and function confirmation after a change of state

In order to assist efforts to track the system state and log changes, a PostgreSQL database was established. This database contains tables defining the current state of users, projects, servers, and software. Particular attention was paid to ensuring that the project table captures the elements associated with the life cycle framework in which we manage the Data Core. One table specifically stores governance document metadata including authorization date, expiry date, type of access allowed, users authorized, and the governance relationship to other documents (eg such as an amendment or update that supersedes an old gov doc. This allows computational assessment of projects that are potentially failing to meet their governance requirements, or in which a requested change would lead to a failure. Changelog tables to record all changes in state allow monitoring not only of who initiated a change and when, but allows us to track the user confirmation that the function required successfully passed testing.

In order to facilitate the population and monitoring of the database, an Apache2 / Django 2.0 web server was created for database access, modification and system monitoring. The Django web app is available as open source at https://github.com/oxpeter/data_core_manager. The website of first importance hosts a dashboard displaying various project configurations that require attention: Projects lacking appropriate governance documentation, or whose governance is expiring in less than 120 days (to allow 30 days for preparation and communication of any status change, and 90 days for execution of those changes); fileshare mounting configurations that would allow a user access to more than one project at the same time (thus allowing possibility of transfer of material between projects directly by the user); users who are not explicitly authorized within the last 9 months, to allow three months for execution of reauthorization and ensure that all authorizations are refreshed no less than annually; projects being onboarded or migrated from one server to another, and thus requiring confirmation of user access, environment function, and data integrity; and software licenses due to expire within 90 days, and thus in need of renewal.

To ensure accuracy of the database in recording system state, a number of audits are regularly performed. Weekly system reports generated for usage of fileshare storage, and server direct mounted space for temporary file generation. Server reports of CPU and RAM allocation, along with which fileshares are mounted, and which users are logging in to the node allow verification of the basic project and node states as recorded in the database. Quarterly reviews are performed to provide small granularity, touching on all the dashboard points above and emphasizing the continuing validity and security of user access to data.

Financial management of Data Core

In order to determine the basic charges for running the Data Core, the costs for staffing and minimum required computational resources were calculated for all projects. Direct staffing is provided by about two full-time equivalent (FTE) positions, split over six actual persons of either administrative or technical specialization. This distribution allows responding to changes in demand, by either changing the proportion of effort, or changing the number of persons. The service also utilizes 0.25 FTE of indirect staffing for execution of standard procedures by a broader range of technical staff. Considering the distribution of the number of users per project (Figure 3), a sliding cost scale was constructed, with a rapid decrease in the incremental cost of adding each additional user. In this way, we ensure staffing and resource costs are appropriately covered even by small projects, and also don’t disincentivize the addition of extra collaborators on a project. After 5 users on a project, each additional user is only $100 per year. Storage costs are passed on to the user without markup, according to the institutional rates for research storage services at Weill Cornell Medicine. Software licensing needs are tracked across all projects and combined with other institutional demand, to allow for bulk purchasing or license management that allows reduced costs. All these savings are passed directly to the users, allowing them to access common statistical software at much lower rates than they would be able to obtain on their own. Extra computational resources above the minimum requirements are charged according to the institutional rate, with an assumption of a certain average shared load across multiple projects. Projects on the lower end of the demand for computation, users, storage, and commercial software are able to run with full administration, technical staffing, and documentation for around $3,500 annually, while the high end has peaked in the $20,000 range. It is expected that further efficiencies in all categories of cost, especially in computation and storage, will lead to a proportional reduction in project costs.

Figure 3.

Distribution of number of users per project. This figure does not include the four classrooms, which had 21,25,43, and 45 users each. The “total project size” histogram (left) represents the total lifetime user count for each project, while the “maximum project size” histogram (right) shows the maximum concurrent user count reached for each project.

Direct funding by HPR recovered the costs of all non-staff expenses, and roughly half of all costs. The unrecovered staff cost was largely for higher-skilled setup and is expected both to decrease and to be more recovered via efficiencies and growth in the service. This effectively startup funding has been drawn largely from related mission support for developing and providing services in this area.

Results

Since the service was initiated in early 2015, the Data Core has managed a total 59 projects: 48 research projects, 7 masters projects, and 4 classrooms. Currently, the Data Core is hosting 35 active projects: 28 for research, 5 masters projects and 2 classrooms. All these projects have been associated with the Department of Healthcare Policy and Research. As of January 2018, the Data Core has been advertised as a college-wide service, and is now onboarding its first project from another department (Anesthesiology), with a second pending grant approval (Medicine). Even within the pilot phase, the HPR projects have involved numerous collaborators from different departments and even different institutions (including Rockefeller University, Columbia University, Cornell Ithaca campus, and the University of Maryland). Onboarding is now underway for new collaborations among WCM and Cornell Tech investigators.

A particularly unique success has been the hosting of the local and regional analysis components of two PCORnet-funded New York City Clinical Data Research Network (CDRN) projects. These projects involved co-ordinated secure transfer of data from external data providers, hosting of the data in both local fileshare directories and a segregated PostgreSQL database, collaboration of activities from multiple parties from external organizations, and frequent testing of procedures in order to ensure successful execution of changing requirements of the projects. Each of these projects in themselves underwent multiple sub-cycles of data import, loading, testing and analysis, allowing iterative fine-tuning of the process, in line with the general framework for confirming project success following a change in state.

The non-classroom projects operate with a mean of 3.2±2.0 users at any given time during their life cycle (Figure 3), although eight projects have had at least six users granted access throughout their life.

As shown in Figure 4, 206 unique users have been granted access to at least one project since 2015. Two classroom projects led to the rapid increases (June 2016, January 2017) and decreases (January 2017, April 2017) in user numbers visible on the graph. In this figure, individual users are counted multiple times if they have access to more than one project at a given time.

Figure 4.

Number of project-specific individuals authorized to access the Data Core over the first two years. Two classroom projects led to the rapid increases (June 2016, January 2017) and decreases (January 2017, April 2017) in user numbers visible on the graph. In this figure, individual users are counted multiple times if they have access to more than one project at a given time.

Resource usage within the Data Core is highly heterogeneous. While eight projects utilize more than 1 TB of fileshare space, the median usage is only 4.4 GB (Figure 5). Total size of the Data Core is currently 32.7 TB. Projects are co-hosted on server nodes, sharing the computational load.

Figure 5.

Current fileshare utilization for 59 projects. At project completion, fileshares and their contents are archived, unless project governance dictates destruction of the data. Thus the data shown here represent the total fileshare size managed by the Data Core, not just the total size of all active projects. Note the log scale for the y-axis. Total usage is 32.7 TB, median is 4.4 GB.

Individual projects that require increased resources will be mounted on servers with sufficient RAM and processor number to meet the project need (Figure 6). Our current server configurations allow provisioning of processors in increments of base 2, with a standard 4 GB of RAM available per processor. Thus the default configuration is 4 CPUs with 16 GB of RAM. Servers can have additional RAM provided independent of processor number. Recent addition of projects pursuing machine learning and natural language processing have created a need for servers with substantially higher resources than more traditional analyses. At this stage, it has been possible to meet these needs with standard CPU and RAM resources, without users seeking GPU functionality.

Figure 6.

Computational resources requested for all projects. Due to high overlap of projects, the points on this figure have been dispersed by up to ±0.5 CPU and ±1 GB RAM for visibility. Actual CPU numbers are multiples of 4, and actual RAM usage is typically in multiples of 16.

A total of 41 export requests have been processed in 2.5 years of operation. The mean turn-around for an export request is 3±1.3 days (2.25±0.8 business days), based on the 14 export logs from the last 12 months (for which record keeping enabled precise tracking of turnaround time).

Discussion

Through two and a half years of operation, the Data Core has provided robust, secure access to protected information for 59 projects, while proving agile enough to respond to user needs in a timely manner, and thus not placing an undue hindrance on research activities. This has been achieved at a cost deemed acceptable by the Department of Healthcare Policy and Research, and by the individual research groups beginning to engage the service of the Data Core. The framework of project life cycle management, and user-confirmation of major changes to project state has proven robust to numerous unique project configurations, such as the two CDRN projects, and to major changes in system infrastructure (such as the migration of all projects from servers hosting Windows 2008 to Windows 2012). The development of the management database and website have substantially aided the administrative management, logging and auditing of the Data Core, allowing greater time to be spent on optimizing provision of services to the users, developing new features and proactively monitoring project function.

One of the major goals of the Research Informatics program at WCM has been to increase accessibility of data for research and quality improvement (20). This involves the staging, cleaning, and transformation of data from the EHR and other sources, so that scientists can analyze and add to the data, and students can learn how data is organized and used to promote care and research. However, many of our data sets are by their nature very sensitive. Simplifying access to these data must be balanced with protecting the privacy of the people they describe. The Data Core offers this compromise by keeping the data tightly controlled in a central location but giving researchers access; two seemingly contradictory goals. This productive tension informs the approach to compliance with various forms of governance or regulation, such as HIPAA, data provider use agreements, agency or provider standards or attestations, and IRB structures. These various requirements are addressed by both structural and training/policy measures, the latter typified by institutional training on HIPAA and research integrity, individual user agreements, and extensive policies on use of IT and data (https://its.weill.cornell.edu/policies). The structural measures detailed in the Methods section can be categorized along two axes: Procedural, aiming to retain efficient records of transactions at each important control point, especially those where data enters or leaves the Core; and technical, aiming to provide data access and processing only within the Core, and only to appropriately authorized users. The Core has used all these elements to respond to and obtain data based on questionnaires from federal, state, city, and private data providers. The Core has been a component of institutional HIPAA risk assessments and will soon complete a Core-specific assessment in anticipation of additional data provider requirements.

The support for classroom activities has proven of immense value. During a recent class, the transition from lecture to laboratory was seamless using Data Core and robust WiFi. Students proceeded from learning about SQL and OMOP, to using SQL to query OMOP, aiding the reinforcement of the course objectives without the need to use a separate dedicated computer laboratory. Managing the atypically large project sizes of classrooms has required specially-adapted approaches. For example, during one class, some users could not connect to their Data Core project. Investigation by the teaching assistant led to the discovery that they were incorrectly entering password credentials by mistakenly using non-English keyboard settings in their operating system. Upon selecting English keyboard settings, students accessed the Data Core resource via two-factor authentication without issue and could subsequently complete the laboratory portion of the class. This case highlights the value of in-person troubleshooting assistance, which is now recommended for the beginning of all new classroom projects.

Figure 2.

Provisioning of user access to project data. Users on the institutional network access the Data Core through two-factor authentication. External users have an addition two-factor authentication step to gain access to the institutional network. Protected information is loaded onto the Data Core via curatorial and technical staff. Additional data and/or software from the user can also be loaded via the Data Core staff. Disclosure-proofed data are able to be delivered to the user by request to the curatorial staff, who independently verify the export is disclosure proof and complies with all project governance.