Is the CapMan System Reasonably Capable of Supporting the 1115 Waiver and Federal Health Care Reform?

flutheronioneyedΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

104 εμφανίσεις



1

Is
the
CapMan

System
Reasonably
Capable of

Supporting the 1115 Waiver
and
Federal
Health Care Reform?

Background

In 2006 the Department initiated a project, 82
0 Phase 2 (820 P2), to create an
automated system that
would deliver member
-
level capitation paym
ent information to Managed Care.
The 1115 Waiver has
the potential to increase the number of beneficiaries enrolled in Medi
-
Cal managed care to 11.2 million
b
y 2014. The larger number of beneficiaries will require more time and computing capacity than
originally contemplated. Related to a larger number of managed care beneficiaries are the likelihood
of more health plans, more reporting requirements, and mo
re complex calculations. Calculations could
get more complex if beneficiaries enrolled under the waiver have different capitated rates or there are
special rates for various medical conditions.

The
CapMan

system development was completed in December 201
0 for the original requirements that
preceded the approval of the 1115 waiver. Performance testing performed on the CapMan system
demonstrated the ability to meet the
requirement

to process 6 million beneficiaries in about one
-
third
the
required time.

CapMan

was funded by the Office of HIPAA Compliance and justified for the need to meet HIPAA
requirements to meet 2012 deadline for implementation of the detailed remittance advice stipulated in
the 5010 version of the X.12 820 transaction set.



Overall
CapMan

functionality goes far beyond just HIPAA compliance. David Bass injected a
management philosophy that the new system must significantly upgrade the quality and accuracy of the
payment calculations so that the payment data sent to health plans is ac
curate as well as HIPAA
compliant.

The scope of functionality is further addressed below.

Approach

In order to answer the question, an
assessment
covering

six

key
application
areas was made
:

1.

Application Functionality and Flexibility

2.

Processing Performance

3.

Database

Design

4.

Computing Environment

5.

Ongoing Maintenance and Support

An Assessment of the Extendibility and Capacity of the
CapMan

System


2

6.

Costs

Application
Functionality

and Flexibility

Today, the breadth of automated functionality provided by CapMan allows the Department’s Medi
-
Cal
Managed Care Division (MMCD) to perform

many tasks necessary to calculated capitated payments
including
:




Allows
business
users to m
anage

c
ontract
data

(payment rates,
etc.)

for
all Managed

Care Pl
an
s
,
in addition to
managing
beneficiary supplemental eligibility data, waiver data
, and other
reference data
.



C
alculates

Capitation

amounts for current eligibility, net eligibility adjustments for 12 prior
months, and rate adjustments for up to 36 prior months, at the at the beneficiary level
.



Generates up to
16

different

invoice type
s

for each Hea
lth Care Plan
.



Aggregates invoice amounts by Aid Code Group, Funding Source, Waiver Authority, Service
Month,

and Payment Month.



Interfaces with ITSD, Accounting, State Controller’s Office, Managed Care vendors,

and multiple
Managed Care user groups.



P
re
pares the

beneficiary detail
level 820

remittance advice fully compliant with
HIPAA
5010
820
standards.



Generates
over 20
detailed
reports
.




In addition to supporting
the
Managed Care invoicing

process
, the system
also
supports the
HIPP
/BCCTP invoicing process

and TPLRD reporting

needs
.
An Assessment of the Extendibility and Capacity of the
CapMan

System


3

Figure
1

-

CapMan System Process Model

820
Phase
2
Level One Process Model
820
Phase
2
System
Medi
-
Cal Managed Care
Division
&
HIPP
/
BCCTP
Global
Scape
SFTP
DHCS
ITSD
DHCS
Accounting
State
Controller’s
Office
Managed Care
Plans
(
Vendors
)
MMCD Program Contracts
4
.
0
Contract and Beneficiary Management
1
.
0
Capitation Calculation
2
.
0
Process Invoices
3
.
0
Process Payments
5
.
0
Process
820
TXNs
Process
Invoices
,
enter
into CMS
64
System
,
and
Send to SCO
2
.
1
Generate
Invoices
Print
,
Sign
and Send
Invoices to
DHCS
Accounting
2
.
3
HIPP
&
BCCTP
Invoice
Management
Managed
Care Contract
Agreement
Managed Care
Contract Creation
(
Contracts Unit
=
Source of Record
)
5
.
1
Generate and
Send
820
Transactions
to SFTP
Receive
CMS
64
Files
(
Claim
Schedule
Data
)
Receive
CD
102
Files
(
Warrant
Data
)
3
.
1
Receive and
Process
Payment
Data
Issue
Warrants to
Vendors
Generate
CD
102
Report of
Warrant
Information
2
.
2
Review
&
Approve
Invoices
4
.
3
Generate
Reports
MMCD
Invoice
Data
4
.
1
Beneficiary
Management
Vendor Sends
Invoices to MMCD
for Supplemental
Payments
Store
820
Transactions
Contract
&
Reference
Data
Beneficiary
Data
4
.
4
Reference
Data
Management
4
.
2
Contract
Management
MMCD Inputs
Contract and
Reference Data
into CAPMAN
MMCD Inputs
Beneficiary
Supplemental
Eligibility Data into
CAPMAN
MMCD Queries
Reports from
CAPMAN
Warrant
1
.
1
Retrieve
&
Process
MMCD
Enrollment File
1
.
2
Calculate
Capitation
Send MMCD
Enrollment
File to SFTP
site
Store
MMCD
Enrollment
File
4
.
6
HIPP
&
BCCTP
Vendor
Management
4
.
5
HIPP
&
BCCTP
Beneficiary
Management
HIPP
/
BCCTP Unit
Inputs Vendor and
Beneficiary Data
into CAPMAN
Retrieve
820
Transactions
(
Remittance
Advice
)
Reconcile
820
TXNs with
Contract
&
Enrollment and
Warrant Data
Send
Maternity
Supplemental
Eligibility File
1
.
3
Retrieve and
Process
Supplemental
Maternity File
Store
Maternity
Supplemental
Eligibility File

An Assessment of the Extendibility and Capacity of the
CapMan

System


4

Anticipated

Application Impacts

Based on a preliminary analysis of the 1115 Waiver
,

the following areas of
CapMan

will be impacted
:



I
ncreased volume of benefic
iaries due to SPD, MCE, HCCI and CCS

beneficiaries



New
waiver authority structuring

requires minor changes to capture new funding splits



New reporting requirements



Modified invoice format

The primary system functionality appears to support the necessary changes
without the

need to modify
the core cap
itation ca
lculation processes. The system’s

flexible use of model types, HCPs, Aid Codes,
Medicare eligibility,
Waivers, etc. accommodates the 1115 Waiver.

The contract management features
can be readily modified to support the aid codes required for SPDs and Dual

Eligibles, if needed.


There
are no changes required to the calculation process.
Invoices will
need to
be modified to reflect new line
items required
by the 1115 Waiver. Need to
distinguish invoice amounts for newly
mandatory

SPDs
vs.
existing SPDs
.
Se
veral a
dditional reports
and modifications to existing reports
are expected

but these do
not require any c
hanges to the database design or
base capitation
calculation approach.

CapMan

can be enhanced to support additional functionality for contract management if needed. Any
co
ntract management enhancements sh
ould have
minimal

impact on the rest of the system. Similarly,
integration
with accounting by automating invoice transfer to th
e CMS64 system
could be added with
no changes to the existing system functionality and features.

A

method for automating the Invoice
process into the CMS system to alleviate ongoing data entry
has already been identified through
collaboration with
DHCS Ac
counting
. The return on investment could be realized in an extremely short
period. The

proposed accounting
automation
has
the potential for long
-
te
rm resource savings and
enhanced
data integrity.

CapMan

is scalable and
take
s

advantage of Microsoft Networ
k Load Balancing Services (NLB) to allow
the system to scale without the traditional incremental penalty imposed on growing systems. Since NLB
is a naturally load
-
balanced solution, allowing new hardware or virtual server instances to be added
transparent
ly to the current implementation and providing a full
-
factor increase in system performance.
NLB presents a virtual computer, with a single DNS and IP that systems or users connect to, while NLB
distributes processes across the servers in the NLB cluster.

An Assessment of the Extendibility and Capacity of the
CapMan

System


5

Figure
2

-

NLB Cluster

Server
3
Server
4
Server
1
Server
2
Server
5
Server
6
NLB
Virtual Server


Processing Performance

The current application and data repositories were designed and tested to accommodate significant
growth

in

enrollment, contract, invoice
, and payment data.
Stress testing was performed to ensure
sufficient capacity
while meeting specified performance criteria. Below is a summary of the Stress and
Load test results.





Completed the required tests on 6 million beneficiaries in six hours.



Stress and Load test was performe
d with 6 million beneficiaries.
This is 150% of the current
production load.



Based on production enrollment data for July 2009 through November 2009, the Net Eligibility
changes
averaged 5
-
10% from month to month. This
would result in approximate 875 million
payment records for 5.2 million beneficiaries over 36 months.



Stress and Load test was performed with 100% retroactive Net Eligibility changes for 6
capitation months for all 6 million beneficiaries.

This resulted
in a total of 1.975 billion payment
records.

Anticipated

Processing Impacts

Considering the
robust

stress and load testing of 100% Net Eligibility changes
, 10x historical activity
,
CapMan

is capable
of

support
ing

36 months o
f payment history for 3
00%
the

current number of
beneficiaries

without any additional changes
. By extending stress and load test parameters further, it is
possible to identify upper limits of enrollment capacity that can be processed within the stated
requirement of 72 hours.

An Assessment of the Extendibility and Capacity of the
CapMan

System


6

Database

Design

This section addresses the content, design, processing capabilities, and the volume of the CapMan
Database.


The database management system used for CapMan is a Microsoft SQL Server 2008
database.

Content

The CapMan data base addresses:



Contracts
with managed care plans;



Details on each beneficiary paid
;



Details on the amount paid for base and supplemental amounts for each month for
each
beneficiary for each plan; and



The balance of amount paid for each month over 13 months; totals incorporate cha
nges as a
result of retroactive adjustments.

Design

Considering very large volume of data produced by the application, the following design patterns were
applied:



Payment data has been partitioned by service month.



Database has been designed based on star
-
schema pattern.



Aggregation tables have been implemented.

This forward
-
thinking approach has enabled the database to acquire some impressive statistics based on
the data for March and April 2011.

Table
1

-

Database
-
Level S
tatistics

Item

Volume

Number of Tables

58

Total Database Size

92,162 MB

Total Database Log File Size

34,888 MB

Database Size


Beneficiaries and Contracts

20,992 MB

Database Size


Details FY 2009

16,640 MB

Database Size


Details FY 2010

6,400 MB

Database
Size


Details FY 2011

16,384 MB

Database Size


Details FY 2012

1
,
024 MB

Total Database Rows

~120 million rows

An Assessment of the Extendibility and Capacity of the
CapMan

System


7

Table
2

-

Beneficiary and D
etails
-
L
evel
S
tatistics

Item

Volume

Database Rows


Invoice Details

~ 110 million rows

Total Number of Beneficiaries

6,438,595

Total number of contracts (counting all versions)

937

Total number of invoices

959

Total number of distinct contracts

91

Anticipated

Database Impacts

The addition of SPD’s will increase
the number of beneficiarie
s by

less than ten percent. Medi
-
Medi’s
could add 25 percent over the next two years. Performance testing has already been performed with 6
million beneficiaries so that growth in the next two years from the 1115 Waiver is well within the proven
database

capabilities of
CapMan
.

Looking toward federal health care reform, a
n increase in the number of beneficiaries may require
changes to the database indexes and queries
. However
,
this is a typical
maintenance
exercise of

any
database
-
oriented application.


No radical changes in the design of the database are anticipated.

Application Architecture

State of the art application architecture calls
for the s
eparation of the tiers (the types of functionality
performed)
. I
n addition to reducing maintenance effort,
separation of tiers enables placing tiers on
different computing servers so that added speed can be provided that targets the function in need of
more power.

Isolation of one tier from
another is critical so

that a change in one tier does not have a cascad
ing,
unintended impact on other tiers
. T
his reduces the level of analysis, design, build, and test required to
make changes. Isolation also enables establishing logical security (authorization and authenticati
on) at a
granular level
commensurate with ea
ch type of user’s “need to know
.


Separation

also enables
implementing firewalls for added security in case any portion of the system is made available over the
public internet at a later time. For example, it would be possible to allow authorized health

plan
representatives to

view contract terms without risk of exposing any portion of the system to
unauthorized updates.

The tiers are:



Presentation



Orchestration



Business Logic



Database Access



EDI Transformation (HIPAA data formatting)

An Assessment of the Extendibility and Capacity of the
CapMan

System


8

The presentation

is implemented as web pages. There are a large number of web pages to enable
Managed Care staff to modify and view various aspects of each plan’s contract features. However, the
presentation layer is a small portion of the overall system functionality.

Orchestation uses the Microsoft
BizTalk

server. The
BizTalk

server manages “end to end”
orchestrations of all tasks from selection of beneficiaries for a plan, to calculations, to invoice
preparation, to database updates, to the data transformation into

the HIPAA
-
required X.12 820 5010
data set. The use of orchestrations is one of the more advanced approaches to application architecture
used in software design and execution anywhere.

Business

logic is all written in Microsoft .
NET

3.5 framework. This i
s the most modern application in the
Department of Health Care Services.

Database access uses Microsoft’s
Entity Framework to

handle the organization of data selected from the
relational database into objects used in the .
NET

framework.

CapMan

uses the

Edifecs

XEngine software product to perform transformation of data to meet HIPAA
requirements. The
Edifecs product

supports 4010, 5010 and HL7 data transformations, among others.
Each health plan can have a different implementation if needed in the fut
ure as part of any future HIPAA
changes or unique circumstances that may arise. All health plans will implement the same
transformation rules in the beginning. The
Companion

Guide

developed for
CapMan

represents a
complete implementation of the 5010 st
andard for the remittance advice data specification (X.12 820).

Anticipated

Application Architecture Impacts

There are no anticipated impacts to the application architecture.

Computing Environment

Testing was

performed
in

the
current
production environment established to operate
CapMan
. The
production environment was specified as part of the detailed design and technical architecture phase of
the project and completed in 2009. The computing en
vironment
architecture

is depicted in Fig
ure 3

conforms to DHCS ITSD standards including:



Microsoft Windows Server operating system



Dell
Poweredge R900

servers with load balancing



Disk storage provided through a Storage Area Network

The
overall

environment also includes the MEDS
database.

A series of extracts from MEDS provide the
Medi
-
Cal beneficiaries enrolled in managed care plans and the aid codes used in conjunction with the
CapMan

contract database to calculate the amount to pay for the current month and for any retroactive
adjustm
ents.
An Assessment of the Extendibility and Capacity of the
CapMan

System


9

Figure
3

-

CapMan Production System Architecture


Calculation

processing

EDI
transformation

Database

Management:
load balanced and

clust
ered

Data storage
(unlimited
expansion)

BizTalk

Orchestration

Firewall
protects
data

Firewall

protects
system

An Assessment of the Extendibility and Capacity of the
CapMan

System


10

The production and staging environments are hosted at the State data center. The development and
test environments are hosted at ITSD. Total acquisition costs were

over

$1 million
.

Backup a
nd
Recovery enabled through

existing processes/procedures
utilizing
an off
-
site facility.
The
SAN can readily scale to support the entire Medi
-
Cal beneficiary population including the projected
capacity required with implementation of PPACA.

Anticipated Comp
uting Environment Impacts

A refresh of the equipment is not projected for at least three years. The current configuration enables
any required refresh to occur only as needed and only for the impacted components without
consequence to other parts of the s
ystem. For example, disk capacity can be added with no impact to
the servers and vice versa.

The
CapMan

system is “instrumented” in order to monitor system performance. Instrumentation is
turned on when needed to assess performance or to identify where a

bottleneck may exist.
(Instrumentation is only turned on when needed as the instrumentation itself can cause processing
delays!)

If there are any delays in adding or retrieving data from the database management system, more servers
could be targeted to

support the SQL Server implementation.

If the business logic processing to calculate capitated payments experiences delays, more servers could
be targeted to the application tier.

If the transformation to EDI data sets is delayed, servers could be targete
d to support the
Edifecs
XEngine

software.

Another area that may experience change is around the reporting capabilities. The database design has
proven responsive to reporting needs. Reporting uses Microsoft’s SQL Server Reporting Services (SSRS).
Altho
ugh not intended for use by “end users”, SSRS enables an experienced reporting specialist to
efficiently specify, demonstrate, modify as needed based on customer verification, and finalize. As
reports may process thousands or even millions of rows of bene
ficiary data, it is essential to have the
large scale processing power in place. At a future point it may be appropriate to configure separate
computing servers to support the SSRS reporting capabilities for added speed and to avoid competing
with any oth
er production processing underway.

Ongoing Maintenance and Support

The biggest risk the Department has in being able to implement parts of the 1115 Waiver using the
CapMan system is a lack of ongoing development and support resources.
Two positions are bu
dgeted to
support
CapMan

for

ongoing system operational support. This is
significantly

less than
the staffing
provided for systems of
similar

size.
CapMan

needs both
a
short
-
term and longer
-
term plan for a
ny
changes to the application.

An Assessment of the Extendibility and Capacity of the
CapMan

System


11

Going forward, wh
ether through vendor staff or State staff, the following ongoing needs have been
identified:

Table
3

-

Anticipated
CapMan

Staffing

Needs

System Functionality

Required PYs


Analyst

Developer

Other

Contract Management

0.25

0.25


MEDS Extracts



0.25

Payment Calculation

0.5

0.5


Invoice Preparation

0.5

0.5


Database Management


0.25


Remittance Advice Preparation

0.5

0.5


Reporting

0.25

1.0


System Administration



1.0

Application Maintenance Manager



0.5

TOTALS

2.0

3.0

1.75


Comparison to Other Systems of Similar Size and Complexity

In order to validate the
ongoing maintenance needs of CapMan, other DHCS systems of similar size and
complexity were examined
.

California Children’s Service

The California Children’s Service

(CCS) program recently completed procurement for annual
maintenance of their CMS Net application with a contract amount of $1.3 million for six contract
staff; CCS also has a team of State IT staff to support the application.

Short
-
Doyle/Medi
-
Cal

The Shor
t
-
Doyle / Medi
-
Cal system just completed its first full year of maintenance. The
Department spent
$1 million for five contract staff. ITSD and OHC also have a combined team of 5
staff to support the application.


Subject Matter Expertise

In
addition to th
e technical resources outlined in the above table, the Department will also need to
continue to dedicate subject matter expertise in several areas:



Project Sponsorship



Contracts



Calculations

An Assessment of the Extendibility and Capacity of the
CapMan

System


12



Overall
Managed Care process



Accounting and Invoice



Quality
Assurance



System Procedures and Documentation specialist

D
ocumentation

Upkeep

The original CapMan
project

specified a series of documents to verify that the system was built to fulfill
expectations. These documents include:



Project Organization Overview



P
roject Work Plan and Schedule



Staffing Management Plan



Quality Assurance Plan



Conceptual Design



Requirements Specifications



Design Specifications



System Test Plan



Acceptance Test Plan



Load/Stress Test Plan



Load/Stress Test Results



System Test Results



Training Plan



Training Materials



Maintenance and Administration Plan



Transition (Turn Over) Plan



Implementation Plan


The Use Cases in the Detailed Design have received continuous update throughout the life of
CapMan
.
Each time a requirement was modified
or the way a process is implemented changed, the appropriate
use cases were modified as well. Similar documentation changes have occurred throughout for the
database design. The component model has remained fairly stable throughout. The Object model has

incurred changes that could require some updates to perfect their alignment with the system as built.

Costs

CapMan

vendor contract costs to date are $2.4 million and carry through to implementation in July
2011. Hardware costs total about $1 million for
all four environments (development, testing, staging,
and production). Other vendor costs incurred for RFP preparation and subject matter expertise
An Assessment of the Extendibility and Capacity of the
CapMan

System


13

approximate $1 million.
The other costs associated with
CapMan

are those
DHCS

staff costs for p
roject
management and

subject matter

expertise.


Conclusions

CapMan’s

primary functionality has been appropriately architected, built and tested to provide system
support to MMCD, TPLRD and HIPP. The 1115 Waiver does have impact to several reporting
components
and the invoice process. The impact will add to the maintenance of
CapMan
. However,
the flexibility of the system will support the changes through the existing processing features. The built
-
in expandability will allow for the expected growth in benefic
iaries without impact to the current
architecture or its configuration.

The
CapMan

application and computing environments have been architected, designed, built, and
tested to immediately su
pport
over 6

million beneficiaries

133
% of
the projected process
ing capacity
of current managed care enrollment
. This is more than sufficient to cover

the additional
554,000
beneficiaries
projected from SPDs and
Dual Eligibles
.

For future growth in the number of beneficiaries,
the main consideration should be to moni
tor disk capacity and add to that capacity as needed.

CapMan

application design can readily be modified to support changes required from the 1115 Waiver.
Most of the changes are in the modification or creation of reporting considerations

and invoice fundi
ng
splits
. There are minor requirements to create a mechanism to capture the
1115 waiver
categories
identified for
invoice
tracking.
However, no funding has been identified to support changes.

Planning, budgeting, staffing, and

procurements have
not
been

considered
sufficient
at this time
to
address
the necessary system
enhancement for SPDs,
Dual Eligibles

or ongoing maintenance
of the
existing
CapMan

application as built prior to the 1115 Waiver.