1. PELICAN Keys to Quality – GSD Session 11 August 26th, 2008

2. Provider: Grant Agreement 2

3. Business Rules 1.If the Grant Closed button is yes on the Grant Summary, disable the Grant Agreement button. 2.The user will be prevented from selecting multiple Grant Types to generate the Grant Agreement packet with the exception of ERA and Merit Grant types. 3.The Grant Agreement template generated will be dependent on the fiscal year selected. 4.At least one Grant Agreement must be selected from the “Grant Agreement Packet” field in order to generate a Grant Agreement. 3

4. Provider: Grant Summary 4

5. Provider: Grant Category Details 5

6. Provider: Grant Category History 6

7. Provider: Grant Agreement 1.Can a grant agreement be signed at the Legal Entity level for a location? - Yes, a grant agreement can be signed by a Legal Entity. 2.Would you like to track any other information regarding the agreement? - No 3.Is there a need to display all the grant related information such as grant type information on the Grant Agreement page? - No, this information is already captured on the Grant Summary page. 4.Do we need to capture the regional key agency’s point of contact information? - The Regional Key Demographic information will be maintained in a reference table. 7

8. User Security Business Rules 1.Only users with Read/Write access can create and update records within the system. 2.Users with Read Only access will be allowed to view records in the system. 3.Only users with Super User access can delete records in the system. Related Non-Functional Requirements 8 Req #TitleCategoryDescription 3.Manage SecurityGlobalThe PELICAN Keys to Quality system will be compliant with Federal, State and HIPAA security guidelines.

9. Questions: Security 1.What are the different User Types that are needed by OCDEL, PA Keys and the Regional Keys? The current “User Types” are HQ, PA Keys and Comptroller, Regional Keys. 2.What are the different User Roles needed by OCDEL in the system? The current “User Roles” are Super User, Supervisor, Fiscal Specialist, STARS Specialist, Director. 3.Aside from the Super User, which other users should have the ability to delete records? 4.Should Regional Key Directors be allowed to view Fiscal Allocation information? 9

10. Archive/Purge Business Rules 1.Only records created in the Keys to Quality system can be archived/purged. 2.When a provider location maintains a STAR Level of “No STAR” in the system consistently for 3 years, then Archive the provider record. 3.Fiscal Allocation information will never be archived or purged from the system. Related Non – Functional Requirements 10 Req # TitleCategoryDescription 1. System Archive of Data GlobalData elements must be archived after an elapsed time period based on the business requirement. These requirements will be further defined in the GSD sessions 2. System Purge of Data GlobalData elements must be purged after an elapsed time period based on the business requirement. These requirements will be further defined in the GSD sessions 5. ArchitectureGlobalThe archive and purge periods need to be flexible and easily configurable to factor changing legal and operational needs.

11. Archive/Purge: Legal Entity 11 # Subsystem/ Logical Unit Description 1. Legal Entity An open legal entity (current and history records) should remain available for online access as long as legal entity remains open. 2. Legal Entity A closed provider legal entity (current and history records) should remain available for online access for a minimum of 3 years after legal entity close date. *NOTE: provider legal entity can only be closed only after all associated locations have been closed. 3. Legal Entity After remaining inactive (closed) for 3 years, the entire provider legal entity record and all associated location records should be archived. This should include current, end-dated and history components of that record. This includes: - legal entity demographics - legal entity Contacts - local Contact Log - Email - all related provider locations

12. Archive/Purge: Location 12 # Subsystem/ Logical Unit Description 1. Location A closed provider location (current and history records) should remain available for online access for a minimum of 3 years after the location close date. 2. Location After associated location remains inactive (closed) for a minimum of 3 years, the provider location record should be archived. This should include current, end-dated and history components of that record. This includes: - location demographics - Certificate ID history - Location Contacts - Location Contact Log - Email - STARS Management - Designation Information - Classroom Information - ERS Score - Grant Management

13. Archive/Purge: Legal Entity/Location 13 # Subsystem/ Logical Unit Description 1. Legal Entity/Location A provider cannot be archived from the operational system if there are associated or open/outstanding provider grants still available in the online system. 2. Legal Entity/Location Basic provider information should be maintained online in the form of a stub-record after the provider record is archived. This stub information should include: - MPI# (legal entity) - MPI# (Location) - Name - Address 3. Legal Entity/Location The provider stub record will have a flag to indicate that the provider record has been archived. Clearance and Demographics searches will use this flag to indicate that this particular provider record has been archived. However, providers with such stub records should be excluded from operational reports. 4. Legal Entity/Location Once a provider record is archived, it should be moved out of the online system. An archived record should not be revived to active status. The user should create a new provider record.

14. Archive/Purge: Legal Entity/Location 14 # Subsystem/ Logical Unit Description 5. Legal Entity/Location Users of the online system should be able to access the archived provider records in the form of a report, if needed. A window of 2 business days is reasonable for generation of this report. 6. Legal Entity/Location To support any urgent needs around archived records, facility to run on-demand database queries should be available, similar to the online system. 7. Legal Entity/Location The stub record maintained in the online system should be purged from the online system when the archived case record is purged. 8. Legal Entity/Location The provider records (legal entity and location) should be purged from archive medium within a reasonable period after moving to the archive medium. This period is a minimum of 7 years from the provider legal entity close date.

15. Archive/Purge: Legal Entity/Location 15 # Subsystem/ Logical Unit Description 9. Legal Entity/Location A provision should be available in the archive medium to flag a provider record for extra retention. This provision should be created to account for any special needs relevant to legal situations such as audit, litigation, OIG referral, etc. 10. Legal Entity/Location A provider under investigation (audit, litigation, OIG referral, etc.) should remain in the system in which the case is investigated. 11. Legal Entity/Location A provider under investigation (audit, litigation, OIG referral, etc.) should be purged after a minimum of 7 years from the resolution date.

16. Archive/Purge: Alerts 16 # Subsystem/ Logical Unit Description 1.Alerts Alert records should be purged a minimum of 90 days after they have been cleared (system or user). 2. Alerts Alert records that have not been cleared should remain in the operational database until the corresponding provider record has been archived or purged. 3. Alerts When a provider record is archived/purged, all associated alerts should be archived/purged at that time. 4. Broadcast Messages Broadcast message records should be purged a minimum of 90 days after their expiration date.

17. Archive/Purge: Reports 17 # Subsystem/ Logical Unit Description 1. Reports Reports requested information should not remain in the online system after a reporting record is purged. 2. ReportsReport requested information (database records) as well as all the report output should remain in the system for a minimum of 30 days after the initial report request. 3. Reports Report database records and PDFs should not be archived. As such, there is no requirement for retrieval from an archive system.

18. Archive/Purge: Enrollment/Grant Agreement Packet 18 # Subsystem/ Logical Unit Description 1. Enrollment/Grant Agreement Packet Enrollment packet reference information should remain available for online access as long as the enrollment packet is in an archived state. The minimum stub information required is the Correspondence ID, MPI ID. 2. Enrollment/Grant Agreement Packet Until purged, all enrollment packet records and PDFs that have been placed in an archive location must be made available within 2 business days upon the request. 3. Enrollment/Grant Agreement Packet All enrollment packet records should be archived after a minimum of 3 years from the requested date. These records include both records stored in the database, as well as the physical PDFs stored on the file system. 4. Enrollment/Grant Agreement Packet All enrollment packet records should be purged when the provider is purged. These records include both records stored in the database, as well as the physical PDFs stored on the file system.

19. Conversion: Assumptions 1.No manual conversion process will be needed, each part of conversion will be accomplished using automated scripts. 2.For this conversion effort, the source system will be database table structure of the existing KIDS production system. 3.Address information will be taken from MPI for all the existing, certified and regulated KIDS providers and not from the current KIDS system. 4.All blank required fields will be populated after the first time the user access the record. 5.Inactive providers record will not be converted from the Current KIDS system into Keys to Quality. 19

20. Conversion: Approach 20 PhaseDescription DSD Specific procedural logic to be performed by the conversion scripts will be designed and validated. Development Scripts for performing the conversion will be coded and unit tested. Integration Errors for script logic and configuration will be fixed as part of this phase. SAT Test/Mock Conversions TFP Test/Mock Conversions Production Final conversion of live Production data and files Post process cleanup

21. Conversion: Questions 1.Which of the following entities should be converted from the current KIDS to the new PELICAN Keys to Quality system: 1.Legal Entity Address Contact Contact Log 2.Location Address Contact Contact Log 3.STARS Application 4.Designation Information Designation History 5.ERS Score 6.Grant Grant Category Details Grant History 7.Fiscal Allocation details Fiscal Allocation History 8.Correspondence (email text) 21

22. Conversion: Questions Continued… 2.Do we need to convert historical data i.e., “Facility History Log” which lists the certification changes within the specified time period, etc? - Yes, the historical data for Designation, Grant and Fiscal Allocation will be converted to Keys to Quality 2.What should be the process for entering data in the new required fields which are not present in the current KIDS system? For example profit/ non-profit, business type, program type, language etc. -The blank required fields must be populated by the user the first time the record is accessed after conversion. 22

23. Questions & recommendations?