Project Management Office

Project Name

Data Management Plan

Data Management Plan Template Instructions (Please remove this section before completion of template)

The Data Management Plan document should identify the type of data that will be used and/or stored within the system and determine how the data will be created, maintained, accessed, secured and archived. This is used to assist with the initial development, maintenance, corrective action and enhancement of the system.

Be sure to maintain version control as the analysis is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant. See below for requirements for a project and deliverable approvals.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Project Deliverable	Requirements by Project Size
Planning/Development Phase	Large	Medium	Small	Requirements	Approvals
Data Management Plan (SDLC)	O	O	O	This deliverable is optional for all project sizes, unless requested by the Sponsor, Steering Committee or IT management.	The Data Management Plan should be approved by the Implementation Team and, if applicable, the Sponsor and the Steering Committee.

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	3

3.	Data Classification	4

3.1.	Description of Data	4

3.2.	Dependencies and Key Linkages	4

3.3.	Management Process	4

3.4.	Data Preservation	4

3.5.	Maintenance	4

3.6.	Storage	5

4.	Governance	6

4.1.	Data Custodian	6

4.2.	Standards	6

4.3.	Quality Assurance	6

4.4.	Change Control	6

5.	Security	7

6.	Approval	8

Introduction

Purpose

Determine the type of data that will be used and/or stored within the system and determine how the data will be created, maintained, accessed, secured and archived. This is used to assist with the initial development, maintenance, corrective action and enhancement of the system.

Assumptions

This document assumes.....

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

Data Classification

Description of Data

Provide a concise, clear description of the business data being managed, including the business objectives, classification of data (legal, patient, etc.) and components.

Dependencies and Key Linkages

Identify any business processes/applications that routinely use any of the data which is being managed within this plan.

Management Process

Describe how the data will be managed, i.e. migration, conversion, what needs to be included in any extraction process, how the extraction will happen, i.e. FTP, interface, etc., and who is responsible for the integrity of the data. When will this process be done within the project?

Data Preservation

Describe the preservation process for the data on the system and/or application being installed. Include:

Make sure to identify if the project is a new implementation, modification to an existing system, or a combination.

Backup and restore of data procedures

Method

Media to be used

Frequency

Retention Periods

Storage of the backups (location)

Request for restoration of the data procedure

Time constraints on restorations

Maintenance

Describe the maintenance process for the data or how the data will be maintained.

Storage

Describe the medium and location of storage.

Governance

Data Custodian

Identify the responsible party for data after project has been completed.

Standards

List relevant internal/external standards and policies that will apply to data being managed in this project.

Quality Assurance

Identify presence or absence of the data and what percentage meets defined data standards. Also, identify plans for data quality analysis and reporting.

Change Control

Develop a process for change control to the data being managed.

Security

Describe general information about access to the data such as availability on the web.

Security of the data system that is used to centralize public documents may have minimal security requirements, whereas a system that stores patient data would require a much higher level a security.

Approval

The individuals below agree that they have reviewed and approved the plan outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Project Management Office

EXAMPLE

NJDS Axium Project

Data Conversion Plan

Rolodex and Chart Tracker

Table of Contents

1.	Version Control	1

2.	Introduction	1

2.1.	Scope and Objective	1

2.2.	Assumptions	1

2.3.	Constraints	1

2.4.	Risks and Contingencies	1

3.	Data Conversion	1

3.1.	Conversion Flow Diagrams	1

3.2.	Conversion Overview	1

3.3.	Data Conversion	1

3.3.1.	Data Conversion Rules and Processes	1

3.3.1.1.	Selection Criteria	1

4.	Governance	1

4.1.	Data Custodian	1

4.2.	Quality Assurance	1

5.	APPENDIX	1

5.1.	ACE to Axium Conversion SQL Script	1

6.	Approval	1

Version Control

Version	Date	Person	Change
1.0	July 15, 2010	Dennis Wykoff	Initial Draft
2.0	July 27, 2010	Dennis Wykoff	Deliverable Review Revisions
2.1	July 29, 2010	Dennis Wykoff	Additional Deliverable Review Revisions
2.2	July 30, 2010	Dennis Wykoff	Additional Deliverable Review Revisions
2.3	August 4, 2010	Dennis Wykoff	SQL Script Revisions
2.4	August 5, 2010	Frances Haies	Removal of the SQL Scripts
3.0	August 13, 2010	Dennis Wykoff	Remove Scheduler from Plan

Introduction

Scope and Objective

The scope of this conversion is to convert data from the ACE software application for use in a new software application. This conversion’s objective is to migrate data into Axium to enable processing for the departments currently not using this software. Three New Jersey Dental School departments: Oral Medicine; Orthodontics; and Special Care Treatment Center were previously converted from their legacy applications to Axium. This conversion effort is to convert Endodontic, Oral Surgery, Paediatric Dentistry, Periodontal, and Restorative departments from ACE to Axium. The conversion requirement is to programmatically migrate Patient data and append it to appropriate tables in Axium. This data migration will be adding the above departments’ data to Production tables already in use for the previously mentioned departments.

Data will be programmatically extracted from ACE and translated into the required data elements in Axium. The extraction process will include data selection, mapping, generating and deriving new Axium data elements from ACE data, and conversion record control counts, Extracted data will be imported into Axium for table updating and conversion reporting.

A conversion validation process will include loading ACE Patient data and converted Axium Rolodex data into Oracle database tables for conversion comparison reporting. Data failing a comparison test will be reported and corrected in the appropriate system.

The ACE system will continue to function and generate financial transactions. To eliminate entering Patient data in both Axium and then again in ACE, Patient data added in Axium after the conversion will be programmatically interfaced back and synced in ACE.

Assumptions

ACE Transaction data will not be migrated in this conversion. Transaction data migration will be a follow on phase to this conversion.

Active and inactive Patient data will be migrated from ACE to Axium.

ACE data will be migrated to Axium as is for test and Production conversions.

ACE will continue to be used for transaction processing and be programmatically synced by Patient data from Axium.

The extracted ACE data file, ACE data loading to the Exan FTP server and backup of the ACE Production data base will serve as a source of conversion data.

The Train and Production data bases will contain required Provider data needed during the conversion.

Axium Support will partner with New Jersey Dental School personnel in processing the Patient data conversion. Multiple Axium Support resources will be available to process the testing and production conversions.

Axium Support will provide NJDS with information used for loading Patient data to Axium. Information will cover patient data errors or rejected. It’s assumed NJDS will understand data transformation steps to be applied by Exan prior to testing commencing and conversion information throughout testing and in the Production conversions.

The Train data base will be used for conversion testing. Axium Support has the required and approved access to this and the Production data bases. The same steps performed in testing will be executed for the Production conversion with the only difference being the Production database will receive the converted data.

Patient data for Endodontic, Oral Surgery, Paediatric Dentistry, Periodontal, and Restorative will be the only data converted. Patient data for the Faculty Practice will not be part of this conversion.

Extraction of this data from ACE will be scripted by NJDS personnel. This data will be made available to Axium Support for conversion testing and Production loading. Approximately 150,000 Patient demographic data records will be extracted for migration to Axium.

Transaction testing following the Patient data conversion is not necessary because the three departments originally converted to Axium can successfully transact. They used to same conversion mapping proposed for this data conversion.

Constraints

The conversion must be completed in Production by September 1, 2010.

ACE Patient data extract output must go to a CSV file due to the approximately 150,000 records extracted for this conversion.

A sample data conversion will be conducted on a Patient data population of 1000 records. A comparison of ACE Patient to Axium Rolodex conversion data will be performed. A 100% equal data comparison and reconciliation between ACE and Axium is the target %.

Conversion testing is restricted to the Train data base. There are no issues with Axium Support accessing this instance. A support contract agreement is in effect to allow Axium Support to access and update the Production data base with conversion data.

Risks and Contingencies

A focused sample Patient data conversion validation effort has been made and scripts are ready and will be further refined in conversion testing.

Availability of internal and external resources is required. NJDS resources have been assigned to the conversion effort. Axium Support primary and back up personnel has been assigned to conversion testing and Production conversion as well.

Data will be converted as is unless otherwise specified. An example being, if a zip code is formatted incorrectly in ACE, it will be carried forward into Axium incorrectly. Backups of the database at all points during the testing will be maintained in the event that it needs to be restored for retesting. NJDS personnel will keep the backups and perform restores, if necessary.

Data Conversion

Conversion Flow Diagrams

Sampling A sample ACE data extract and Axium upload for 1000 patients will be performed. Patient data will be uploaded to the Train database. A 100% validation of the data elements transferred between ACE and Axium is the target result before conversion testing begins. NJDS or Exan will refine conversion scripts to achieve desired results based on sample review.

Test and Production Data Conversion

Conversion Overview

ACE’s Patient data will be extracted from its Production environment into a CSV file. The initial processing will extract all Patient data for the subject departments. Any subsequent Patient data extracts from ACE will re-extract all Patient data. Extract scripts will include record counts used for reconciliation with Axium uploads.

Extracted data will be uploaded to the Exan server used for current file transfers between NJDS and Exan. This is a secured server accessible to contracted parties only. Multiple file uploads will be allowed with naming standards used to separate files.

Axium Support will extract conversion data from the Exan server and use as its source for uploading Rolodex data in Axium.

Axium Support will import extracted data, add Patient data to Rolodex tables already in use and generate information needed to validate the conversion. Rejected Patient data and error information will be produced. Materials will be communicated to NJDS or stored on the Exan server for access and downloading by NJDS.

NJDS will use Patient upload information and reconcile with ACE Patient record counts from ACE extract. Error and reject information will be used as a source for revising data conversion scripts. Any scripting errors by NJDS or Exan will be corrected. A rerun of a conversion cycle will require a restore of the Train data base. A data base restore request will be made of Axium Support and the conversion cycle will be repeated.

When all ACE data has successfully passed through the conversion cycle, an ACE Patient data to Rolodex Patient data validation cycle will be performed.

NJDS will load extracted ACE Patient data to Oracle tables as a source to for ACE to Axium comparison reporting.

NJDS will extract and load Patient Rolodex data from Axium to load to Oracle tables as an additional source to for ACE to Axium comparison reporting.

NJDS will generate an ACE to Axium Patient data comparison report. Report will print only differences in converted data between ACE and Axium.

Any reported differences in the conversion cycle will be resolved by correcting data conversion scripts and restoring the required data base and then performing another conversion cycle. Else, the ACE to Axium data conversion will be considered complete.

Data Conversion

There will be a three phase data conversion of ACE Patient data to Axium’s Rolodex functionality. The first phase is a sampling of conversion data migration from ACE to Axium. It is intended to be a baseline validation of the converted data elements and newly derived Axium required data elements. The objective is determine if ACE and derived data is compatible in Axium and to confirm the data extracted from ACE was uploaded 100% correctly in Axium. Sampling results will be approved before launching the testing phase.

The second conversion phase is the testing phase. It is a follow on phase to the approved sampling phase and dependent on its 100% success. The objective is to test the end to end migration of the required Patient data population from ACE into Axium. A test data base (Train) will be updated and conversion information will be produced to support the migration process. Conversion testing can be a reiterative process. The end to end conversion testing will be performed until any errors are resolved. A companion of the end to end conversion is to generate a validation of the conversion data. Data will be imported from ACE and Axium into Oracle tables used for reporting. A comparison report of like data elements will be generated. Any data conversion problems identified by report will result in conversion script revisions and another test cycle to be performed.

The third phase of the conversion is the Production upload. This phase is dependent on successful and approved conversion testing. The same steps conducted in the testing phase will be executed for the Production data migration. The difference being is that the Production data base will receive migrated data.

Roles and Responsibilities

Role	Resource	Responsibility
Project Manager	Walter Latham	Axium Project Manager
Data Conversion	Yaping Yuan	Data extracts, Exan/Axium communications, supporting project team members, support Axium Testing and Production cutover
Data Conversion	Dmitriy Mikhelzon	ACE conversion support, ACE Production cutover support
NJDS IT Director	Mark Cappelli	NJDS IT management
Report Writer	Debbie Ceci	Conversion data extract, loading and reporting
Axium Application Support	Exan Software	Software vendor that provided resources to develop or revise programmatic conversion executables for Patient data upload to Axium
Axium Support Conversion Lead	Brad Miller	Vendor’s lead for supplying NJDS with summary of conversion information used for loading Patient data to Axium, loading the Axium data and point person for resolving issues and answering questions
Axium Support Conversion Back Up	Brad Chen	Vendor’s support organization back up for supplying NJDS with summary of conversion information used for loading Patient data to Axium, loading the Axium data and point person for resolving issues and answering questions
Axium Support Conversion Back Up	Heather Knull	Vendor’s support organization back up for supplying NJDS with summary of conversion information used for loading Patient data to Axium, loading the Axium data and point person for resolving issues and answering questions

Data Translation

The following is a matrix of ACE Patient data elements being converted to Axium’s Rolodex for the Endodontic, Oral Surgery, Paediatric Dentistry, Periodontal, and Restorative departments:

NJDS Patient Data Conversion Field Mapping	7/13/2010

ACE patient field name	ACE Patient field description	AxiUm Field in Patient table except where noted in caps	Notes
chart_no	ACE chart No	Chart	In addition AltChart
last_name	Last
first_name	First
mid_init	middle initial	Middle
birth_date	Date of birth	Birth
ssn	Social security#	Sin
st_address	Address line 1	Address1
Suite_No	If apt_or_POBox = ‘A’, then address line 2 = apt + suite_no; if apt_or_POBox = ‘P’, then address line 2 = PO Box + suite_no.	Address2
apt_or_POBox	Address2
city	City
state	Province
zip	Zip code	Postal
home_phone	home phone No.	HomeArea + HomePhone	2 separate fields
day_phone	daytime phone No.	WorkArea + WorkPhone	“
day_phone_ext	Daytime phone# extension	WorkExt
gender	Male/female	Sex
status_code	Status
prim_assign_date	Date primary provider is assigned	PTPROD.StartDate	Where IsPrimary=1
sec_assign_date	Date secondary provider is assigned	PTPROD.StartDate	Where IsPrimary=0
prim_provider_id	Primary provider ID	PTPROD.Producer	Where IsPrimary=1
sec_provider_id	Secondary provider ID	PTPROD.Producer	Where IsPrimary=0
group_assignment	Patient’s primary clinic (use patient type)	PTTYPES.PatType
Chart location	ChartSort

Data Conversion Rules and Processes

Conversion criteria and processes are defined in the following section. They cover the necessary steps to migrate Patient data from ACE to Axium.

Selection Criteria

There will be a one for one conversion of ACE Patient data records to Axium Patient Rolodex records. Primarily, patient demographic data is the conversion’s requirement.

Axium Patient Rolodex data will be derived from fields in an ACE Patient data record. Please see Appendix for SQL scripts that derive this data.

Axium Address 2 will receive and Apt or PO Box prefix in addition to ACE Suite Number

Data conversion records will be bypassed for ACE Patients’ Chart#s that are already in Axium designated by specific prefixes and patient types.

ACE Group Assignment will be evaluated and translated to different values in Axium’s Patient Type.

ACE Primary Provider IDs will be prefixed with D’s or G’s in Axium depending on whether ACE provider is Undergraduate or PostGraduate.

Conversion Processing

User Procedures

NJDS IT will perform the extraction of Patient data from ACE for migration to Axium. SQL scripts will be run against the Production data base to output record counts and the required data to a file.

NJDS IT will upload the ACE extracted data file to the Exan server now being used for file transfers between the vendor and client. Conversion data will be stored in a Folder under as specific names to allow Axium Support to extract the required data.

Axium Support will extract the conversion data from the Folder used by NJDS for importing into the Oracle data base and eventually updating in Axium.

Axium Support will execute SQL scripts that update migrated Patient data into Axium’s Rolodex tables. Axium Support will compile conversion information and provide to NJDS IT. Patient loading error and reject information will be generated in the data migration process. Depending upon volume of information, Axium Support will either communicate with NJDS IT or load information to the server used for file transfers for access by NJDS IT.

NJDS IT will compare records counts from ACE extraction scripts to those provided by Axium Support for accuracy. NJDS will review error and reject information. Exan or NJDS conversion script corrections will be made before the next conversion test cycle. When an additional conversion cycle is required, NJDS will request Axium Support to restore the necessary data base from an archived version prior to the cycle beginning.

Using the original ACE Patient data extract, NJDS IT loads the extracted data into Oracle tables used for conversion validation reporting.

NJDS IT extracts the Rolodex data from Axium for conversion validation reporting. NJDS loads extracted data into Oracle table used for reporting.

NJDS IT generates an ACE to Axium Patient Data Comparison report. Report will compare each data element for each ACE patient record to its corresponding Axium field and reverse calculate the fields in ACE that derived for Axium. The link between patient and provider will be verified. Only fields failing these criteria will have Patient data printed on the report.

The Patient Data Comparison report will surface any conversion scripting errors in NJDS data extraction or Exan data uploading scripts. Scripts will be corrected and another conversion test cycle performed.

Backup and Restore

Backups of the Production instance are as per requirements and archived copies of the Train data base are done regularly. A restore of a data base is a standard procedure in place between NJDS and Axium Support.

Security

Axium Support has System Administration rights to the NJDS Production and Train data bases. This Oracle Responsibility is secured to the Exan individuals who will be engaged in the Patient data migration.

Administration access to ACE and Axium data bases and applications has been secured to individuals within the NJDS IT department. NJDS IT personnel will have the ability to extract Patient data from the Production data base.

Data moving in and out of the Exan FTP server is secured to individuals who have access rights.

An ACE and Axium Patient demographic data exception report will be generated by authorized NJDS IT personnel. These same personnel have access rights to view Patient data in the ACE and Axium applications.

The following is the Naming Standard used for loading data to the Exan FTP file server:

NJDS_ACE_Data Conversion_MMDDYYY_versionNN

Governance

Data Custodian

The existing custodian of ACE Patient data will continue to rely on ACE patient data for transaction purposes.

A programmatic synchronization of Axium Rolodex Patient data back to ACE will be in place to bypass the need to manually process patient data in both Axium and ACE.

Contractual agreements are in place that provides Axium Support the ability to migrate data into Train and Production data bases.

The Patient data end users will continue to have custodianship to ACE and Axium Patient data based on current security configurations.

Quality Assurance

There is a target of 100% of migration of all data elements from ACE to Axium for all ACE Patient data that are candidates for conversion. ACE Patient data will be migrated as is as of the data conversion date. A requirement of the conversion will be data elements needed in Axium that do not exist in ACE will be derived or calculated as part of the conversion. The Patient Data Comparison report will be used to identify conversions issues needing resolution.

APPENDIX

ACE to Axium Conversion SQL Script

Final Scripts will be incorporated into the final Data Conversion test results documentation.

Approval

The individuals below agree that they have reviewed and approved the contents of this Document.

APPROVED BY:
Function Role	Name and Title	Signature	Date