Get documents about "Application Implementation Strategy
W
Description
Application Implementation Strategy document sample
Document Sample
eXPRS Implementation Strategy
Template Examples Disclaimer
Unless otherwise specifically stated, the information contained herein is
made available to the public by the Department of Human Services, Office
of Information Services, Project Management Office for use as an example
of template content information and may not reflect the realities of an actual
project. The intent of the template example is to assist an individual
creating a new document using the PMO standard template.
Neither the DHS, OIS, PMO nor any other agency or entities thereof,
assumes any legal liability or responsibility for the accuracy, completeness,
or usefulness of any information, product or process disclosed in these
examples.
Reference herein to any specific commercial product, process, service by
trade name, trademark, manufacturer, or otherwise, does not constitute or
imply its endorsement, recommendation, or favoring by the PMO or any
entities thereof.
The views and opinions of the originators expressed therein do not
necessarily state or reflect those of the DHS, OIS, PMO or any agency or
entities thereof.
Page 1 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
Oregon Department of Human Services
Office of Information Services
Express Payment & Reporting System (eXPRS)
Implementation Strategy
Approval Date: 09/18/2002
Initiation Planning
Controlling Executing
Verify Requirements
Conceptual Design
Closing Functional Design
System Construction
Implementation
Purpose of the Document
The purpose of the Implementation Strategy is to define and recommend the potential
implementation scenarios based on the principles and considerations defined by the
Project Steering Committee (i.e., cost, duration, functionality, etc…)
The Implementation Strategy includes decisions for design alternatives and potential
releases to be used in creating a definitive implementation plan.
Page 2 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
Document Change Activity
The following is a record of the changes that have occurred on this document from the
time of its original approval
# Change Description Author Date
Page 3 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
1 Implementation Strategy ...................................................................... 5
1.1 Design Recommendations ............................................................ 5
1.2 Release Strategy .......................................................................... 6
2 Design Alternatives - Detail.................................................................. 7
2.1 Make or Buy Analysis ................................................................... 7
2.2 Interface with Client Index System (CI) ......................................... 8
2.3 Interface with Contract Status & Timing (CSTAT) ......................... 8
2.4 eXPRS Development Environment ............................................... 9
2.5 Scenario #1 – Replace Rbase first................................................ 9
2.6 Scenario #2 – Deliver system with one ‘big-bang’ release ............ 9
2.7 Scenario #3 – Deliver system using phased approach ................. 9
Page 4 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
1 IMPLEMENTATION STRATEGY
The primary constraint for implementing a payment system is that implementation must
occur at the start of a fiscal year. Implementing a new payment system requires a
period of parallel operations with the existing system as well as using a pilot to improve
product quality prior to general rollout.
Implementing a payment system also requires corresponding changes in the contracts
that the payments are based on as well as coordination with changes in accounting and
budget code structures. Therefore, the project recommends adopting the following
implementation schedule:
eXPRS Payment & Reporting System
Implementation Schedule
Jun 2002 Sep 2002 Jan 2003 Jun 2003 Jan 2004 Apr 2004 Jul 2004
Plan Approved R1 Defined R1 Designed R1 in Production R2 Pilot R2 Parallel R2 Switchover
May 2002 Jul 2004
1.1 Design Recommendations
Each design recommendation is detailed in the remaining sections of this report.
Build eXPRS using internal development staff to reduce overall cost and duration of
satisfying the business need.
Build eXPRS using a phased approach to build the system in multiple releases to
make business improvements faster and timelier.
Build eXPRS outside of Curam to meet schedule constraints while collaborating with
MMIS and Transformation Project to centralize functionality that should be
performed at an enterprise level.
Build external interface with Client Index System (CI) to centrally manage client
information.
Build external interface with Contract Status Tracking & Timing (CSTAT) to share
contract information.
Build eXPRS using Cold Fusion (presentation tier), Websphere (application tier) and
DB2U (database tier)
Page 5 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
1.2 Release Strategy
Release 1 benefits include: increase payment accuracy, improve reconciliation, reduce
manual input, prove the feasibility of the technical architecture, and introduce change to
system stakeholders early in the development process.
All conversion and replacement work entails complex business logic and requires close
monitoring for risk mitigation. The project will define a transition process for both
releases in the Implementation Plan.
Release 1 functionality: Client and Provider Enrollments, Prior Authorization (subset),
System Administration (subset). Release 1 work includes:
Replace the Rbase Interface database with an external DB2 Interface to SFMA.
Note: this work must be prioritized to accommodate schedule constraints.
Replace the client and provider enrollment and termination paper forms for Client
Process Monitoring System (CPMS) with an electronic version that is entered
electronically into eXPRS and manually/batch uploaded into CPMS.
Replace the Terminations and Service Adjustment Records (TSAR) form with web-
based screens.
Convert unique client identifiers from CPMS to the CI system and ensure security
requirements for access to client information (all DD clients, all A&D clients, and only
Community Mental Health clients).
Develop web-based forms for Providers to record and verify service delivery for
exception tracking. This functionality will replace the Provider Financial Statement
(PFS) in Release 2.
Build a process to transfer Provider Enrollment data from eXPRS to CPMS with a
one-time conversion and an ongoing manual process to stay synchronized using a
crosswalk.
Build the technical infrastructure for system development and operations
Develop a role-based security model that authorizes at the individual level.
Provide training to DHS, Counties, and Providers for the new web-based interface.
Release 2 functionality: Payment Request, Payment Process, Prior Authorization
(complete), System Administration (complete). Release 2 work includes:
Replace the Provider Financial Statement (PFS) with web-based screens.
Develop all remaining Prior Authorization and System Administration functionality
Page 6 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
Develop all remaining external interfaces necessary to operate system
Develop an interface with the HIPAA translator and HIPAA compliant Claim form
(837) to ensure HIPAA compliance.
Replace the remaining Rbase databases
Build the Reporting capabilities described in the Business Requirements (i.e.,
System Reports, Federal Reports, Tax Reporting, etc…)
Provide training to DHS, Counties, and Providers for the new payment process.
2 DESIGN ALTERNATIVES - DETAIL
2.1 Make or Buy Analysis
10 accounting based systems were reviewed for reuse opportunity from the States of
Oregon, Arizona, Louisiana, and Nevada, as well as commercial products (i.e., Oregon
Dept. of Forestry, Oregon Youth Authority, Curam, and Anasazi).
Alternative Pros Cons
New Best fit to Business Requirements. Introducing new technology may
Development Greatest productivity gains in present unforeseen risk.
shortest timeframe.
Cost savings with new capabilities.
Purchase & Compliance with DHS system Timing (i.e., Mar 2003 HTML
Customize – architecture (if selected). release, Business Feasibility
CURAM complete in Oct 2002).
Requires substantial
customization (i.e., payment
processing functionality).
Financial portion has not been
implemented within the United
States (has within UK).
Payment processing would be
outside of Curam anyway.
Duration of procurement process
likely to delay schedule.
Purchase & Some Oregon Counties & Providers Requires software installation and
Customize – are using other Anasazi modules maintenance on all desktops.
Anasazi and would be able to share User screens are complicated and
information and interface easily. require extensive training.
Page 7 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
Alternative Pros Cons
All customization and
maintenance must be performed
by Anasazi.
Requires an annual maintenance
agreement and fee.
Has only been implemented on a
county level, no experience with
statewide implementation.
Duration of procurement process
likely to delay schedule.
Transfer & Meets many of the eXPRS Technology not supported in DHS
Customize – business requirements including standards (Small Talk and Oracle
OYA having provider and client Database).
enrollment and a pre-authorization System is not web-enabled.
component. Requires installation of software
on to the user’s desktop.
2.2 Interface with Client Index System (CI)
Alternative Pros Cons
Interface with Compliance with agency Requires testing in new technical
Client Index directive to provide client environment.
System (CI) information across services. Work is necessary from both CI
Reuse of functionality and data. and eXPRS staff.
No anticipated performance Security for non-DHS users not
impact on CI. in place.
2.3 Interface with Contract Status & Timing (CSTAT)
Alternative Pros Cons
Interface with Compliance with agency directive CFAA contract not currently in
Contract Status to provide centralized contract CSTAT.
and Timing management. Data at summary level not
(CSTAT) sufficient for eXPRS needs.
CSTAT resources may not be
available to implement required
changes.
Direct interface may present
performance issues (based on
different technologies).
Page 8 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
eXPRS Implementation Strategy
2.4 eXPRS Development Environment
Alternative Pros Cons
Cold Fusion only Faster development Reuse of business logic
Quick learning curve Oregon.gov is converting to
Currently used in e-Government Websphere
web portal
Websphere only Reuse of business logic Difficult to learn
Same technology as DAS Significant training requirements
payment manager
Cold Fusion Rapid screen development and Increased tool cost
(presentation tier) provides reuse of business
and Websphere logic.
(application tier)
2.5 Scenario #1 – Replace Rbase first
There are three Rbase databases in the existing system: Community Payments,
Community Contracts, and the Statewide Financial Management Application (SFMA)
Interface. The databases are in different Rbase versions, each with bugs that are no
longer being patched through vendor upgrades.
Rbase is not supported by vendors and there are few people within OIS that can
maintain the Rbase databases. Workstations running Rbase are beginning to fail as a
result of infrastructure changes made (i.e., operating system upgrades).
Replacing the Community Payments and Community Contracts databases requires that
the new payment process design is complete. Based on the schedule constraints, a
new payment process will not be implemented until July 2004.
2.6 Scenario #2 – Deliver system with one ‘big-bang’ release
This scenario will delay the delivery of benefits and improvements until the end of the
project and is not recommended.
2.7 Scenario #3 – Deliver system using phased approach
A phased approach to build a system in multiple releases makes business
improvements faster and timelier and as a result is likely to foster increased customer
satisfaction and support throughout the life of the project.
A new payment system must be implemented in whole. Facilitated work sessions were
held to identify the functionality for each release, based on the associated benefits and
schedule constraints.
Page 9 of 9 Revise Date: 12/15/2010 7:46:00 PM
D:\Docstoc\Working\pdf\59eead41-6cfc-4732-b7d5-99dfdfb3a121.doc
Related docs
