Central Paternity Registry - State of Ohio Procurement



Supplement 1: Central Paternity Registry Work and System RequirementsCentral Paternity RegistryIn Ohio, approximately 56,000 children are born out of wedlock each year. The Ohio Department of Job and Family Services (ODJFS) is the single state agency charged with responsibility to administer Title IV-D of the Social Security Act which requires the establishment of paternity and support. For children born out of wedlock, paternity can be established with an affidavit of paternity, an administrative order, or a court order. Paternity establishment is a necessary first step in the process of setting a child support order. In addition to a child support order, paternity establishment may result in eligibility for financial benefits including Social Security, pension benefits, veteran benefits, and inheritance benefits. Paternity establishment may also provide psychological and social bonds between father and child, and provide important medical history information.Unmarried parents can establish paternity by voluntarily signing an affidavit of paternity, naming the biological father as the legal father. Federal regulations require that the paternity affidavit must be signed by the biological father before his name can be recorded on the child’s birth record (birth certificate). At the time of a birth, while still in the hospital, a great opportunity exists to educate parents on the importance and benefits of establishing paternity, as well as to provide them with the paperwork to do so. The Ohio Central Paternity Registry (CPR) works closely with each birthing facility to ensure they have the knowledge and tools to assist parents in completing affidavits of paternity.In 1997, after Federal regulations required all states to establish central paternity registries, Ohio House Bill 352 mandated the creation of a central database of all parentage actions for children born out of wedlock. The database currently has more than 1,106,600 records that have been processed since January 1, 1998. During SFY 2017 (i.e., July 1, 2016 through June 30, 2017), the current CPR Contractor processed 52,477 documents. Additionally, the current CPR Contractor responded to approximately 250 - 300 calls per week, primarily from parents, hospital staff, registrars, Child Support Enforcement Agencies (CSEAs), and courts.1.0 Overview of the ProjectThe selected Contractor will be responsible for day-to-day operations of the CPR for ODJFS. The main functions of the registry include the receipt and processing of all paternity documents (affidavits, administrative orders, rescissions, and court orders), and the development and maintenance of a single database (the CPR database) that contains specific information from each paternity document. The selected Contractor shall be responsible for interfacing electronically with ODJFS and the Ohio Department of Health (ODH). They will also be charged with entering into contracts with birthing facilities and local registrars to establish performance standards for completed affidavits and to provide reimbursement to birthing facilities. The CPR program receives approximately 13,500 documents from birthing facilities, registrars, CSEA’s, courts etc., each quarter. Only the birthing facilities and registrars are reimbursed $20.00 per correctly completed affidavit. The current CPR Contractor facilitated payments to birthing facilities and registrars totaling $ 702,340 during SFY 2017. Additionally, the selected Contractor will be required to operate a call center on business days from 8:00 a.m. to 5:00 p.m. Columbus, OH local time. The CPR Contractor currently receives an average of 50 calls per day.The Paternity Establishment Percentage (PEP) is an important Federal performance measurement for Ohio. The measure is derived by dividing the total number of paternities established by the number of children born out of wedlock in the previous year. Therefore, it is vitally important that all paternity documentation is received by the CPR Contractor so that each paternity establishment can be counted. The selected Contractor will be responsible for reconciling completed paternity documentation by program partners with documentation received by the CPR program. Increasing the number of paternities established each year is also important. The Offeror will propose an outreach/marketing plan designed to target underserved populations for paternity establishment. 2.0 Objectives of the ProjectThe Contractor’s objectives will be to: Operate a Central Paternity Registry that fulfills state requirements to establish a single point of contact for all paternity actions in the State; Operate a call center and website that will serve as a resource for parents, birthing facilities, registrars, courts, and CSEAs to receive responses to their questions regarding procedures or specific cases; Perform data entry for each paternity document, retrieving information from each action so a database can be maintained for tracking and reporting; After data entry, forward all paternity documentation to ODH; Send electronic transmissions of all paternity documentation (currently twice a week) to ODJFS and ODH;Provide a data warehouse that State staff will have access to and from which reports, both scheduled and ad hoc, will be made available;Develop a team of Relationship Managers (RM), whose responsibility it will be to monitor Ohio’s Statewide Paternity Establishment Percentage (PEP) Score. The RMs will be the liaisons between program partners (birthing facilities, registrars, courts, clerks of court, and CSEAs) and the State Office of Child Support; andProvide training, instructional materials and outreach/marketing for the program.There is no specific library of documents, reports, or other information that Offerors interested in this RFP should consider. However, a wide variety of information on ODJFS and its programs which Offerors may find useful is available to the public via the ODJFS website at . The website for this specific program is oh-. 3.0 General Scope3.1 General Administrative RequirementsAttend Weekly Status and other Key Meetings - The State and Contractor Project Managers and other Project team members must attend weekly status meetings with other members of the Project teams on State premises as deemed necessary by the State to discuss Project issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.Birthing Facility Agreements – The Contractor must enter into agreements with all 108 Ohio birthing facilities for the purpose of completing paternity affidavits and the payment of appropriate fees. This paperwork must be completed by no later than 90 days after the contract award date. Sample facility agreements can be found in Supplement Three. Monthly Invoice – A monthly invoice must be submitted to ODJFS which includes the amounts paid to birthing facilities and registrars for the submission of valid affidavits as well as the charges to ODJFS for performance of other deliverables as separate line items. The invoice must be submitted on the Contractor’s letterhead. The billing date and service date must be included on the invoice. Supporting documentation must include an electronic list of hospitals and registrars receiving payments for valid affidavits during the invoice month. Invoices should identify the number of affidavits at each hospital and registrar. Invoices must be forwarded to a specific ODJFS address, as directed by the State.Facility Reimbursement – The Contractor will reimburse the facilities (birthing facilities/registrars) $20.00 for each correctly completed affidavit. Contractor will advance payments to the facilities within 15 days of the end of the calendar quarter, and will invoice ODJFS for this amount quarterly on their monthly invoices for August, November, February and May. IMPORTANT: Offeror cost proposals are to include the $750,000 amount to be passed through from ODJFS to the facilities for affidavit completion. For contract purposes, ODJFS will obtain a purchase order for the amount of the selected offeror's accepted cost proposal plus an amount appropriate for payments by the Contractor to birthing facilities for completed affidavits. The amount made available to the selected Contractor for completion of this deliverable will be based on historical volume and projections, and may be increased by ODJFS if actual use exceeds projections. Actual use of funds for this purpose by the selected Contractor must be fully documented. Contractor must assure that payments are made promptly and accurately. 3.2 Document Processing RequirementsDocument Processing – Monday to Friday on all non-Federal holidays, the Contractor must process original notarized affidavits, copies of administrative orders of paternity, certified court orders and rescission documents received from birthing facilities, local registrars, CSEAs, courts, and parents. The Contractor must date-stamp affidavits, administrative orders of paternity, certified court orders and rescissions on date of receipt. The Contractor must create a numbering process, which must be approved by ODJFS and ODH, to facilitate record identification. The Contractor must also create a batch numbering system for batches of two-hundred records.Document Review - The Contractor must review affidavits, administrative orders of paternity, certified court orders, and rescission documents for validity in accordance with criteria provided by ODJFS. Invalid documents will be sent back to the point of origin with a letter of explanation. The Contractor must track returned documents for correction and re-submission within the database. Upon completion of work with all such documents, the Contractor must provide them to ODH, twice per week, for comparison and permanent storage.Document Imaging - The Contractor must create and store images of all affidavits, and rescissions, excluding those that do not pass the review process at CPR. Additionally, the Contractor must create and store images of CSEA administrative orders establishing paternity and court orders establishing paternity. The imaged documents will be made available to the CSEAs and OCS staff through a password protected, secure portion of the website required in this RFP within 48 hours of the numbering of the document by CPR. IP authentication or restriction to access the secure CPR document site will be required. Legible images, scanned at 300 DPI or better, must be browser agnostic. All document images produced during this Contract are property of ODJFS. The Contractor must use the State’s Enterprise Document Management System which uses Hyland’s OnBase. The Contractor must develop multiple search criteria, including document number, mother's name, mother's social security number, mother's county of residence, father's name, father’s social security number, child's name, child's date of birth, date of birth date range, so the CSEAs and OCS can access copies without delays. The estimated volume of imaged documents is 50,000-55,000 per year. For FFY 2017, the current CPR Contractor imaged 52,773 paternity documents.Record Creation – Records should be created by entering the following information from each affidavit, administrative order, court entry, and rescission document into the database:Father's Name (first and last), Date of birth, Street Address, City and State, andSocial Security Number;Mother's Name (first and last), Maiden Name,Date of birthStreet Address, City and State, andSocial Security Number;Child's Name,Name change history,Social security number, Address, Date of birth, Sex, andCity, county and state of child's birth;Date paternity was established;Date the document was received by Contractor (Mail stamp date);Date the document was processed (entered into the database) by Contractor;Origin of the document (where the document came from);Type of document; andUnique document number assigned by Contractor.NOTE: This data-entry function must be performed in the greater metropolitan Columbus, Ohio area because same day delivery is required. A statement (with location) affirming the offeror’s compliance with this requirement must be included in the offeror’s proposal.Error Correction – Any documents sent to ODJFS or ODH that contain errors will be returned to the Contractor for database correction. They are to be corrected and re-processed within two business days.Timeliness and Accuracy - All data entry for affidavits and other records must be completed within two (2) business days of receipt. A quality assurance (QA) process must be established to ensure that processed records are 100% accurate. The QA process may be separate or be combined with data entry, however, all documents must be validated as 100% accurate within three (3) business days of receipt. Immediate action will be required by the Contractor when the accuracy rate falls below 100%. The Contractor will be responsible for creating an auditable process, for the purpose of providing a report of timeliness and accuracy. The State reserves the right to review this process at its discretion. If the Contractor determines a backlog has developed so that it cannot meet the two-day requirement, the Contractor must alert ODJFS immediately and include corrective measures to eliminate the backlog. File Transmission – The Contractor must transmit information electronically twice weekly (currently Tuesday and Thursday) to ODH and ODJFS. The transmission will consist of all new records processed by the CPR Contractor. Transmission must be completed by 10 am on the specified days. ODJFS requires secure plus transmission methods. The Contractor will be required to establish an account with ODH. ODJFS and ODH reserve the right to change the transmission requirements at any time. File Transmissions must meet the data security standards listed in Supplement 2. Hard Copy Transfer – On the same frequency as the electronic file transmission above, the Contractor must send the hard copy of all affidavits and other records to ODH for comparison and permanent storage.3.3 Training, Technical Assistance, & Community Education RequirementsNOTE: All instructional materials to be produced under this Contract are subject to approval by ODJFS. The printing of project materials is subject to State of Ohio regulations excluding the following: project correspondence; the introductory mailing announcing the Contractor's contact points and reports; and a reasonable number of copies of instructional materials for distribution to ODJFS for approval. Offerors are not to include printing costs in their cost proposals because ODJFS will print the approved materials. The selected Contractor will be required to provide finalized, approved documents in print-ready/reproduction-ready condition to ODJFS, sufficiently in advance of any scheduled distribution and dissemination of materials, to allow for any corrections and printing time. Reproduction of printed materials will be completed under existing ODJFS and State of Ohio agreements for printing services.Any and all instructional materials produced by the selected Contractor under terms of the contract resulting from this RFP shall be the sole property of ODJFS.Introductory Mailing - The Contractor must develop and send an introductory mailing to approximately 108 birthing facilities, 115 registrars, and 88 CSEAs (counts as of 1/1/2018). This mailing will include basic information on the Contractor's points of contact (including address, phone, fax, email, toll-free number and website). The Contractor is responsible for the costs of the introductory mailing, including postage. ODJFS shall provide the Contractor with the appropriate mailing list. Upon acceptance of successful transition requirements an introductory mailing that has been approved by the ODJFS must be sent as a letter or brochure in an envelope in conjunction with system go live. See Deliverable 11 in Section 7.7.Birthing Facility Staff Instructional DVD - The Contractor must produce an instructional DVD for use by birthing facilities and registrars' offices’ staff at the start of the contract term. The DVD must cover the key points of state regulations and any ODJFS rules for the completion and submission of paternity affidavits. The DVD must be of professional quality, produced in color, close captioned and designed as a standalone training aid. The Contractor must assume all responsibility for creation, production, copying and distribution of the DVDs. ODJFS retains approval authority for final content. At least 350 copies will be required. The Contractor will be responsible for mailing the DVDs to all birthing facilities and registrars' offices at contract initiation. The Contractor will also host the instructional video on the CPR website that is accessible to the birthing facilities, and registrars’ office staff (or any system user) through a secure log-in. See Deliverable 12 in Section 7.7.General Public Instructional DVD - The Contractor must produce a DVD that is 3-5 minutes in length for use by the general public (mothers, fathers, other family members) in birthing facilities. This DVD will also be used in other outreach/marketing efforts. The content of the DVD will stress the importance of paternity establishment. The Contractor is responsible for the creation of the DVD, production, and distribution of copies to all birthing facilities. The DVD must be of professional quality, produced in color, close captioned and designed as a standalone training aid. ODJFS shall provide the selected vendor with the appropriate mailing lists. The initial supply will be 250 DVDs that contain English, Somali and Spanish versions of the content described above. ODJFS has final approval rights for content. The general public instructional video must also be made available on the CPR website in all three languages. See Deliverable 12 in Section 7.7.Brochure - The Contractor must distribute multi-color tri-fold brochures provided by ODJFS that explain the affidavit process as part of its overall marketing effort. Initial and subsequent distribution of the brochures to birthing facilities, registrars, and CSEAs will be the Contractor's responsibility. Approximately 50,000 brochures will be available for the initial distribution in English, 5,000 brochures in Spanish, 5,000 brochures in Somali. Toll-free Number - The Contractor must maintain the existing toll-free number to receive inquiries regarding documents. The Contractor must report to ODJFS monthly as part of the activity summary report regarding the number of calls received on the toll-free number. The toll-free line will be operable from 8:00 a.m.-5:00 p.m. on work days (Monday through Friday), excluding state holidays. Voicemail must be available 24-hours a day. The Contractor must respond to all voicemail messages within one (1) business day.Website – In conjunction with go live, the Contractor must develop and maintain an Internet website conforming to ODJFS branding specifications and with broad appeal to a diverse population. See Deliverable 13 in Section 7.7. The website must include an overview of affidavit procedures and general information about paternity and rescission processes. The website will also clarify the role of ODH in birth record comparisons as required by law. Included in the website should be embedded videos, graphics etc., to provide a dynamic experience for the general user. The Contractor must ensure that the website has mobile compatibility, and that its contents are available in English, Spanish and Somali. Once per biennium, the Contractor, with the assistance of ODJFS, is required perform a routine audit and refresh of the website and its contents to ensure that it remains up to date. The website must include a secure section that the CSEAs and Office of Child Support (OCS) can access that will allow the CSEAs and the OCS to view and print imaged affidavits, rescissions, court and administrative orders. These images are for agency use only. Sufficient search criteria must be established to allow CSEAs to quickly locate documents for viewing and printing. Additionally, there must also be a secure log-in made available to birthing facilities, and registrars in order to view the instructional video. ODJFS has the right of final approval for the website content. The website must adhere to State of Ohio IT Policy IT-09 Web Site Accessibility which may be retrieved from As part of its submission, the offeror is required to submit sample wireframes of its proposed new website solution. The necessary branding information can be found in Supplement 3 Appendix BCorrespondence - Contractor must process and provide appropriate follow-up to all letters of inquiry or other correspondence sent to the CPR program from local registrars, hospitals, parents, or the general public. The Contractor must date stamp these items, and respond to matters under its purview within two (2) business days. The Contractor must maintain a log of the dates that correspondence was received and responded to for inspection by ODJFS. Any correspondence requiring an OCS response must be forwarded to OCS within two (2) business days of receipt.Relationship Management – The Contractor must utilize Relationship Managers (RM), to perform the following activities: Interact with program partners (birthing centers, registrars, courts, clerks of court, and CSEAs) for the purpose of providing guidance, training, performance monitoring and follow up with these entities. Minimum RM activities will include regularly scheduled visits (3-4 times per calendar year or as needed) to discuss the benefits of the paternity program, deliver materials, train staff, and lead discussion of practical barriers to completion of affidavits and other paternity documents and their timely delivery to CPR. Perform a monthly reconciliation to ensure the timely delivery of affidavits and other paternity documents to the CPR from all program partners by the 15th of the following month. Then provide a report to ODJFS with the results of the reconciliation. The reconciliation will compare State paternity establishment data maintained within the Support Enforcement Tracking System (SETS) with documentation received at CPR from program partners. Execution of the training plan described below in Section 3.3:10. Execution of the marketing plan described below in Section 3.3:9 (c). Provide a monthly report to ODJFS described below in 3.4:3. Client Outreach/Marketing – In order to enhance the paternity establishment program in Ohio, the Contractor must perform outreach and marketing to reach parents whose child(ren) need legal paternity established. The Contractor is required to submit a plan annually covering how they will market and grow the CPR program. It must include the benefits of paternity establishment for the child and must also include how the population to which the marketing will be directed will be identified. Further, it must also include a section reviewing the prior year’s plan and performance after the first year, including outcome and growth metrics covering the target populations as described below. The plan for regular outreach and marketing to underserved populations will include but not be limited to the following: Parents whose child(ren) need legal paternity established, Parents whose child(ren) have paternity established, but do not have a child support order established for the child(ren).Other potential customers from physician’s offices, prenatal clinics, public health offices, Head Start, Women Infant and Children (WIC) program, churches, and community centers.As part of their proposal, Offerors must include their suggested outreach/marketing plan. This plan should cover the Offeror’s unique approach to improving the State’s PEP score and how it plans to build relationships with care providers to underserved populations.Program Partner Training Plan – The Offeror must include in their proposal a training plan to conduct up to eight (8) training sessions total per year for program partners. The Contractor will be responsible for the content of the training sessions, development of training materials, securing locations, registering attendees, and evaluation of training effectiveness. Training should target the following audiences:Paternity affidavit training at birthing facilities, registrars and CSEA staff training – The Contractor must conduct regional training meetings for staff from birthing facilities, registrars and CSEAs. The sessions are to be held in various locations across the State of Ohio. The Contractor shall select the location of each regional training meeting, but it must be approved by ODJFS prior to the training session. Each session shall run approximately four (4) to five (5) hours in length and may serve up to 75 people at a session. Topics will include general affidavit procedures, and solutions to frequent issues that hospital and registrar staff regularly encounter (married mothers, minors, delayed signatures, etc.).Paternity order submission for courts and clerks of court – The Contractor must conduct training sessions for various judicial bodies. These training sessions may be provided at conferences, specially scheduled meetings, or through video conferences. Locations for training sessions may vary throughout the State and must be approved by ODJFS in advance. Dates and times for the training sessions will be determined cooperatively by the Contractor and ODJFS, with final approval by ODJFS. Topics will include the importance of accurate and timely order submission, review of forms used in the process, and ways to avoid common errors that are observed by the CPR staff.3.4 Reporting RequirementsTransition Report- This report should be a weekly status report covering all project activities and deliverables that are part of the database build and CPR transition process applicable that week. This must include the Discovery report, testing reports, bug fix reports, conversion reports and error reporting as applicable.Data Warehouse – The Contractor must make available to OCS a Data Warehouse that contains all the elements captured by the CPR Database. The Contractor will be responsible for working with OCS to meet the requirements set forth to accomplish data integration into the Data Warehouse, including making the data available in real time. All data must be stored in the Data Warehouse. By using a Central data warehouse solution, data access will be provided across all of OCS allowing for a more integrated reporting and inquiry environment for any given OCS operation. At a minimum, the Contractor must make the following pre-programmed reports available within the Data Warehouse downloadable in PDF and MS Excel. Affidavit Participation Report – provides a breakdown of affidavits received by individual birthing facilities, CSEAs, parents and registrars for the month. Affidavits received are to be summarized by under 18 and 18 and older. A sample of the report has been provided as Appendix C-Affidavit Participation Report to this RFP.Paternities Established Year-To-Date – The number of affidavits, court & administrative orders, and rescissions received from birthing facilities, CSEAs, courts, registrars and parents where applicable. Additionally, the report must capture births to non-Ohio mothers. The report must provide a statewide summary as well as a breakdown by county. The report must also have the capability of being produced under multiple date ranges such as calendar, state and federal fiscal years. A sample of the report has been provided as Appendix D-Paternities Established Year-To-Date Report to this RFP.Affidavit Efficiency Report - The number of affidavits received from each birthing facility, CSEA, registrar, and parents and the date paternity was rescinded (if applicable), and the amount of time (in days), each entity took to submit completed documents to CPR after the final notarized signature.Other reports must be developed as needed during the contract. The Contractor must also make the following monthly report available electronically within five (5) business days after the end of the previous month:Activity Summary Report:Statewide Paternity Establishment Percentage (PEP) Performance – the statewide PEP is the ratio of paternities established compared to children born-out-of-wedlock (BOW). This report item will be a forecast of the statewide PEP ratio to the end of the Federal Fiscal Year (FFY). The ratio will be calculated by determining the monthly average number of paternities established year to date and populating subsequent months with the average to the end of the FFY. This projected number will be compared to the BOW children.A record of data transmissions to ODJFS and ODH to include date transmitted and number of records.A report of relationship management activities – this report will detail the Contractor’s effort during the previous month in cultivating relationships with program partners who contribute to paternity establishment. Activities to report on will include any and all items addressed with program partners as outlined in Section 3.3 number 8 above. This report must include a calendar with past visits and future visits. Call Center Activity Reports – The Contractor must provide daily, weekly, and monthly reporting on Help Desk activities. Reports must include performance statistics as approved by the ODJFS. See section 5.0 Call Center for a list of metrics to be reported on.Timeliness and Accuracy Report – The Contractor must provide a report that demonstrates how a 100% data entry accuracy rate was achieved in the previous month.3.5 Transition Assistance ServicesThe Contractor must provide Transition Assistance Services to the State, or at the State’s request to the State’s designee to allow contracted services to continue without interruption or adverse effect and to facilitate the orderly transition to a new service provider. Transition Assistance Services must commence as follows:No less than six (6) months prior to expiration of this Contract or on such earlier date as the State may request; orUpon notice of termination/partial termination; orUpon notice of non-renewal of this Contract.For a period of up to three (3) months following the effective date of expiration, termination or non-renewal, at the State’s request, the Contractor will continue to provide Transition Assistance Services. Upon State request, the Contractor must provide Transition Assistance Services that include, at a minimum: Provide assistance, cooperation and information as is reasonably necessary to help enable a smooth transition of the applicable Services to the State or its designated service provider.Provide information as the State may reasonably request relating to the number and function of each of the Contractor personnel performing the Services.Transfer State-owned data, information, deliverables, work products, documentation, etc.Identify any dependencies on the new service provider necessary for the Contractor to perform the Transition Assistance Services.Assist the State in the identification of significant potential risk factors relating to the transition.Assist the State in designing plans and contingencies to help mitigate identified risks.Submit a Transition Plan, for approval by the State, which includes a timeline for successfully completing the Transition Assistance Services.Meet with State staff and new awardee staff on an as needed basis to be decided by ODJFS.Schedule and plan for Contractor’s return to the State (i) the State’s service locations then occupied by Contractor (if any), and (ii) the State’s Confidential Information, State Data, documents, records, files, tapes and disks in Contractor’s possession.The Contractor must provide a single point of contact who will be responsible for Contractor’s overall performance of the Transition Assistance Services. 4.0 Staffing RequirementsStaffing PlanThe Offeror must provide a staffing plan that identifies all the personnel by position that the offeror proposes and that are required to operate the Central Paternity Registry. The staffing plan must show each individual’s responsibilities on the Project. The State also requires a staffing plan that matches the proposed Project key personnel and qualifications to the activities and tasks that will be completed on the Project. At minimum, the Offeror’s proposal must identify the following Key Project Personnel: (1) Project Manager, (2) IT Lead, (3) Outreach/Relationship Managers. In addition, the plan must have the following information:An organizational chart including any sub-Contractors, key management and administrative personnel assigned to this project;A contingency plan that shows the ability to add more staff if needed to ensure meeting the Project's due date(s), outreach/marketing and relationship management requirements; A statement and a chart that clearly indicates the time commitment of the proposed Project Manager and the Contractor’s Key Project Personnel, inclusive of the Project Manager and the Contractor’s proposed team members for this Work during each phase of the Project.The Offeror also must include a statement indicating to what extent, if any, the candidates may work on other projects or assignments that are not State related during the term of the Contract. The State may reject any Proposal that commits the proposed Project Manager or any proposed Key Project Personnel to other projects during the term of the Project, if the State believes that any such commitment may be detrimental to the Contractor’s performance.The State expects that the proposed named Key Project Personnel will be available as proposed to work on the Project. Resumes for the proposed candidates must be provided for all Key Project Personnel. Representative resumes are not acceptable. The resumes will be used to supplement the descriptive narrative provided by the offeror regarding their proposed project team.The resumes (2-page limit per resume) of the proposed Key Project Personnel must include: Proposed Candidate’s Name;Proposed role on this Project;Listings of completed projects that are comparable to this Project or required similar skills based on the person’s assigned role/responsibility on this Project. Each project listed should include at a minimum the beginning and ending dates, client/company name for which the work was performed, client contact information for sponsoring Directors, Managers or equivalent level position (name, phone number, email address, company name, etc.), project title, project description, and a detailed description of the person’s role/responsibility on the project.Education;Professional Licenses/Certifications/Memberships; andEmployment History.In addition to providing a resume, the Contractor must provide a detailed narrative highlighting why the proposed Key Project Personnel possesses the necessary experience, education, training and professional certifications to successfully perform their assigned role/responsibility on the Project. This can be accomplished on Attachment 7 of the RFP document, Offeror Profile forms.Project ManagerThe proposed candidate must have experience as a full-time Project Manager overseeing the implementation of a document and workflow management project that is similar in size and scope to this project. He or she must also have experience as a full-time Project Manager responsible for system requirements development, specification, design and implementation to the production of an enterprise level management system in the public sector.The candidate must have five (5) years’ experience or more implementing and managing complex public sector programs and must have at least a bachelor’s degree from an accredited college. IT LeadThe candidate must have experience as an integration architect for a document and workflow management implementation project that is similar in size and scope to this project. He or she must have at least a bachelor’s degree from an accredited college.Outreach/Relationship ManagersThe offeror must propose sufficient staff to perform the duties detailed in Section 3.3:8 above. The candidates will have demonstrated and referenceable experience developing professional relationships with a broad range of individuals such as; elected officials, medical professionals, state and county child support professionals, etc. Candidates will also demonstrate an ability to balance multiple responsibilities and manage shifting priorities without direct supervision. They must also have experience in outreach/marketing and training materials creation and delivering user training for a wide range of audiences. He or she must have at least a bachelor’s degree from an accredited college. 5.0 Call CenterThe Contractor must staff the Customer Service Help Desk throughout the day with the number of operators appropriate to meet the performance specifications defined below:Maintain the average call response time at or below 60 seconds;Respond to all email inquiries within one (1) business day;Respond to all voicemail inquiries within one (1) business day;Respond to all correspondence received within two (2) business days;Maintain, at a minimum, a monthly average call answer rate of 97%; andMaintain a busy rate at or below 1% of calls.The Contractor must receive inquiries and provide an automated response for any known problems through the following means at a minimum:The existing toll-free phone number;E-mail;Fax;P.O. box; andAny alternative methods proposed by the Contractor (e.g. online portal, instant message, etc.).6.0 General System RequirementsBased on the State’s priorities that factor cost, ability to migrate to the new operating environment, integrations and conversion considerations and other factors, a minimum set of project requirements for each phase is identified later in this Supplement. The Offeror is strongly encouraged to provide its approach and project implementation plan based on its own demonstrable success and experience that would lead to the most cost-effective and low-risk implementation of the Solution that meets the RFP requirements.The State Office of Information Technology offers an Enterprise Document Management Service utilizing Hyland, OnBase. All offerors must provide a response that utilizes this DMS solution provided internally by the State. Supplement 3 provides additional information to help the offeror provide appropriate configuration requirements. Proposals must include all relevant OnBase configuration requirements. The Contractor will be responsible for implementation,?maintenance and support of the OnBase instance used as a part of this solution.The proposed solution must use the “Hyland OnBase” platform. Any proposals that contain an alternative solution will be automatically disqualified, unless the Offeror can demonstrate a substantial cost benefit / ROI to the State.Required System EnvironmentsThe State requires that the following environments, at a minimum, will be provided and supported for the new installation of the proposed solution(s). The offeror may propose any additional environments if they believe these environments are required to provide a fully functional solution based upon the offeror’s approach.Development;System Test;UAT;Production.System Access: User AccountsA valid, active user ID and password must be utilized to access the website. The website will include a maintenance function for administrators to add, modify and inactivate user access for the system. The website will maintain the following data elements for the user account:UsernameUser First NameUser Last NameUser TitleUser TypeUser Email AddressPasswordDate Added (read-only)Date Modified (read-only)User Last Modified (read-only)Operational RequirementsThe CPR system must be available except during scheduled maintenance and be designed to accommodate high usage must be during normal business hours of Monday-Friday 7am through 6pm Columbus, Ohio local time with no planned or unplanned outages during these hours.Disaster Recovery & BackupsThe Central Paternity Registry data will be backed up using State backup devices once data is saved to the State’s OnBase solution by the State using Contractor provided scripts, backup target file systems or databases scripts and methods once each business day to capture as many completed transactions as possible and to not impede State access to, or use of, the system.CPR system data will be retained according to State data retention policy.Policy ComplianceThe solution provided by the Contractor must be in compliance with State Security, Data Handling, IT and Access Policies contained in Supplement 2 of this RFP.7.0 System Conversion Phases and RequirementsThe Project’s Life Cycle as described earlier represent the logical progression of the Project. The following subsections describe the responsibilities, tasks, activities and deliverables required for successful completion of each phase. The offeror must provide details on their Project approach to phasing including methodology and rationale.The offeror should note that Managed Services and Operational Support responsibilities will begin with the initial release of functionality into the Production environment. 7.1 ConstraintsAll CPR logins will need to be reestablished on the new solution with the existing login and password;All CPR logins will be driven to a password reset on first login to the new solution;The State of Ohio will provide a small set of data to support a “pilot” conversion onto the new system;All the CPR accounts need to be moved in one block before the new site can go into service.7.2 Conversion Phase - InitiateThis phase initializes the Discovery period and commences the activities to successfully implement, at a minimum, the Project requirements, establish Project teams and conduct kick-off meetings. The Contractor must conduct a Project kick-off meeting with State identified project members and Contractor resources. The State will be responsible for organizing and conducting any necessary kick-off meetings with stakeholders. However, the Contractor will be required to participate and provide support as necessary for these stakeholder kick-off meetings.In this phase, the Contractor must also lead planning sessions to ensure, at a minimum, the following: A common understanding of the project implementation approach and work has been established; A common vision of all deliverables has been established; All elements and Work Products of the Preliminary Project Plan as listed under Deliverable 001 described later in this section are produced, reviewed and validated by the State;Clarity on scope of overall project and the responsibilities of the Contractor have been defined and agreed to by the State.Additionally, the Contractor is required to establish and maintain all required Project reporting for status, risk and issue management, changes, decisions, resource management, schedule, and other reporting needs not otherwise stated in here. A critical component of the Preliminary Project Plan is the Quality Management Plan (QMP) which describes how quality will be managed throughout the lifecycle of the project, and defines how the Project Team will implement, support, and communicate project quality practices for use with the project. It also includes the processes and procedures for conducting quality planning, quality assurance and quality control.The following table contains, at a minimum, the list of tasks and the roles and responsibilities for the State and Contractor for the Initiate phase:Initiate Phase Key TasksStateContractorConduct Project kick-off meetingSupportPerformIdentify State stakeholders and manage expectationsSupportPerformIdentify and verify project scope SupportPerformVerify project implementation approachSupportPerformCreate the project Work Breakdown Structure (WBS)SupportPerformCreate a preliminary project plan and all related Work Products SupportPerformPrepare for and conduct on-going project meetings SupportPerformCreate and maintain Project status reports SupportPerformReport and manage issues and risksSupportPerformAssist with on-boarding for the Contractor resourcesSupportPerformConfirm State Project staffing PerformSupportConfirm Contractor Project staffing SupportPerformConfirm Project governancePerformSupportProvide planned checkpoint review datesSupportPerformThe Contractor must submit the following deliverable with the associated elements and Work Products (WP) listed below:Preliminary Project PlanImplementation Scope for Project Implementation (WP)Identified out-of-scope areas (WP)Project Work Breakdown Structure (WBS) (WP)Project Schedule – including sub-projects supporting WBS, Review Checkpoints (WP)Project Team Rosters and State-Verified Roles and Responsibilities Matrix (WP)Project DependenciesProject’s Critical PathQuality Management Plan (QMP) (WP)Preliminary Benefits Realization Measures (WP) Project Management Approach (WP)7.3 Conversion Phase - AnalyzeThis phase is primarily intended to review, verify, and finalize the State’s requirements and business processes, to establish the benefits realization baseline data, and prepare for Solution design and blueprint. The Contractor must conduct a fit-gap analysis of the capabilities of the Solution, best practices, the operating environment, and other available State application tools as they relate to the requirements in this Supplement. Also, the Contractor must recommend changes, as applicable, which will improve the State’s business processes and requirements. The Contractor must lead, document and complete the analysis. The Contractor must also analyze impacts to the integration points with external systems, for example ODH’s system. In addition, the Contractor must analyze external systems and, where applicable, recommend approaches to retire, integrate with, or convert/migrate data into the Solution.The outcome of all analysis activities in this phase must be a State approved final and definitive set of requirements and Requirements Traceability Matrix (RTM). The Matrix must document and associate each requirement to all relevant Solution functionalities, Configurable or Customization components, customizations, extensions, integrations, and conversions.The following table contains at a minimum, the list of tasks and the roles and responsibilities for the State and Contractor for the Analyze phase: Analyze Phase Key TasksStateContractorReview requirements & system functionalitySupportPerformIdentify integration/conversion pointsSupportPerformProvide functional impacts on external systemsSupportPerformDefine technical environment requirements for the project from Design through Deployment and Run. This includes any components or tools required to support development, test, configuration management, etc.SupportPerformComplete and document definitive technical and integration requirementsSupportPerformComplete and document definitive conversion requirementsSupportPerformCreate Requirements Traceability Matrix (RTM)SupportPerformBegin stakeholders’ communicationsPerformSupportIn relation to the tasks above, the Contractor must provide the following two deliverables:Requirements vs. Functionality GapDiscovery Reports (WP)Definitive Business Requirements (WP)Definitive Conversion Requirements (WP)Definitive Technical and Integration Requirements (WP)Requirements Traceability Matrix7.4 Conversion Phase - DesignFrom the decisions made during the Analyze phase, the Contractor must prepare implementation strategies and recommendations for State confirmation and direction; prepare an overall “To-Be” architecture and system blueprint reflecting the finalized and approved Solution components; and provide a detailed implementation plan for fully deploying the Solution blueprint to a production status. This implementation plan must include, at a minimum:Documents detailing functional, configuration and customization/extension designs/information;Specifications for Production, Test and other system environments; andDocuments detailing Technical, Integration, and Data Conversion designs/information. The Functional Designs created in this Phase must address, at a minimum, data conversion, business and security impacts as well as identify integration points to external systems.The Contractor is expected to be responsible to collaboratively work with the State’s Document Management System (DMS) Team to articulate the solution for the Application to DMS Service Integration into Design Requirements.? Once completed and the Build Phase initiates, the Contractor must develop the solution, and where possible, or needed (as specified by the submitted project plan), the Contractor must work collaboratively with the DMS Team in order to complete the Interface.The Contractor must advise the State of any Out of the Box or configured functionality that could be used in lieu of customizations / extensions to meet State requirements and identify any necessary changes to State requirements, processes, policies and, if applicable, Revised Code.Also, required in this Phase is the development of a Detailed Project Plan that must be approved by the State. The Contractor must perform and successfully complete, at a minimum, the following tasks in Design phase: Design Phase Key TasksStateContractorCreate Functional designs according to the requirementsSupportPerformValidate current or design new business processesSupportPerformValidate and Finalize the overall “To-Be” ArchitectureSupportPerformFinalize project scopeSupportPerformDesign Production environment to specsSupportPerformDesign Test environment to specsSupportPerformDesign integrations and interfacesSupportPerformDesign conversion pointsSupportPerformCreate/finalize the Solution’s blueprint SupportPerformCreate Conversion strategy and planSupportPerformCreate System and User Acceptance Test strategies SupportPerformDesign/develop testing scenarios and scriptsSupportPerformCreate Master Test planSupportPerformUpdate Requirements Traceability Matrix with design and configuration cross referencesSupportPerformCreate and update the security designs for the solutionSupportPerformClassify new data introduced in the system to identify data elements that need to be added to the list of confidential and sensitive dataPerformSupportCreate/finalize Detailed Project Plan for Project Implementation SupportPerformThe Contractor must provide the following Overall “To-Be” Architecture & System Blueprint deliverable with the associated Work Products:Overall “To-Be” Architecture & System Blueprint Functional Design Documents (WP)Production / Service Design & plan (WP)Technical / Integration Design & Plan (WP)Information Security Requirements and Impact on Integration Points (WP)Interface Approach and Design (WP)A collection of required standard and custom reports to meet State requirements (WP)An Inventory of all workflow deployment and configuration designs, values and validation specifications (WP)Configuration and Integration Requirements for all Third-Party systems (WP)In addition to Deliverable 004, the Contractor must, in collaboration with the State, create a conversion strategy plan which describes what system records are to be converted and/or migrated into the solution and clearly define/describe the data elements involved.The Contractor must provide the following Conversion Strategy and Plan deliverable:Conversion Strategy and Plan Includes List of Systems/Data Being Converted and/or MigratedThe Contractor must also create and provide detailed testing plans early in the Project. The types of tests required will be determined as an outcome of design iterations. During this phase, the Contractor will create a Master Test Plan that includes a collection of all test plans for various functions and parts of the Solution. It is expected that the Master Test Plan will evolve with additional details throughout subsequent phases of the Project.The Contractor must provide the following Master Test Plan deliverable with the associated Work Products:Master Test PlanFunctional Testing Plans/Scenarios & Procedures (WP)System Performance Testing Plans & Procedures (WP)Integration Testing Strategy & Plan (WP)User Acceptance Testing (UAT) Strategy and Plan (WP)Operation Readiness Test (ORT) Plan & Procedures (WP)Production/Service (Configured System) Acceptance Criteria (WP)Integration Acceptance Criteria (WP)Conversion Acceptance Criteria (WP)Using the Preliminary Project Plan developed in the Initiate phase, the Contractor must develop a Detailed Project plan that addresses rollout/implementation. The Contractor must provide the following Detailed Project Plan deliverable with the associated Work Products:Detailed Project Plan Finalized Implementation Scope for Project Implementation Periods 1 and 2 (WP)Validated identified out-of-scope areas (WP)Comprehensive Project Work Breakdown Structure (WBS) (WP)Detailed Project Schedule - including sub-projects supporting WBS, Review Checkpoints (WP)Definitive Project Team Rosters and Finalized, State-Verified Roles and Responsibilities Matrix (WP)Validated Project DependenciesFinalized Project’s Critical PathFinalized Project Management Approach (WP)7.5 Conversion Phase - BuildIn this phase, the Contractor must complete Solution setup, configuration, customization / extension, and necessary integrations and conversions (in test and production environments) based on the functional designs and decisions made in the Analyze and Design phases. This process must also include preparing and delivering test scripts which can be utilized by the State to support regression testing required during the Project and following implementation. During this phase all system defects should be managed and resolved by the Contractor. The Contractor is expected to work with the State’s Enterprise Document Management System (DMS) Team where those defects are consuming a part of the DMS Service during the resolution.? Where the Contractor’s system and the State’s join, the Contractor is expected to work collaboratively with the DMS Team during the Design and Implementation Phases of the Project to ensure all aspects of the Service’s Requirements are considered and woven into their approach.The Contractor must perform and successfully complete, at a minimum, the following Build phase tasks: Build Phase Key TasksStateContractorBuild and Unit Test the Solution Production environment as applicableSupportPerformBuild and Unit Test Customizations/Extensions as applicable SupportPerformBuild and Unit Test updates to Production Environment (i.e. interfaces, print, security services, etc.)SupportPerformBuild Test Environment(s) SupportPerformBuild Training environment SupportPerformIntegrate systems according to plan & create required interfaces (as applicable)SupportPerformMap data fields according to conversion plan & convert data (as applicable)SupportPerformSupport all environments, including patches and fixesSupportPerformDesign/develop testing scenarios and scriptsSupportPerformHold conversion meetings as needed with current vendor and State staffSupportPerformThe Contractor must provide the following Test deliverable:Test and Production EnvironmentsInclude Managed Services to maintain both environmentsRecognize State’s Production Acceptance Criteria (PAC)Provide refresh procedures indicating the process to refresh data in Test from ProductionEnvironments Accepted by the State Configured, Customized and Test-Ready Collection of Documented final Test Results (WP)7.6 Conversion Phase - TestThe Test phase will check all aspects of the Solution including but not limited to its functionality, performance, integration, and the conversion/migration of relevant data. Offeror Note: With respect to testing activities, the Contractor is responsible for all activities associated with System Test while the State will participate in these activities. The State is responsible for User Acceptance Testing (“UAT”) Test execution while the Contractor will be responsible for test preparation, management and tracking of UAT activities.System Test focuses on the customizations/extensions, configurations, workflow and integrations. Test conditions and test scenarios to be included in the System Testing will be mutually agreed upon by the Contractor and the State. These scenarios will be based on an analysis of the requirements, changes, and modifications that are approved for implementation.UAT verifies the usability of the new processes and ensures that the system meets the requirements and the needs of the organization and the end user. UAT leverages System Test Scripts and is executed by State resources. A key objective of UAT is to facilitate an understanding of the technology and the business change being implemented. The Contractor must provide all support necessary for the State to conduct Security Testing of each functional release which may include activities such as manual testing of the system and loading of maliciously formatted inbound interface files.The Contractor is responsible for all unit, system, performance and regression testing of the Solution and system-related changes. Such changes must not be introduced into a Production environment until they have been through the complete test cycle described above and approved by the State after a successful UAT. The Contractor must remedy all bugs/defects discovered during testing and maintain a bug/fix tracking report that clearly identifies each bug detected in testing, the status of the resolution, and the projected fix/resolution date. The Contractor must also provide additional testing steps if needed as part of the bug fix/resolution.The Contractor must develop and prepare weekly status reports to monitor the progress of each test phase. The status reports will contain at a minimum, sections for condition creation, script creation, script execution, issue identification and resolution, and defect identification and resolution.The Contractor must, to the extent possible, implement measures to help avoid unnecessary recurrence of incidents, by performing root cause analysis and event correlation for items discovered during testing/validation activities.Before go-live, the Contractor must provide an interface assurance plan that outlines the monitoring and reporting mechanisms that they will put into place to ensure that the interfaces are operational. Failure to detect that the interface is down will count as a critical failure even if the root cause is shared or originates on the State side.The Contractor must perform and successfully complete, at a minimum, the following Test phase tasks: Test Phase Key TasksStateContractorDevelop and maintain test data repositories as agreed appropriateSupportPerformPerform batch testing with each system the CPR solution interfaces withSupportPerformManage and track System /Regression Test, and UATSupportPerformExecute System / Regression Test and document resultsSupportPerformExecute UATPerformSupportDocument UAT resultsSupportPerformPrepare for and execute Security TestPerformSupportPrepare for and execute Performance TestSupportPerformSupport Functional Team TestingSupportPerformDevelop, update and maintain a migration checklistSupportPerformPrepare for final move to ProductionSupportPerformPrepare for and execute Assembly TestSupportPerformPrepare for and execute Performance TestSupportPerformSupport Functional Team TestingSupportPerformConduct tests for moving to ProductionSupportPerformProvide updated Test Scripts to the Status for UATSupportPerformMigrate release functionality to UAT environmentSupportPerformInterface Assurance PlanCatalog all systems the CPR solution will need to interface with, including but not limited to, those at ODH, the website, the data warehouse, and SETS.Provide detailed results of each batch test performed with all systems with which the CPR Solution will interface.Provide a detailed monitoring plan for each system interface used by the CPR solution.7.7 Conversion Phase - DeployAt the end of successful testing, the functionality will be deployed. The Contractor must manage the deployment activities and must conduct a deployment readiness assessment to determine the technical readiness of the Solution functionality for Go-Live. Part of the readiness assessment will be to determine that the State has reviewed and accepted all functional, technical, and OCM requirements. For the purposes of Solution functionality deployment, Go-Live means the point at which the relevant users are trained, have their roles assigned, and are provided access to the Production environment to begin conducting their official business. The Contractor, with the State’s approval, must drive the technical planning and execution for the system deployment which includes, at a minimum, the coordination of software deployment to the file server elements, deployment of interfaces, any required data conversions/migrations, installation and verification of any required middleware products, installation of server software, and any required verification to achieve the proper roll‐out of the application software.To receive State approval to deploy, the Contractor must confirm that the following pre-deployment tasks are completed for each Release which comprise the State’s Production Acceptance Checklist (PAC):Revise Requirements Traceability Matrix to reflect as implementedProvide a list of all customizations and components as implementedProvide detailed System Test Cases and Demonstrate Successful Completion of SameProvide detailed Performance Testing Results Demonstrate completion of final State User Acceptance Testing and an affirmation of same by the StateProvide final Operational Readiness Testing Results and an affirmation of same by the StateComplete User and System Administration Documentation that represent the system as implementedProvide updated/final Solution Architecture and Blueprint documentsAny deviation, partial acceptance or waiver of PAC requirements must be agreed to in writing and in advance by the State.The Contractor must develop and submit for State approval, a Deployment and Stabilization Plan which addresses all deployment and go-live activities. This Plan will include both Contractor and State activities identifying all required resources, roles and responsibilities. The Plan will also include a deployment and go-live schedule which must be mutually agreed to by the State and the Contractor. Once approved by the State, the Contractor will be responsible for managing the execution of the Plan.Upon deployment, the Contractor will begin measurement and tracking of the established benefits metrics associated with the functionality being deployed. Measurements will be assessed against the established baselines and based on trending, projections of potential future benefit realization numbers will be estimated.The Contractor must perform and successfully complete, at a minimum, the following Deploy phase tasks: Deploy Phase Key TasksStateContractorExecute required data conversions or migrations as applicable.SupportPerformCreate the Deployment and Stabilization PlanSupportPerformPerform required data matching activities and error reporting as applicableSupportPerformDocument data issues and provide to the State for resolution as applicableSupportPerformCompile and maintain solution issue listsSupportPerformProduce an end-to-end final validation of the operational architecture and corresponding operational documentation for the upgraded and implemented modulesSupportPerformConduct quality and progress reviews with appropriate State personnelSupportPerformTransition solution support responsibility according to the Deployment & Stabilization PlanSupportPerformManage training environments sufficient to support the overall training effortSupportPerformCreate and distribute introductory mailingSupportPerformCreate and distribute instructional DVDsSupportPerformCreate new program websiteSupport PerformDeployment and Stabilization PlanFunctional Release Go-Live Technical Readiness Assessment (WP)In conjunction with successful go live, the Contractor must send an introductory mailing to all birthing facilities, registrars and CSEAs as described in Section 3.3.1. Introductory MailingIn conjunction with successful go live, the Contractor must produce and send Instructional DVDs to all birthing facilities, registrar’s offices and CSEAs as described in Section 3.3.2 Birthing Facility Staff Instructional DVD and 3.3.3 General Public Instructional DVD. Instructional DVDsIn conjunction with successful go live, the Contractor must create a website for the program that conforms with the requirements described in Section 3.3.6.Program Website7.7.1 Conversion Phase – Deploy- Performance Period ResponsibilitiesA successful Performance Period is required to demonstrate that the CPR solution meets requirements and performs according to State-approved Service Levels for a period of up to thirty (30) consecutive days unless otherwise agreed by the State. In the event that a Severity 1 or 2 issue or any critical blocking issue, as defined in the Service Levels section of this Supplement occurs during this 30-day period, this 30-day period may be extended at the sole discretion of the State for a period commencing upon satisfactory resolution of the issue in the production environment. Under no circumstances will the Contractor performance during this period, including successful conclusion of this period (i.e., no Severity 1 or 2, or critical blocking issues detected for 30 consecutive days) be construed as relief from, or reduction to, any requirements or responsibilities contained in this RFP for a complete, operational CPR product. During the Performance Period, the Contractor must measure, monitor and report to the State its performance against the relevant Service Levels then in effect. It is the State’s intent to work with the Contractor on adjusting any Service Levels during the Performance Period, if necessary. The State does not intend to assess performance credits based on Service Levels during the Performance Period. Once the Performance Period is successfully completed as determined by the State, then the Contractor may submit the production release for State acceptance. Once the State accepts the production release, the Contractor must manage, maintain and operate the solution according to the terms of the Contract and the State-approved Service Levels will apply. The State’s final acceptance of the system is conditional upon a successful Performance Period defined herein and in Attachment Four, Part Five: Standards of Performance and Acceptance. Upon the successful completion of the Performance Period, the Contractor must present the production release of the CPR Solution to the State for acceptance by submitting a system certification letter. During the Performance Period, the Contractor must at a minimum:Provide personnel with the requisite skills and experience levels in the solution to answer questions that the State may have;Address any software defects, gaps, omissions or errors that are discovered in the Contractor’s work as they pertain to operation in a production environment;Resolve any performance, compatibility or configuration issues that arise as a result of migration of the Contractor’s work to a production environment; Document any relevant changes to operational, configuration, training, installation, commentary or other documentation as a result of migration to the Contractor’s work to a production environment; andProvide personnel with the requisite skills and experience levels in the solution to perform production issue triage, root cause and remedy analysis and wherever possible propose workarounds, fixes, patches or remedies (code-based, procedural or environmental) required to successfully operate the CPR solution in a production environment.If the production release of the CPR solution fails the Performance Period, the Contractor will be in default and the State may apply the remedies available to it under the Contract. The Contractor must provide the following deliverable to certify the State’s acceptance of the Performance Period for each functional release:Certification Letter of State’s Acceptance Functional Release7.8 Conversion Phase - RunFollowing initial release of functionality, the Contractor will assume the Run Phase responsibilities of ensuring that all operating environments are fully functional, maintained, and supported. Details of these Contractor responsibilities are defined in Section 8, Service Level Agreements. 8.0 Service Level Agreements and Contractor Fee Credits8.1 Parties and TimelinesThis service level agreement is effective as of the date of award of this work. ODJFS and the service provider shall review at least quarterly to determine if any modifications or amendments are needed to reflect the State support requirements and service provider’s services.8.2 Responsibilities of the State and ContractorThe State is responsible for the DMS solution. Once the document has been verified to have been successfully imported into the OnBase system, the responsibility for the documents falls on the DMS. Any part of the solution prior to permanent storage is the responsibility of the Contractor. Additionally, if the DMS is used for any front end processing, that portion of the Solution is also the responsibility of the Contractor.8.3 Service Level FrameworkThis section sets forth the functional and technical specifications for the Service Level Agreements (SLA) and Service Level Objectives (SLO) to be established between Contractor and the State. This section contains the tables and descriptions that provide the State framework and expectations relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. This document defines the State’s detailed performance, management, and reporting requirements for all Contractor Services under this RFP.Both the State and Contractor recognize and agree that new categories of Service Levels and Performance Specifications may be added during the term of the Contract as business, organizational objectives and technological changes permit and require.The method set out herein will be implemented to manage Contractor’s performance against each Service Level, in order to monitor the overall performance of Contractor.Contractor will be required to comply with the following performance management and reporting mechanisms for all Services within the scope of this Statement of Work:Service Level Specific Performance – Agreed upon specific Service Level Agreements to measure the performance of specific Services or Service Elements. The individual Service Level Agreements are linked to Performance Credits to incent Contractor performance; andService Level Requirements: Maintenance, Operations & Run ServicesThis section sets forth the performance specifications for the Service Level Agreements (SLA) and Service Level Objectives (SLO) to be established between the Contractor and the State that are applicable to any work associated with the operation, maintenance, updates or upgrades of any software associated with this Supplement in general, and as the work pertains to any Operations and Run services.The section contains the tables and descriptions that provide the State framework, requirements relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. This document defines the State’s detailed performance, management, and reporting requirements for the Operations and Run Services and to all subsequent Operations and Run services and phases that are contracted under future Statements of Work between the State and the Contractor related to this RFP. The mechanism set out herein will be implemented to manage the Contractor’s performance against each Service Level, in order to monitor the overall performance of the Contractor.The Contractor will be required to comply with the following performance management and reporting mechanisms for all Services within the scope of this RFP and will provide these reports to the State on a no less frequent than monthly basis: Service Level Specific Performance – Agreed upon specific Service Levels to measure the performance of specific Services or Service Elements. Most individual Service Levels are linked to financial credits due to the State (“Performance Credits”) to incent Contractor performance.Service Level Specific Performance Credits – Each Service Level (SL) will be measured using a “Green-Yellow-Red” traffic light mechanism (the “Individual SL GYR State”), with “Green” representing the highest level of performance and “Red” representing the lowest level of performance. A Performance Credit will be due to the State in the event a specific Individual SLA GYR State falls in the “Yellow “or “Red” state. The amount of the Performance Credit for each SLA will be based on the Individual SLA GYR State. Further, the amounts of the Performance Credits will, in certain cases, increase where they are imposed in consecutive months. No Service Level Performance Credit will be payable for the Contractor’s failure to meet a Service Level Objective.Set forth below is a table summarizing the monthly Performance Credits for each SLA. All amounts set forth below that are contained in a row pertaining to the “Yellow” or “Red” GYR State, represent Performance Credit amounts.Consecutive (SLA Performance Credits)Individual SL-GYR State1st Month2nd Month3rd Month4th Month5th Month6th Month7th Month8th Month9th Month10th Month11th Month12th MonthRedA =1.71% of MPCA + 50% of AA + 100% of AA + 150% of AA + 200% of AA + 250% of AA + 300% of AA + 350% of AA + 400% of AA + 450% of AA + 500% of AA + 550% of AYellowB = 0.855% of MPCB + 50% of BB + 100% of BB + 150% of BB + 200% of BB + 250% of BB + 300% of BB + 350% of BB + 400% of BB + 450% of BB + 500% of BB + 550% of BGreenNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneThe Contractor agrees that in each month of the Contract, 12% of the monthly project charges (MPC), not including the reimbursement costs for affidavits, will be at risk. MPCs are the charges for the services accepted during a given month. The MPC for the Project Implementation will be at risk for failure to meet the Service Levels set forth in the Contract. The Contractor will not be required to provide Performance Credits for multiple Performance Specifications for the same event; the highest Performance Credit available to the State for that particular event will apply. On a quarterly basis, there will be a “true-up” at which time the total amount of the Performance Credits will be calculated (the “Net Amount”), and such Net Amount will be set off against any fees owed by the State to the Contractor. Moreover, in the event of consecutive failures to meet the Service Levels, the Contractor will be required to credit the State the maximum Performance Credit under the terms of the Contract. The Contractor will not be liable for any failed Service Level caused by circumstances beyond its control, and that could not be avoided or mitigated through the exercise of prudence and ordinary care, provided that the Contractor immediately notifies the State in writing and takes all steps necessary to minimize the effect of such circumstances and resumes its performance of the Services in accordance with the SLAs as soon as possible.For example, if an Individual SL GYR State is Yellow in the first Measurement Period, Red in the second Measurement Period and back to Yellow in the third Measurement Period for an SLA then the Performance Credit due to the State will be the sum of Yellow Month 1 (B) for the first Measurement Period, Red Month 2 (A + 50% of A) for the second Measurement period, and Yellow Month 3 (B + 100% of B) for the third Measurement period, provided (1) such Performance Credit does not exceed 12% of the MPC (the At-Risk Amount); and, (2) no single Service Level Credit will exceed 20% of the total At-Risk Amount, as stated below:SLA Calculation EXAMPLEMonthly Project Charge (MPC) = $290,000.00Monthly At Risk Amount = 12% of MPC = $34,800Maximum for any one SLA = 20% of At Risk Amount = $6,960GYR State1st Month2nd Month3rd MonthRed0$0$7,438.500Yellow1$2,479.5011$4,959.00Green6$66Totals7$2,479.507$7,438.507$4,959.00Adjusted Totals by At Risk Amount and 20% per individual SLA Limitations (Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes (Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes (Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - Yes(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - No(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - Yes$2,479.50 $6,960.00 $4,959.00 Total Quarterly Credit: $ 2,479.50 + $ 6,960.00 + $ 4,959.00Total Quarterly Credit: $ 14,398.50Service Level Performance Credit payable to the State = (B) + (A + 50% A) + (B + 100% B), based on an illustrative MPC of $290,000.The total of any weighting factors may not exceed 100% of the total At-Risk Amount. To further clarify, the Performance Credits available to the State will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance. Service Levels will commence with Project initiation for any Implementation Project. Monthly Service Level ReportOn a monthly basis, the Contractor will provide a written report (the “Monthly Service Level Report”) to the State which includes the following information: (i)the Contractor’s quantitative performance for each Service Level; (ii) each Individual SL GYR State and the Overall SL Score; (iii) the amount of any monthly Performance Credit for each Service Level (iv) the year-to-date total Performance Credit balance for each Service Level and all the Service Levels; (v) a “Root-Cause Analysis” and corrective action plan with respect to any Service Levels where the Individual SL GYR State was not “Green” during the preceding month; and (vi) trend or statistical analysis with respect to each Service Level as requested by the State. The Monthly Service Level Report will be due no later than the tenth (10th) accounting day of the following month. Failure to report any SLA, SLA performance in a given month, or for any non-Green (i.e., performing to Standard) SLA a detailed root cause analysis that substantiates cause will result in the State considering the performance of the Contractor for that period as performing in a Red State.Failure to Report or Report Late after Mutually Agreed DatesShould for any reason the Contractor fail to report or produce the Monthly Service Level Report to the State on a mutually agreeable date, in part or in total, the Contractor performance for the Service Levels, in part or in total, must be considered Red for that period. Should, under agreement of the State a Service Level not apply in a given period, the report must reflect this agreement and indicate “not applicable this period”.Applications and EnvironmentsThe State acknowledges that its environment requirements fall into two major categories: 1) critical applications – those that are required to perform day-to-day state functions in production; and 2) non-critical application environments – which are defined as items that do not have a significant impact on day-to day operations, are used in a non-production capacity, which may not adversely impact the productivity of State development efforts or are otherwise used to support non-commercial activities. The Contractor must deliver Service Levels in keeping with the criticality levels as described herein.Temporary Escalation of an SLO to an SLAIn general, SLOs are considered measurable objectives by the State and the SLA framework accommodates their treatment and importance to the State via Contract termination considerations as opposed to financial credits as contained herein. However, in the event that Contractor performance is not meeting the established standards and requirements for SLO related items, the State may determine that an SLO needs to be escalated to an SLA. The following conditions must prevail in this escalation:Contractor performance falls below yellow standard in an SLO area for three consecutive months; orContractor performance falls below 75% of red standard in any given month; or Contractor performance is consistently in a yellow or red status for four of any six consecutive months.Should one or more of these conditions exist, the State may:Temporarily replace any SLA of its choosing with the SLO until such time as the below standard SLO is determined to be consistently (i.e., more than 3 months in a row) performing to standard;Add the SLO to the SLA group and rebalance the weighting accordingly such that the monthly fees at risk percentage agreed to is maintained (i.e., fees at risk remain constant, the number of SLAs that are considered against those fees changes) until such time as the below standard SLO is determined to be consistently (i.e., more than 3 months in a row) performing to standard.At the conclusion of period of three consecutive months where the escalated SLO is deemed to be performing in a green status, the State and Contractor must revert the escalated SLO (now an SLA) back to its SLO state.State Provided Service Support Infrastructure ElementsThe following items will not be considered Contractor Fault with respect to Service level failures and therefore not apply to any Contractor Performance Credits or Overall Contract Performance considerations discussed later in this section:Failures outside of the scope of the Contractor responsibilities pursuant to the Services responsibility scope;Failures due to non-performance of State retained responsibilities pursuant to the services responsibility scope;Failure of an out-of-scope State provided element that directly impacts an in-scope Contractor element;Failures arising from State provided equipment or networks; A pre-existing or undocumented deficiency in a State provided computing element as they pertain to adhering to State Policies and Standards. In this case, upon identification the Contractor is to promptly notify the State of the identified deficiency; Failure of a State provided resource to follow and comply with Contractor provided processes and procedures except where: (i) State Policies and Contractor policies are in conflict in which case the State resource must notify the Contractor of the conflict and resolve which process applies or; (ii) in cases of emergency that would place the State resource at physical peril or harm; Failure of a State provided third party warranty or maintenance agreement to deliver services to the Contractor for in-scope services and infrastructure elements that result in the Contractor’s inability to perform at required levels; The period of time associated with an incident where a State provided or contracted 3rd party service, repair or replacement service renders an in-scope infrastructure element unusable by the Contractor to provide the Contracted Services must be reduced from the overall duration timing of an incident; The incident requires assistance for a State retained responsibility, is delayed at the State’s request, or requires availability of an End User that is not available;Mutually agreed upon service interruptions such as scheduled changes to the technical environment; State implemented changes to Production Environments that the Contractor is not aware or apprised of.Service LevelSLA or SLOCoverage1Incident Resolution – Mean Time to Repair (Severity 1 Outages)SLA7x242Incident Resolution – Mean Time to Repair (Severity 2 Outages)SLA7x243Incident Resolution – Mean Time to Repair (Severity 3 Outages)SLOBusiness Hours4Service Availability – Application and Data Warehouse AvailabilitySLA7x245Application Performance & Responsiveness SLA7x246Incident Resolution - Issue Triage, Closure and Recidivist RateSLOBusiness Hours7Monitoring & Auditing – Application Security Breach Detection, Notification and ResolutionSLA7x248Document Processing PerformanceSLAContinuous9Call Center PerformanceSLABusiness Hours10Correspondence PerformanceSLOBusiness Hours11Reporting PerformanceSLOBusiness Hours12Operational Process Control & Repeatability – Changes to Production environmentsSLOScheduled Maintenance13Service Quality – System ChangesSLAScheduled Maintenance14Service Timeliness – System ChangesSLAScheduled MaintenanceIncident Resolution – Mean Time to Repair (Severity 1 Outages)Business Intent:Prompt resolution of outages that impact State processing and processesDefinition:Mean Time to Repair (Severity 1 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 1 Outage Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Level 2 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution. “Severity 1 Outage” is defined as:An Incident must be categorized as a “Severity 1 Outage” if the Incident is characterized by the following attributes: the Incident (a) renders a business critical System, Service, Software, Equipment or network component un-Available, substantially un-Available or seriously impacts normal business operations, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function. This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.The Contractor must report updates and progress to the State every thirty (30) minutes for this SLA until resolved.Formula:Mean Time to Repair (Severity 1 Outages)=Total elapsed time it takes to repair Severity 1 Outage Service RequestsTotal Severity 1 Outage Service RequestsMeasurement Period:Reporting MonthData Source:Activity Summary ReportFrequency of Collection:Per incidentService Level Measures:Individual SL GYR StateMean Time to Repair (Severity 1 Outages).Green<= 4 hoursYellow> 4 hours and <= 6 hoursRed> 6 hoursIncident Resolution – Mean Time to Repair (Severity 2 Outages)Business Intent:Prompt resolution of outages that impact State processing and processes.Definition:Mean Time to Repair (Severity 2 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 2 Outage Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from the time a Service Request is received at the Level 2 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution. “Severity 2 Outage” is defined as : An Incident will be categorized as a “Severity 2 Outage” if the Incident is characterized by the following attributes: the Incident (a) does not render a business critical System, Service, Software, Equipment or network component un-Available or substantially un-Available, but a function or functions are not Available, substantially Available or functioning as they should, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.In the event of “go live” of new functionality, an Upgrade, or significant change in the architecture of the Application environment, this Service Level will be suspended temporarily from the time the “go live” of the applicable Change through two (2) business days following completion of stabilization criteria in accordance with the transition to production plan.The Contractor must report updates and progress to the State every sixty (60) minutes for this SLA until resolved.Formula:Mean Time to Repair (Severity 2 Outages)=Total elapsed time it takes to repair Severity 2 Outage Service RequestsTotal Severity 2 Outage Service RequestsMeasurement Period:Reporting MonthData Source:Activity Summary ReportFrequency of Collection:Per incidentService Level Measures:Individual SL GYR StateMean Time to Repair (Severity 2 Outages).Green<= 8 hoursYellow> 8 hours and <= 12 hoursRed> 12 hoursIncident Resolution – Mean Time to Repair (Severity 3 Outages)Business Intent:Prompt resolution of issues and irregularities that impact State processing and processesDefinition:Mean Time to Repair (Severity 3 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 3 Outage Service Requests in the Contract Month. “Time to Repair” is measured from time a Service Request for in-scope Services is received at the Level 2/3 Contractor Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution. An Incident must be categorized as a “Severity 3 Outage” if the Incident is characterized by the following attributes: the Incident causes a group or individual to experience an Incident with accessing or using a System, Service, Software, Equipment or network component or, A key feature thereof and a reasonable workaround is not available, but does not prohibit the execution of productive work.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the stabilization and transition to production plan. The Contractor must report updates and progress to the State every twenty-four (24) hours for this SLA until resolved.Formula:Mean Time to Repair (Severity 3 Outages)=(Total elapsed time it takes to repair Severity 3 Outage Service Requests)Total Severity 3 Outage Service RequestsMeasurement Period:Reporting MonthData Source:Activity Summary ReportFrequency of Collection:Per incidentService Level Measures:Individual SL GYR StateMean Time to Repair (Severity 3 Outages).Green<= 5 business daysYellow> 5 business days <=7 business daysRed> 7 business daysService Availability – Application and Data Warehouse AvailabilityBusiness Intent: Is Available to All State Users for All Business Functions to Support State Processes.Definition:Application and Data Warehouse Availability for each in-scope Platform, Environment, Module and Business Process.Application Availability means access to the production system is enabled; log-in permitted from the local user LAN and business transactions can be executed. While it is dependent on State provided infrastructure and Third Party software availability the expectation is that the Contractor must implement operational processes, instrumentation, monitoring and controls that validate availability of to the end-user and development community in the State.This SLA will be calculated for those Service Elements that are directly in the Contractor’s scope and will be measured from the end-user community desktop to the ability to process transactions to the database. If, in determination of the root cause of an “unavailable” condition, the State LAN, WAN and Data Center outages, or the outage of State provided Infrastructure is the cause of the condition, the Contractor must be excused from those outages that arise from such a condition, unless the outage is a direct result of a Contractor created situation.Formula:Application Availability=Total Application Scheduled Uptime – Total Application Unscheduled OutagesTotal Application Scheduled UptimeMeasurement Period:Reporting MonthData Source:Activity Summary ReportFrequency of Collection:Continuous, 24 hours a dayService Level Measures:Individual SL GYR StateCritical/Production EnvironmentNon Critical EnvironmentsGreen>= 99.9%>= 99.0Yellow>= 99.7% and < 99.9%>=95.0 and < 99.0Red<99.7%<95.0%Application Performance and ResponsivenessBusiness Intent:Online and Batch Processes perform within expected norms, the end user experience is high performance and responsive and scheduled jobs, processes and reports execute within the established job schedule without intruding upon online application users or other business functionsDefinition:System Performance and Responsiveness will be based upon an end-to-end service class performance baseline (e.g., network time, application/session response time, system time, and network return time) performed by the Contractor during the transition or as mutually agreed will perform for key service elements for a statistically valid sample of 5 EPM/ scheduled reports.Online response time for this application. Online response time is measured as the elapsed time from when a request enters the Central Paternity Registry system until the request has been satisfied and leaves the Central Paternity Registry system. This includes processing times of all components covered under this RFP, which participate, in fulfilling the request, including but not limited to Firewalls, Load Balancers, WAN/LAN Telecommunications Lines, Web Servers, and Application and Database Servers. The definition of a transaction is any system action that requires a screen to paint, refresh or system update to complete during normal operations. Mutually agreed to exception functions will be excluded from measurement. Response times are only applicable to system within the control of the Contractor or their sub-Contractor(s) as identified in this Contract.Should the Contractor wish to accept State written requirements for each of the above in lieu of benchmarking, or use the aforementioned benchmarking, this sample will serve as the “Performance Baseline” for this SLA.Thereafter, the Contractor must perform automated testing on a daily basis for online transaction elements or provide objective evidence from system generated statistics, and provide run-time statistics for scheduled/batch system jobs and scheduled report and compare these to the Performance Baseline.Two % deviations from the Performance Baseline will be calculated: 1) % Variation Online Transactions and 2) % Variation Batch/Scheduled Operations; The higher variation (i.e., online or batch) will be used in the below formula for both the numerator and denominatorFormula:System Performance and Responsiveness=Observed (Online or Batch Scheduled) PerformanceBaseline (Online or Batch) PerformanceMeasurement Period:Reporting MonthData Source:Activity Summary Report Frequency of Collection:Continuous, 24 hours a day and Schedule Job/Report PerformanceService Level Measures:Individual SL GYR StateSystem Performance and ResponsivenessGreen< = 100%Yellow>100% - <=110%Red> 110%Incident Resolution - Issue Triage, Closure and Recidivist RateBusiness Intent:Incidents affecting, online batch or otherwise, are promptly addressed, prioritized and resolved to the satisfaction of the State and to no reoccur or cause corollary or spurious issues to occur as a result of the repair to the element that was the root cause of the Incident.Definition:Incident Triage, Closure and Recidivist Rate will be determined by monitoring compliance with the following four key performance indicators (KPI):Incident Triage: Contractor to indicate high-level diagnosis and estimate to remedy to the State within 30 minutes of acknowledgement.Incident Closure: Incident to be documented with root cause remedy, (where root cause is within Contractor’s control), and procedures to eliminate repeat of incident within 24 hours of incident close.Incident Recidivist Rate: Closed incidents not to reappear across all in scope Services no more than 1 times following incident closure.Incident means any Severity 1 or 2 incident where the Services for which Contractor is responsible are unavailable.Formula:Issue Triage, Closure and Recidivist Rate=Total Severity 1 and 2 Incidents for which Contractor is responsible under the SOW, where solution Services are unavailable) - (Number of Incidents where the KPI was not in compliance(Total Severity 1 Incidents where Services for which Contractor is responsible under the SOW are unavailable)Measurement Period:Calendar QuarterData Source:Activity Summary ReportFrequency of Collection:Calendar Quarter, All Severity 1 and 2 IncidentsService Level Measures:Individual SL GYR StateIncident Resolution - Incident Triage and Closure and Recidivist RateGreen>= 99.5Yellow< 99.5 and > =99.3Red< 99.3Security – Monitoring & Auditing – Security Breach DetectionBusiness Intent:Ensure that State Security policies are implemented correctly, and monitored and followed at all times for all users of whether end-user, State, Contractor or 3rd PartyDefinition:System Security Breach Detection will be determined by monitoring compliance with the following three key performance indicators (KPI):System security breach success notification due within 30 minutes of physical intrusion detection of any element within the Contractor’s responsibility area or Contractor provided facility or element that accesses including Contractor’s machines. Notification will be as set forth in the State/Contractor Process Interface Manual or other supporting documents.Suspension or Revocation of unapproved or intruder access in accordance with State established procedures within 10 minutes of State approval or (absent State approval) 15 minutes.System security breach (attempt, failure) notification due within 1 hour of such physical intrusion detection. Notification will be as set forth in the Process Interface Manual or other supporting documents.Formula:Security Breach Detection=(Number of instances where individual KPI’s were not in compliance)Measurement Period:MonthData Sources:Infrastructure Antivirus/Malware/Rootkit Scan logs, Active Port Scanning Logs, User Account Review ReportFrequency of Collection:MonthlyService Level Measures:Individual SL GYR StateSecurity Breach DetectionGreen<= 0YellowN/ARed> 0Document Processing PerformanceBusiness Intent:Process all documents received in two (2) business days with 100% data accuracy and then transmit these files to ODJFS and ODH twice per week for additional processing and verification. Definition:Contractor will receive and enter all paternity records within two (2) business days of receipt. They will then create a unique record for each paternity document containing all of the data elements listed herein. Any errors in paternity documents must be corrected within three (3) business days of receipt. All electronic files will be securely transmitted to ODJFS & ODH twice weekly by 10am as outlines in Section 3.2 above. All hard copies will be forwarded to ODH twice weekly.Formula:Document Processing Performance=(Total Number of incorrectly processed records) + (Total Number file transmission deadlines missed)Total Number of Documents ProcessedMeasurement Period:MonthlyData Sources:Timeliness and Accuracy ReportFrequency of Collection:DailyService Level Measures:Individual SL GYR StateDocument Processing PerformanceGreen= 100%Yellow> 1% <= 5%Red> 5%Call Center PerformanceBusiness Intent:Answer calls during business hours to provide both technical and end user support. Maintain phone, fax and email for the program. Definition:The Contractor must staff a Customer Service Help Desk throughout the day with the number of operators appropriate to meet the performance specifications defined below: Maintain the average call response time at or below 60 seconds;Respond to all email inquiries within one (1) business day;Respond to all voicemail inquiries within one (1) business day;Maintain, at a minimum, a monthly average call answer rate of 97%; andMaintain a busy rate at or below 1% of calls.Formula:Call Center Performance=(Total Number calls answered above 60 seconds) + (Total Number of emails responded to after one (1) business day) + (Any monthly average call answer rate above 97%) + (Days with a busy rate above 1%)(Total Number of calls) + (Total Number of emails) + (Monthly average call answer rate)+ (Number of days in the month)Measurement Period:MonthlyData Sources:Call Center Activity ReportFrequency of Collection:DailyService Level Measures:Individual SL GYR StateCall Center PerformanceGreen= 100%Yellow> 1% <= 5%Red> 5%Correspondence PerformanceBusiness Intent:Track and respond to user questions sent by mail to the CPR program. Definition:Contractor must process and provide appropriate follow-up to all letters of inquiry or other correspondence sent to the CPR program from local registrars, hospitals, parents, or the general public. The Contractor must date stamp these items, and respond to matters under its purview within two (2) business days. The Contractor shall maintain a log of the dates that correspondence was received and responded to for inspection by ODJFS. Any correspondence requiring an OCS response must be forwarded to OCS within two (2) business days of receipt.Formula:Correspondence Performance=(Total amount of correspondence older than two (2) business days without reply)(Total amount of correspondence)Measurement Period:MonthlyData Sources:Call Center Activity ReportFrequency of Collection:DailyService Level Measures:Individual SL GYR StateCorrespondence PerformanceGreen= 100%Yellow> 1% <= 5%Red> 5%Reporting PerformanceBusiness Intent:Receive reports related to the performance of the CPR program in a timely fashion. Definition:Receive an Activity Summary Report within five (5) business days of the end of the reporting month that includes the following: the Statewide Paternity Establishment Percentage Performance; the data transmission record between ODJFS and ODH; the relationship management report; the call center activity report; and the timeliness and accuracy report. Additionally, the Contractor is required to provide to ODJFS a monthly reconciliation to ensure the timely delivery of affidavits and other paternity documents to CPR from all program partners by the 15th of the following month. The reconciliation will compare state paternity establishment data maintained within the Support Enforcement Tracking System (SETS) with documentation received at CPR from program partners. Formula:Reporting Performance=(Days past the 5th business day of the month for Activity Summary Report) + (Days past the 15th of the month for the reconciliation report)(Days in the month)Measurement Period:MonthlyData Sources:ODJFS StaffFrequency of Collection:DailyService Level Measures:Individual SL GYR StateReporting PerformanceGreen= 100%Yellow> 1% <= 5%Red> 5%Operational Process Control & Repeatability – Changes to Production EnvironmentsBusiness Intent:All changes to production environments follow a disciplined process, are authorized by the State and documentation is updated at all times to ensure that the operating environment of is up to date and documentation is current. Production changes are tested/validated and move as a comprehensive change package as opposed to piecemeal elements that result in unintended consequences. Definition:The changes to production environment measure is determined by monitoring compliance with the following six key performance indicators: All changes to production environments have an authorization from an approved the State employee. Code or System changes are promoted to production environments that use contemporary change control methods including version control, data backup/back out procedures (if applicable).All elements that comprise a system change inclusive of code, configuration values, environment parameters, database elements, security, executables and other required change elements are applied as part of a Production change. No untested or unapproved changes or changed elements that are not required by a production change are introduced into the production environmentChanges that are detected to introduce errors or unavailability to production systems are reversed in accordance with the Contractor back-out procedure and the system is restored to the pre-change state without impacting regular operations.Corresponding updates to the supporting documents are completed within a reasonable timeframe of receiving and implementing minor approved change request(s).Formula:Changes to Production Environments=Total Number of KPIs not metTotal Number of KPIs metMeasurement Period:MonthlyData Sources:Activity Summary ReportFrequency of Collection:Each Change to ProductionService Level Measures:Individual SL GYR StateChanges to Production EnvironmentsGreen<= 1%Yellow> 1% <= 3%Red> 3%Service Quality – System ChangesBusiness Intent:System Changes are implemented correctly the first time, and do not cause unintended consequences to users, scheduled jobs and reports, corrupt or compromise data or data relationships and otherwise perform as intended from a functional, technical and performance perspective. Non-Production environments reflect Production.Definition:The Service Quality System Changes measure is determined by monitoring compliance with the following four key performance indicators (KPI): System changes or updates (i.e., break fix, configuration, and patches) in any release to production environment are implemented correctly the first time inclusive of all code, non-code, configuration, interface, scheduled job or report, database element or other change to the production environmentSystem changes or updates are propagated within 5 business days as mutually deemed appropriate to non-production environments such that environment configurations are synchronized and reflect the then current environment and a common development, testing, QA, demonstration and training environment is carried forward that is reflective of production.Production system changes (i.e., break fix, configuration, and patches) in releases that do not cause other problems.System changes or updates (i.e., break fix, configuration, and patches) in emergency releases are implemented correctly the first time that comprise the system.Formula:Service Quality – System Changes=Total Number of KPIs not metTotal Number of KPIs metMeasurement Period:MonthlyData Sources:Production Change ReportFrequency of Collection:Each Change to Production and Follow-On Changes to Non-ProductionService Level Measures:Individual SL GYR StateService Quality – System ChangesGreen<= 2%Yellow> 2% <= 5%Red> 5%Service Timeliness – System ChangesBusiness Intent:System Changes are implemented in a timely manner as scheduled with the State or (if applicable) during a Scheduled Maintenance Period or as required by the StateDefinition:The Service Timeliness System Changes measure is determined by monitoring compliance with the following two key performance indicators (KPI): Emergency system changes or updates (i.e., break fix, configuration, and patches) will be initiated within 24 hours of the State approved request and Change Management Process and to be reported complete within 1 hour of completion. Non-emergency system changes or updates (i.e., break fix, configuration, and patches) to be initiated in accordance with the State policies during a scheduled maintenance period or as mutually scheduled between the Contractor and State and reported within 2 days of post implementation certification.Formula:Service Quality – System Change Timeliness=Total Number of KPIs not in Compliance in a MonthTotal Number of System Changes in a MonthMeasurement Period:MonthlyData Sources:Production Change ReportFrequency of Collection:Each Change to Production and Follow-On Changes to Non-ProductionService Level Measures:Individual SL GYR StateService Quality – System ChangesGreen<= 2%Yellow> 2% <= 5%Red> 5%8.4 Central Paternity Registry- OnBase Interface Outages The bulk of the critical functions of the Central Paternity Registry are supported by data flows back and forth between CPR and On Base. Due to this critical dependence, special monitoring is needed to ensure that the interface is operational and timely. Before go-live, the Contractor must provide an interface assurance plan that outlines the monitoring and reporting mechanisms that they will put into place to ensure that the interfaces are operational. Failure to detect that the interface is down will count as a critical failure even if the root cause is shared or originates on the State side. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download