data conversion and versioning approach › sites › default › files › kc-pmx-dataret… ·...

Data Conversion and Versioning Approach Kuali Coeus Implementation at MSU

Version 20141106 11/6/2014

Revision Log Date Version Revision(s) 03 Jun 2014 20140603 Draft preparation 29 Jul 2014 20140729 Revisions based on technical feedback 28 Aug 2014 20140828 Revisions based on EIS/Data Services feedback 29 Aug 2014 20140829 Revisions based on comments from Dr. Hunt 16 Sep 2014 20140916 Response to Chandran comments 17 Sep 2014 20140917 Draft distributed to Business Units 17 Oct 2014 20141017 Feedback from ORA 22 Oct 2014 20141022 Incorporate written feedback from ORA 29 Oct 2014 20141029 Incorporate feedback from SPA 05 Nov 2014 20141105 Incorporate feedback from EIS/Data Services 06 Nov 2014 20141106 Draft for review

KC Data Conversion and Versioning Approach Version-20141105

Page 2 of 22

Table of Contents 1. Executive Summary 2. Introduction 3. Current State Systems and Data Availability 4. Current State Data Conversion 5. KC and the MSUEDW 6. Archival Storage 7. Access and Security 8. Glossary 9. Appendix A – WBS for data conversion process 10. Appendix B – RACI for data conversion process 11. Appendix C – Key element for 21 CFR 11 compliance


Page 3 of 22

1. Executive Summary Data conversion strategy in each of the functional areas Preaward Award COI IRB IACUC Legacy transactional data to be converted and pushed to KC

Active proposals within 18 months of submission date

Active awards

All entities and most recent disclosure (project and annual)

Active, expedited and full board (non-active – previous three years for records retention). Incomplete protocols started close to go-live

AUF data captured in Microsoft Word files. Can the word files be mined for IACUC data, for push to KC?

Legacy reference data to be converted and pushed to KC

Sponsors, Organizations, Address Book Contacts, Unit Administrators, Research Areas

Status of legacy data not pushed to KC

Proposal submission data since 2009 in MSUEDW. Limited proposal data between 1989 and 2009 in MSUEDW.

Award data since 2009 in MSUEDW. Limited award data between 1989 and 2009 in MSUEDW.

Push current COI database to MSUEDW?

Paper. Electronic data in FileMaker since late 1990s. Basic information, but not detailed transactional information

Paper. Duplicate electronic records stored in ORA S: drive and pushed to Angel. Propose push to archival system

Current state data dictionary freeze1

09/01/2014 09/01/2014 09/01/2014 TBD TBD

Overlap between current state application and KC after go-live

“All-Search/eTransmittal/Proposal

Record” view only for back office and end users. Maintain edit access for back office for

data correction

Transition time, keep legacy as reference. Do not duplicate

data in KC and legacy. Verification. As back office.

Stage at which data edits occur

Data cleansing to occur during extract or load process, or both. Edits to improve data quality in current state system are underway. Data Resource Administrator

to provide direction on quality/cleansing efforts by Business Unit Data edit responsibility

EIS will provide documentation templates. The Business Units, working with the KC Project Team, will create and document the conversion rules

Validation strategy EIS will use the IBM Information Analyzer to validate current state data quality. Business Unit and KC Project Team will develop Use Cases to identify and

test/validate pathological cases Any exceptions to above

Activity Log Account Explorer will be maintained

None Transition of legacy data from paper to electronic format

MSU Angel at end-of-life in April 2015

1Changes after the freeze date to be documented and reported to the KC Project Team


Page 4 of 22

Data cross links between KC modules and other external systems. Items in italics indicate links that have not yet been developed

Producer Preaward Award COI IRB IACUC MSUEDW Archive Other ERPs Consumer

Preaward None Training, Annual

disclosure

Training, Submitted protocol

Training, Submitted protocol

None

Historical Proposal

s pre-2009

Kuali Rice

Award

Proposal data to

associate with an award

Annual disclosure Approved protocol

Approved protocol None

Historical Awards

pre-2009

KFS, Kuali Rice

COI

Proposal data to

associate with

disclosed entities

Award data to associate

with disclosed entities

Protocol data to associate


Protocol data to associate


Training None Kuali Rice

IRB

Proposal data to

associate with a

protocol

Award data to associate with protocol

Annual disclosure None Training

Historical protocols

Kuali Rice

IACUC

Proposal data to

associate with a

protocol

Award data to associate with protocol

Annual disclosure None Training

Historical AUFs

Kuali Rice, , EHS, Occ

Health

MSUEDW

All data, excluding comments

and attachments


and attachments


and attachments


and attachments


and attachments

Archive Attachments Attachments Attachments Attachments Attachments

Other ERPs

Academic Profile

Project, Encompass, Activity Log

KFS, Encompass,

Clinical Trials,

Account Explorer

Purchasing None Animal Management


Page 5 of 22

KC Project Team Working Assumptions: • Current state Research Administration systems for Preaward, COI, and IRB, will

maintain back-office operation at KC go-live to verify data and provide view-only access in-process records KC will be the system of record for Awards and Subawards, however, Account Explorer will continue

• All data in KC will be pushed nightly to the MSUEDW; however, only a subset of KC data in the MSUEDW will be pushed to the MSUDIM

• No data from KC will be written to MSUDATA • File attachments and comments in KC will not be pushed to the MSUEDW;

however, metadata describing uploaded files, if available, will be pushed to the MSUEDW

• MSUEDW will be available for direct query (ODBC, SQL) based on business need

• Encryption methods applied to KC data in the MSUEDW will be tested to verify that system performance is not degraded. KFS 5.x data push to an encrypted database in the MSUEDW has not revealed any performance issues

• The need to version data in KC will not be dictated by other ERP applications • Versioned data in KC will not be consumed by other ERP applications systems;

similarly, versioned data from other ERP applications will not be consumed by KC

• All manipulations of KC data elements during conversion will be documented to ensure accountability, auditability, and reasonability

• Data retention requirements will be defined and enforced at go-live • Data archival storage (outside of MSUEDW) of scanned paper documents will

not carry an association to electronic data records; however, metadata and/or file location information will be maintained in KC

• A core set of reports for research administration will be optimized by go-live. On demand reporting via MSUEDW will be possible based on business unit need


Page 6 of 22

2. Introduction The Kuali Coeus (KC) Research Administration Implementation Project will provide the MSU community with an Enterprise Resource Planning (ERP) application for the administration of research proposals starting with development, through submission, negotiation activities (both pre- and post-submission), award, and finishing at close-out. In addition to Preaward and Award functionality, KC include modules covering the compliance areas of Conflict of Interest (COI), Institutional Review Board (IRB) for research involving Human Subjects, and Institutional Animal Care and Use Committee (IACUC) for research involving Animals. KC will replace current state systems at MSU for proposal routing, IRB protocol submission and review, and COI reporting. KC will also be the system of record for award and subaward transactions. This document outlines, at a high level, the approach to be taken by the KC Project Team regarding the retention and treatment of historical data. One area of focus is the need for current state data within KC. Some data elements within the current state systems will need to be converted and transferred into KC, while other data elements may need to reside in the MSU Enterprise Data Warehouse (MSUEDW) and remain accessible for generating reports. Attention is also paid to the availability of historical data values within the KC application, and the eventual use of those historical values in report generation. While the nightly data push from KC to the MSUEDW only saves current data element values, options for versioning within the MSUEDW and the MSU Dimensional Model (MSUDIM) are presented. 3. Current State Systems and Data Availability The availability and quality of data dictionaries, which contain the descriptive data on data elements, related to current state research administration activities across campus vary widely. The IT Services EIS team provides metrics for completeness of the dictionaries and subjectively analyzes the quality of the content of the dictionaries. Most of the data dictionaries were documented on implementation, but updates/changes to the dictionaries have rarely been recorded. The goal is to make available the data dictionary documentation on line for the current business systems, and to use the current state data dictionaries to inform the data conversion process. The KC Project Team will propose freeze dates for current state data dictionaries, after which the Business Units will complete a Change Notification Form to inform the project of changes in data structure(s).

3.1. OSP/CGA Prior to 1989, all data elements in the Office of Sponsored Programs (OSP) and Contract and Grant Administration (CGA) were maintained on paper. Between 1989 and 2007, some data elements started to be recorded electronically. A flat table structure was used, composed of approximately 400 data columns per entry. Post 2009, all


Page 7 of 22

electronic data elements maintained in complex table database that includes some 41 total tables and 1,243 data fields. All active award have accounts established in the MSU instance of the Kuali Financial System (KFS). The current treatment of proposals is that all changes are recorded in the OSP/CGA database. The OSP/CGA database is pushed nightly to both MSUEDW and a second data repository for reporting commonly known as MSUDATA. MSUDATA is a legacy data repository at MSU used for sharing of data between systems, reporting, and analysis. No data from KC will be written to MSUDATA. OSP/CGA is continuing to create an electronic archive of paper records. About 80% of the paper record storage had been scanned as of November 2014, and the scanned documents are currently maintained on the SPA shared public drive. SPA is considering coping these records to the planned research administration data archival storage system.

3.2. COI The current state COI database includes 21 total tables and more than 200 data fields. All data fields have technical metadata from the source system. An Entity Relationship Diagram is available for the web-based COI application. The COI data dictionary has been assembled, based on a database download from late 2013. The data fields are not being pushed to the MSUEDW. Active and inactive financial entities and event-based and annual disclosures for calendar year (CY) 2012 and 2013 are available in .html format. The Faculty Conflict of Interest Office would like to push these electronic records to the MSUEDW.

3.3. IRB The current state IRB system is an application written in FileMaker Pro. The database for the current state includes 11 tables and nearly 2,200 data fields. The Business Unit is working with IT Services Enterprise Information Stewardship to update the current state data dictionary and analyze the quality of existing data. No data are pushed from the FileMaker Pro application to the MSUEDW. Exempt protocols, 118 Designations, and Non-Human Subject Determinations are all in electronic format, within FileMaker Pro. All other records for IRB are in paper form. The MSU Human Research Protection Program (HRPP) office would like to transition to electronic record keeping for all protocols, provided the provisions of 21 CFD Part 11 are met.

3.4. IACUC


Page 8 of 22

The IACUC administrative staff use a DOS-based program and an MS Windows application called the Campus Animal Resources Laboratory Ordering System (CARLOS) for capturing animal use data for reporting and procurement. Animal User Forms (AUFs) are completed in Microsoft Word and collected as electronic copies, and relevant data elements are logged in CARLOS, the DOS-based system, and Microsoft Applications (Word, Excel) by the IACUC staff. Paper copies of the approved AUFs, along with other pertinent documentation, are also maintained by the IACUC office. The data elements from the AUFs captured in the DOS-based system are used to generate approval letters that are distributed to the Protocol Submitter, the Submitter’s Unit Administrator, and CGA. CARLOS is used by University Laboratory Animal Resources (ULAR) for laboratory animal procurement. Data elements from approved AUFs are entered into CARLOS by IACUC staff. Principal Investigators use CARLOS to order animals, view orders, view bills, and designate who can order animals for an approved AUF. Fiscal Officers enter account update information into CARLOS, and can also view and print billing information. An animal management system will be needed to supplement the functionality of the IACUC module post KC go-live. 4. Current State Data Conversion

4.1. Work Breakdown Structure

A work breakdown structure (WBS) is provided in the Appendix A for conversion of Preaward and Award data elements. The structure is similar for conversion of Compliance (COI, IRB, IACUC) data elements. A Responsible, Assists, Consults, and Informs (RACI) chart that parallels the WBS is provided in Appendix B.

4.2. Description of Preparatory Work The current state data dictionaries for Preaward/Award, COI, IRB, and IACUC will be reviewed for both completeness and quality. The Enterprise Information Stewardship (EIS) group from Information Technology (IT) Services will construct a common format for the data dictionaries, and the Business Units will provide identifying information (database names, table, and column names, and the associated data types) and characterize the security level (public or sensitive) for each data element. The Business Units will also confirm data type and whether a given element must contain data. EIS is also using IBM Information Analyzer to find data quality issues such as data formatting inconsistencies, missing data, incorrect data types, etc. The KC data dictionary for each module will be prepared by the relevant KC Functional Workgroup, using a common format developed by EIS. The Business Units will review the data elements, with particular attention to data element sensitivity, data quality, and definition. Data quality issues may be addressed by the Business Units in advance of data disposition actions for KC. The KC Technical Workgroup will provide the KC


Page 9 of 22

source information for the database, owner, table name, column name, and data type. Lastly, the KC Functional Workgroup will provide descriptions for each KC data table.

4.3. Disposition of Current State Data Elements Current state data elements will be dispositioned in one of four ways:

• needed in KC, whereby the data element will be passed to KC; • not needed in KC, but necessary for reporting, whereby the data element will be

copied to the MSUEDW; • not needed in KC or for reporting, but must be retained, whereby the data

element will be archived; • not needed; whereby the data will be left behind.

All transactional data in KC, expect for attachments and selected comments, will be pushed in the MSUEDW. A mapping of the current state and KC data dictionaries will inform the data conversion process. The mapping is necessary to decide if any manipulation is needed to transfer necessary data elements into the transactional system, to expose that current state data elements that do not have a corresponding element in the KC application, and to ensure that the tracking of historical data across the current state to KC transition is making use of comparable data elements. In cases where a KC field is identified that does not have a corresponding input from the current state system, the field will not auto-populate in KC. If the field is mandatory in KC, the KC Project Team and EIS will discuss the action to be taken with the relevant Business Unit.

4.3.1. Preaward

There are roughly 4000 active proposals in the current system. As noted above, proposal data from OSP are pushed to both the MSUEDW and MSUDATA. All active proposal will be pushed to KC at go-live. In process proposals will be entered into Institutional Proposal, where there will be a need to reference the App Notes from the current state system. OSP also currently uses Activity Log for a tracking and metric system as well as maintaining transparency with campus. At KC go-live, all open activities in the Activity Log will remain in the current system and will be processed there. All new activities will be logged in the Negotiation module. After all open activities are closed out, Activity Log will no longer be used but all activities will remain in a view only format.

4.3.2. Award

There are roughly 2000 active awards in the current system. As noted above, award data from CGA are pushed to both the MSUEDW and MSUDATA. Active awards and their corresponding Institutional Proposal will be pushed to KC at go-live. There would not be a need to regenerate active award accounts, since the award accounts will already exist in KFS. Attachments from the current-state eTransmittal will not be transferred to the Institutional Proposal, however, the eTransmittal and associated attachments will remain viewable to both the Business Office and end users after KC


Page 10 of 22

go-live.

4.3.3. COI

The current state COI web-based application maintains entities and disclosures in electronic format. However, these data elements are not being pushed to the MSUEDW. It is desired to have all existing COI entity and the most recent annual and project disclosure data imported into KC. However, it is noted that the KC COI module relies on proposal, protocol, and award information for completing disclosures. Disclosures of significant financial interest in an entity may or may not require association with a current proposal, protocol, and/or award. As of January 1, 2015, all individuals at MSU appointed through the academic personnel system or have independent responsibility for proposing, conducting, or reporting results of research must annually disclose all significant financial interests in entities associated with their institutional responsibilities. It has been suggested that standard data values for the entity descriptions be adopted for KC, possibly using the KC Organization Table. There are approximately 4,700 faculty and academic staff appointed at MSU, however, only a small percentage have a significant financial interest to disclose.

4.3.4. IRB Protocol applications for initial review, renewal, or revision are submitted electronically via the FileMaker Pro current-state system. Protocol reviews are also carried out on-line, with reviewer comments and investigator responses captured in FileMaker Pro. There are approximately 2,200 active IRB protocols, some having been renewed for decades. Exempt protocols, 118 Designations, and Non-Human Subject Determinations are all in electronic format, within FileMaker Pro. HRPP maintains paper copies of other protocols types. Current state data from FileMaker Pro are not being pushed to the MSUEDW. The working assumption of the project team and business office is that the current state system will transition to a back-office system on KC go live. FileMaker Pro will remain accessible to Business Unit staff for validation purposes. Active protocol data elements will be pushed to KC, with tracking of the prior electronic or paper documentation in the transactional system by manual entry into a designated KC data field. In-process protocols, e.g., those started in FileMaker Pro prior to KC go-live, will be pushed to KC as well. As noted earlier, it is desired to transition to all electronic records. Such a transition requires KC to be capable of complying with 21 CFR Part 11 (see Appendix C). The Foundation KC Project Board is developing a best-practices document for the KC application to guide institutions on meeting 21 CFR Part 11 requirements. Note that the current state system, FileMaker Pro, is not 21 CFR Part 11 capable.

4.3.5. IACUC Only a limited number of IACUC data elements are maintained electronically in the DOS- and web-based applications, which are copied from the AUF applications and


Page 11 of 22

entered manually into the databases. AUFs are submitted as electronic files in Microsoft Word format and stored on the ORA “S” drive. Active AUFs could be uploaded as attachments into KC, but most of the protocol details would need to be entered manually. The possibility of extracting data directly from the Microsoft Word files will be reviewed. There are approximately 600 active AUFs.

5. KC and the MSUEDW MSUEDW can serve a hub-spoke architecture, whereby data from separate source systems are pushed to the MSUEDW and then accessed by other systems. Such architecture is appropriate for data transfers that do not need to be executed in real time, and eliminates the need to develop point-to-point system integrations, which may involve numerous maintenance considerations. The working assumption is that KC will consume data from the MSUEDW that is sourced from KFS (e.g., object codes), OOI (e.g., organizational hierarchy, with the working assumption being the KFS OOI), HR/SAP (e.g., personnel data), and Saba (e.g., compliance training records). Compliance data from Environmental, Health and Safety and Occupational Health are needed, however, the availability of these data in the MSUEDW before KC go-live needs to be resolved. KC data residing in the MSUEDW will be consumed by other applications, including Account Explorer (CGA), Encompass (Advancement), and the Academic Profile Project (VPRGS). The working assumption for the KC Project Team is that the data push from KC to the MSUEDW will occur nightly. Only immediate last values in KC will be pushed, however, if there is versioning in the application, that versioning will be carried over to the EDW. The MSUEDW retains no historical records; that is, all values in the MSUEDW schema, which is the organization of data that serves as a blueprint for the database construction, are current as of the last data push from the source system. However, if the source system has date-delimited data, the same data-delimited data can be carried in the MSUEDW.

5.1. Versioning in KC

5.1.1. Preaward Historical proposal information is maintained in KC, however, this proposal information is not readily accessible outside the transactional system. A proposal being developed generates an Institutional Proposal once it is completed and submitted to the sponsor. Any subsequent revisions to a submitted proposal will generate changes to the Institutional Proposal and KC maintains historical record of those changes. The original proposal, the last revision of the day, and the corresponding Institutional Proposal along with its versions will be pushed to the MSUEDW. The transactional system (KC) will need to be accessed to see intermediate proposal activity within a given day.

5.1.2. Award


Page 12 of 22

The Award module includes a data table that maintains a historical record of award data element changes in KC. This data table will be pushed to the MSUEDW.

5.1.3. COI Descriptive details of financial entities and travel disclosures cannot be edited, and these records remain “static” in KC. Any updates to financial entities or travel disclosures will result in a new record in KC, and no subsequent overwrite of the previous data value captured in the MSUEDW. Changes to the annual disclosure, e.g., newly disclosed entities and/or deactivation of existing entities result in the generation of a new document version in KC, and version retention when pushed to the MSUEDW.

5.1.4. IRB The individual components of IRB protocols in KC are versioned in the application, and the versions will be retained when KC data are pushed to the MSUEDW. Renewals and revisions in progress are treated as separate documents in KC, therefore, these versions will be retained during the data push to the MSUEDW as well. Some data elements planned in code customization may change on a time scale more frequent than the one-a-day data push from KC to the MSUEDW. For example, MSU-specified requirements for the KC implementation include the tracking of both the IRB case manager and case file location. It will be necessary to maintain the change history of these new data elements in the KC application and following the push to MSUEDW so the Business Unit can generate their performance reports for their case managers.

5.1.5. IACUC In KC, IACUC protocols are treated in a similar way to IRB protocols. Historical information will therefore be retained for IACUC initial applications, renewals, and revisions upon the data push to the MSUEDW

5.2. Versioning in the MSUEDW and MSUDIM A full snapshot of the MSUEDW can be generated at given points in time; these data snapshots are stored in a separate schema and designated by schema name, date, and qualifier. The source system owner determines the retention of this historical schema in the MSUEDW. The KC Technical Team is considering the implementation of MSUEDW snapshots on initial go-live to allow for more rapid data recovery during application stabilization. It is also possible to capture certain table data at given points in time within the same schema, and generate an aggregated view. This option provides access to the historical data without having to inspect multiple schemas.


Page 13 of 22

A similar approach to data element versioning can be applied in the MSUDIM, whereby changes in a data element are tracked on a day-to-day basis (essentially an end-of-day snapshot). A data comparison check can be executed to identify changes in data values, with the changes labeled by an effective date. “Current” values can also be captured as needed. Short of the full snapshot, it is necessary to identify in advance the data elements to be versioned in the MSUEDW or MSUDIM, so that the expanded tables can be set up properly.

5.3. Attachments and Comments The treatment of attached documents during the data push from KC to the MSUEDW was discussed during the Preaward and Award Management Review. KFS currently does not bring attachments into the MSUEDW. If attachments are made available in the MSUEDW, then it is also necessary to make the attachments accessible, regardless of file type. The viewing of attachments, which could include any number of different file types, has not yet been developed within the MSUEDW. Also, a method to track versions of attachments in the MSUEDW would be needed. The content of attachments may contain sensitive information, carrying a need to restrict access to such documents. Finally, attachments would not be “searchable” in the MSUEDW. The working assumption of the KC Project Team is that attachments and selected comments from KC will not be pushed to the MSUEDW. Copies of attachments will be maintained in Archival Storage (see Sec. 6). The intent is to copy any metadata and reference information existing in KC for attachments into the MSUEDW to maintain the “full” integrity of the transactional data. The file upload process, when executed within the KC application, includes prompts requesting details on the file contents that are then stored with the file as metadata. File attachments made in KC via the Notes & Attachments tab do not include such prompts, and the metadata information is minimal (filename, author, creation/modify date, etc.). Technical content of the proposal (e.g. Current and Pending Support Forms), typically included in the proposal as an attachment, could be retrieved either from the transactional system or from the archival storage area (see Sec. 6). Comment fields in KC will not typically be pushed to the MSUEDW. The EIS Data Services team has been working with KC Project Work Group Leads to identify instances where comment fields are needed for reporting, and therefore would be copied to the MSUEDW.

5.4. Reporting Flat reports based on KC transactional data will be generated in the MSUEDW or MSUDIM. The working assumption of the KC Project Team is that a core set of (10-20) reports for research administration will be optimized by go-live. These reports, if classified as appropriate for public viewing, will be made available to the campus


Page 14 of 22

community. Identifying the core report set will require input from all levels of university administration. Other reports can be generated from the MSUDIM by the self-service functionality of Query Studio. CGA is already actively using Query Studio to generate reports from KFS data that is pushed to the MSUDIM. The KC Project Team expects that the campus experience with Query Studio will grow during the KC implementation, so that by KC go-live the self-service approach will be tenable. Limited access will be provided to the MSUEDW. Access to the MSUDIM will be controlled through the Cognos application, where most reporting will be self-service via the Query Studio application. 6. Archival Storage The MSUEDW and MSUDIM are intended to serve the reporting needs of the institution, and are not intended for data archiving. Data (including attachments) for record-keeping purposes will be archived in a separate system, which is defined in the Statement of Work agreement between the KC Project and IT Services. Archival storage of electronic data files will be driven in part by federal, state, and local (including university) requirements for each of the functional areas of the KC application and will be defined prior to go-live. It is assumed that record retention requirements shall be defined and enforced at go-live.

6.1. OSP/CGA Record retention for federal grants is governed by the Office of Management and Budget (OMB) Circular A-110, while record retention for federal contracts is governed by the Federal Acquisition Regulation (FAR) 52.215-2. Records are to be retained for 3 years after submission of the fiscal status report or after final payment under a Federal contract. If any litigation, claim, or audit is started before the expiration of the 3-year period, the records must be retained until all litigation, claims or audit findings involving the records have been resolved and final action taken. Record retention for state or other awards depends on the terms and conditions for the specific contract/award. When unspecified, usually the federal retention requirement is followed. Presently, proposals that do not result in an award within 18 months of submission are marked unfunded/expired. OSP/CGA has created an electronic archive of paper records, and the scanned documents may be placed in the to-be established research administration data archival system. The working assumption is that only the scanned paper documents will be stored, with association to the KC transactional system only in the instance of an active award.


Page 15 of 22

6.2. COI

The Public Health Service (PHS) requires that investigators and subcontractors maintain records relating to all Investigator disclosures of financial interests and the Institution's review of, and response to, such disclosures (whether or not a disclosure resulted in the Institution's determination of a financial conflict of interest) and all actions under the Institution's policy or retrospective review, if applicable. These records must remain available for at least three years from the date the final expenditures report is submitted to the PHS. The National Science Foundation (NSF) requires institutions to maintain records of all financial disclosures and all actions taken to resolve COI for at least three years beyond the termination or completion of the grant to which they relate, or until the resolution of any NSF action involving those records, whichever is longer.

6.3. IRB IRB documentation must be retained for a minimum of three years after completion of the research. Most IRB approvals expire one year from the date of approval. Investigators wishing to continue research activities, including data collection and analysis, beyond the expiration of IRB approval must submit and receive approval for updated renewal prior to the expiration. Renewed approval is for a maximum of one year. There is no inherent limitation on the number of IRB renewals, as such, a single project may accumulate a multi-year historical record of protocol documentation. Research studies considered to be exempt from federal regulations do not require continuing IRB review and thus, do not require a renewal application on an annual basis. However, records relating to the research must be retained for at least three years after completion of the research.

6.4. IACUC

The US Department of Agriculture requires all records and reports shall be maintained for at least 3 years. Records that relate directly to proposed activities and proposed significant changes in ongoing activities reviewed and approved by the IACUC shall be maintained for the duration of the activity and for an additional three years after the completion of the research. The PHS recordkeeping policy states that all records shall be maintained for at least three years; records that relate directly to applications, proposals, and proposed significant changes in ongoing activities reviewed and approved by the IACUC shall be maintained for the duration of the activity and for an additional three years after the completion of the research.


Page 16 of 22

IACUC conducts an annual review of all studies involving animals used in research, testing or instruction. All AUFs expire on the anniversary date of the original approval, and must be renewed prior to that date. AUF can only be renewed for up to three years, after which, a new AUF needs to be submitted for review and approval by IACUC. MSU requires that once an AUF goes inactive, it will be retained for an additional 3 years. 7. Access and Security The KC application security approach was initially presented for review in August 2013 (kc.vprgs.msu.edu/application-security-review-presentation). Direct access to MSUEDW access will be limited, based on business need, as articulated in an Access Request Memorandum (ARM). The ARM shall be approved by line management and system owners for to access to be granted. Access to the MSUDIM will be through the Cognos Business Intelligence suite, with authentication through MSU NetID login. Access to the Cognos application is role based. Roles in Cognos will be mapped to corresponding roles in KC. Generally speaking, if a person has access to see a specific kind of data in KC, then that person will also be able to see corresponding reports in the Business Intelligence system. Business Intelligence tools such as Query Studio or Analysis Studio require a separate role-granting access to specific tool via an Access Request Memorandum (ARM), with data access mirroring access to the source system. Business Units shall be responsible for defining the security and data classifications in the MSU EDW. Enterprise Information Stewardship and Data Services will facilitate the discussions, as part of the data mapping exercise between current state and KC. Data Services shall execute the security implementation, based on the Business Unit definitions. The Enterprise Security team within IT Services will recommend best practices and a path forward based on project requirements. Engagement with MSU General Counsel is encouraged if questions arise concerning possible open records requests. The KC Project Team will provide the explicit business and security rules for those data elements that will have restricted access. The ARM form shall be approved by line management and system owners prior to access being granted. MSUEDW contains both non-sensitive and sensitive views. The non-sensitive views do not contain any confidential data while the sensitive views contain both public and confidential data. The data elements from KC will be pushed into an encrypted database within the MSUEDW. Recent tests on data element pushed from KFS 5.0 into an encrypted database in the MSUEDW revealed no impact on system performance. The working assumption of the KC Project Team is that additional testing will be completed to


Page 17 of 22

demonstrate that similar pushes of KC data into an encrypted database in the MSUEDW can be performed without compromising system performance.


Page 18 of 22

Glossary Acronym Definition ARM Access Request Memorandum AUF Animal Use Form BU Business Unit CARLOS Campus Animal Resources Laboratory Ordering System CFR Code of Federal Regulations CGA Contract and Grant Administration CLIFMS MSU Course Load Instruction Funding and Modeling System Cognos MSU Business Intelligence software application COI Conflict of Interest CTMS Clinical Trials Management System CY Calendar Year DOS Disk Operating System DS Data Services EIS Enterprise Information Stewardship ERP Enterprise Resource Planning FDA Food and Drug Administration HR Human Resources HRPP Human Research Protection Program IACUC Institutional Animal Care and Use Committee IdM Identity Management IRB Institutional Review Board IT Services Information Technology Services KC Kuali Coeus Research Administration software application KCDev KC Development Team KCFunc KC Functional Team KCPMO KC Project Management KCSteer KC Steering Committee KFS Kuali Financial System software application MS Microsoft MSU Michigan State University MSUDATA MSU Data Warehouse for SIS, CLIFMS, and “older” MSU applications MSUDIM MSU Dimensional Model MSUEDW MSU Enterprise Data Warehouse NetID MSU Network Identification NSF National Science Foundation ORACLE MSU Database application OSP Office of Sponsored Programs PHS Public Health Service RACI Responsible, Assists, Consults, Informs QA Quality Assurance Saba Learning Management System for Compliance Training SAP MSU Human Resources software application SIS MSU Student Information System SPA Sponsored Programs Administration WBS Work Breakdown Structure


Page 19 of 22

8. Appendix A – Initial Work Breakdown Structure (WBS) for data conversion process, as of Summer 2014. The conversion planning will continue to be elaborated as additional details become available.


Page 20 of 22

9. Appendix B – Responsible, Assist, Consulted, Informed (RACI) Chart for data conversion process as of Summer 2014. RACI chart will continue to be elaborated as additional details become available.

Deliverable Responsible Assists Consulted Informed Research Administration Current State Data Dictionaries

KCSteer

Current State data dictionary BU EIS, KCPMO

KCPMO

Transaction and Warehouse system/data security documentation assembly

BU EIS KCPMO

Current State data model BU EIS KCPMO Data dictionary / model analysis and evaluation

EIS KCPMO

Data dictionary / model evaluation report EIS KCPMO Data dictionary business owner remediation

BU EIS KCPMO

Research Administration Current State Data Quality

KCPMO KCSteer

Valid data, formats, nullability, keys, etc analysis

EIS BU KCPMO

Business rule enforcement analysis EIS BU KCPMO Data quality issues report generation EIS BU KCPMO Data quality issues remediation BU EIS KCPMO Data Conversion Process Conv/Retroconv white paper analysis KCPMO EIS, BU,

DS KCSteer

White paper analysis actions KCPMO EIS, DS, KCDev

KCSteer

Data conversion documentation from previous systems (EBS Finance and HR)

EIS BU KCPMO KCFunc, KCDev

Data conversion lessons learned documentation

EIS KCPMO KCFunc, KCDev, BU

Current State and future-state data documentation collected and assembled

EIS KCFunc, KCDev

KCPMO BU

Data security during the conversion process

BU, KCDev EIS KCPMO, KCFunc

KCSteer

Planning Detailed Requirements Documentation BU, KCFunc EIS,

KCPMO KCDev, KCFunc, BU


Page 21 of 22

Deliverable Responsible Assists Consulted Informed Business Rules Defined BU, KCFunc EIS,

KCFunc KCPMO KCDev

Data Mapping structure and analysis KCFunc EIS, KCFunc

KCPMO, KCDev

Gaps between current reporting & KC analysis

BU EIS, KCFunc

KCPMO, KCDev

KCSteer

Gaps documentation & action plan BU EIS, KCFunc

KCPMO, KCDev

KCSteer

Disposition of data elements BU EIS, KCFunc

KCPMO, KCDev

Data cleansing and preparation Quality Assurance (QA) Current State Exports KCSteer Trial Data Exports BU EIS KCPMO,

KCDev

Quality Assurance (QA) PROD Data Export BU EIS KCPMO Validation EIS BU KCPMO KC Imports KCSteer Import Jobs Development KCDev EIS KCPMO Import Jobs Testing KCDev EIS KCPMO Quality Assurance Test Schedule KCDev EIS KCPMO Test Documentation KCDev EIS KCPMO Test Results Review Trial Import Iterations KCDev EIS KCPMO PROD Import KCDev EIS KCPMO Quality Assurance KCPMO

BU = Business Unit; DS = Data Services; EIS = Enterprise Information Stewardship; KCDev = KC Development Team; KCFunc = KC Functional Team; KCPMO = KC Project Management; KCSteer = KC Steering Committee


Page 22 of 22

10. Appendix C – Key elements for system compliance with 21 CFR Part 11 requirements (taken from “21 CFR Part 11 and the Role of Technology”, Webinar ID: 928-026-145, QPharma/Forte Research Systems, February 26, 2014) • Limits system access to authorized individuals • Use of operational system checks • Use of authority checks • Use of device and workflow checks • Controls for Open and Closed systems • Appropriate controls over systems documentation • Training • Electronic Signature Accountability • Requirements related to electronic records, electronic signatures and audit trails

data conversion and versioning approach › sites › default › files › kc-pmx-dataret… ·...

Documents