pelican keys to quality – gsd session 11 august 26th, 2008

PELICAN Keys to Quality – GSD

Session 11

August 26th, 2008

Provider: Grant Agreement

2


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

Provider: Grant Summary

4

Provider: Grant Category Details

5

Provider: Grant Category History

6


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

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 # Title Category Description

3. Manage Security Global The PELICAN Keys to Quality system will be compliant with Federal, State and HIPAA security guidelines.

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

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 # Title Category Description

1. System Archive of Data

Global Data 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

Global Data 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. Architecture Global The archive and purge periods need to be flexible and easily configurable to factor changing legal and operational needs.

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

Archive/Purge: Location

12


Description

1. LocationA 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

Archive/Purge: Legal Entity/Location

13


Description

1. Legal Entity/LocationA 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


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/LocationOnce 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

# Subsystem/ Logical

UnitDescription


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/LocationTo 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/LocationThe stub record maintained in the online system should be purged from the online system when the archived case record is purged.


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


Description


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/LocationA provider under investigation (audit, litigation, OIG referral, etc.) should remain in the system in which the case is investigated.

11. Legal Entity/LocationA provider under investigation (audit, litigation, OIG referral, etc.) should be purged after a minimum of 7 years from the resolution date.

Archive/Purge: Alerts

16


Description

1. AlertsAlert records should be purged a minimum of 90 days after they have been cleared (system or user).

2.

AlertsAlert records that have not been cleared should remain in the operational database until the corresponding provider record has been archived or purged.

3. AlertsWhen a provider record is archived/purged, all associated alerts should be archived/purged at that time.

4. Broadcast MessagesBroadcast message records should be purged a minimum of 90 days after their expiration date.

Archive/Purge: Reports

17


UnitDescription

1. ReportsReports requested information should not remain in the online system after a reporting record is purged.

2.Reports Report 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.

Archive/Purge: Enrollment/Grant Agreement Packet

18


UnitDescription

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.

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

Conversion: Approach

20

Phase Description

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

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

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

Questions & recommendations?

pelican keys to quality – gsd session 11 august 26th, 2008

Documents

grant agreement button

grant agreement page

grant agreement template

grant related information

grant agreement packet

merit grant types

multiple grant types

grant summary page