Health Care Administration Master Roster Contract by qlc15660

VIEWS: 103 PAGES: 102

printable-contract-of pdf

More Info
									                        Health Care Administration
                         Master Roster Contract
                                STATEMENT OF WORK
                             FOR TECHNOLOGY SERVICES
                                       ISSUED BY
                          Minnesota Department of Human Services

Project Title:   Report Cost Benefit Analysis (CBA) Resulting from
                 Technology and Business Process Redesign Projects

I. Description of the Business Need:
DHS is the State’s largest Executive branch agency with primary responsibility for developing
policy and administering State human service programs such as cash and food assistance, health
care, and services for people who are elderly or disabled. The Department serves over 600,000
citizens with various Minnesota Health Care Programs (MHCP) including Medical Assistance
(MA), General Assistance Medical Care (GAMC), and MinnesotaCare. Eligibility determination
and case management for health care programs are decentralized over 87 distinct county
governments, tribal governments, central DHS case-processing facilities (MinnesotaCare), and
other business partners.

The Health Care Administration (HSA) area of the Department of Human Services (DHS) has
four major health care technology/business process projects underway that will significantly
change how we deliver service to our customers. In the future, business activities traditionally
performed by DHS staff located at the central office, may be performed by county staff located
at county social service centers, and vice versa. DHS is proposing to consolidate some service
delivery activities, and decentralize others to achieve our over-arching mission and objectives,
which are to:

    1.   Reduce administrative costs
    2.   Improve customer service, including faster service
    3.   Increase administrative flexibility
    4.   Improve program integrity; e.g. accurate program enrollment and claims payment.

In 2001, DHS embarked on a business process reengineering effort, which involved in part, a
study conducted by KPMG Consulting Services. This effort and subsequent management
initiatives gave rise to the following key technology projects:

   • HealthMatch, which will fully automate eligibility determinations for most Minnesota
     Health Care Programs (MHCP) including Medical Assistance, General Assistance Medical
     Care, and MinnesotaCare and select the program that provides the greatest benefits for the
     lowest cost. Consumers and their advocates will have direct access to program information,
     applications and renewals via the internet. This project is currently in development.
  • Centralized Electronic Document Management System (EDMS) and Incoming Mail
    Center, which will provide a central repository and distribution center for health care
    applications and related documents, as well as clear names and assign personal
    identification numbers. This project is proposed at this time.

  • Centralized Customer Contact Center, which will provide a single entry point for
    customers seeking information on Minnesota health care programs. This project is
    proposed at this time.
  • Health Plan Enrollment, which will streamline our managed care health plan enrollment
    process and make it more accessible to Minnesota citizens. This project is proposed at this
    time.

See Attachment A for more information about these projects.

Cost benefit analyses were prepared to a varying degree on each of these projects in an effort to
make decisions on their viability. DHS now seeks a comprehensive and formal means of
measuring their combined cost benefit analysis (CBA) across both state and local government.
DHS is seeking a qualified vendor to provide a team of analysts to determine what we need to
measure, how to measure it, and to implement a measurement process to produce an ROI for
each of the above projects and a combined ROI for all of them. Throughout the remainder of this
document, we refer to these standard measurements as metrics. For business performance
metrics that are not ready to be measured due to unavailability of data, timing issues, or some
other reason, the final report must contain specific work plans to complete the ROI process for
those remaining measurements. DHS is interested in initial cost benefit analysis from these
projects, as well as recommendations for ongoing monitoring of metrics such as cycle time, error
rates, costs, cost avoidance, and net savings.

Working assumptions applicable to this project include:

    •   HealthMatch is the foundational project necessary to execute the other projects
    •   The centralized health care EDMS would use the DHS enterprise EDMS architecture
        and support processes. The centralized EDMS would require some additional hardware
        and/or software to accommodate the increased volume of mail, but the department would
        not build an entirely new system.
    •   The centralized call center would use the DHS enterprise call center technology that will
        implemented August 2005 in the new Elmer Anderson human services building. This
        technology includes VoIP, IVR, and other call center technology. See Attachment A
        for more call center technology information.
    •   The centralized health plan enrollment operation would use HealthMatch, the centralized
        EDMS, and the centralized call center as integral parts of its infrastructure.
    •   If development must be phased, the preferred order of development would be:
        HealthMatch, centralized EDMS, centralized call center, centralized health plan
        enrollment.
    •   Some or all of these projects will be developed for future use in cash, food support, and
        other non-health care programs administered at the state or county level.
       •     The 87 counties and one tribe administering health care all have different organizational
             models, technical capabilities, financing, and business processes. The vendor for this
             effort will be required to interview, or visit when feasible, a sampling of diverse counties
             to draw out conclusions, risks, and ROI regarding implementation of these projects at the
             county level.

The following attachments are included to provide you with additional background information:

   •        Attachment A – Project Summaries
   •        Attachment B – Health Care Automation Request for Proposal
   •        Attachment C – DHS Strategic Plan for Information Technology


All work must be performed within the State of Minnesota.


II. Product or Result:
The primary product of this contracting engagement will be a series written reports that describe:

   •       the methodology used to complete the assessment
   •       the specific metrics used to determine the projected cost benefit analysis for each project
   •       a detailed plan for establishing ongoing metrics
   •       a projected cost benefit analysis based on current technology projects and the redesign of
           state and county roles and responsibilities currently proposed by DHS.

This will require research and evaluation of existing documentation about our business process
reengineering effort and our technology projects, understanding DHS goals and project-specific
goals, and expertise to design tactical and operational measures that will tell us whether we will
achieve the cost benefit analysis we anticipated upon launching these four key technology-based
projects. DHS requires a comprehensive view of the impacts of these projects and their
individual and collective ROI. All ROI analyses must take into account impacts of these projects
on other, primarily non-health care, programs that are not covered by these projects.

The contracting engagement will include:

   • interacting with stakeholders, including but not limited to department managers, project
     managers, operational and technical staff of DHS and county offices.
   • gathering and synthesizing data from a variety of sources, including validating conclusions
     through research, and
   • presenting both interim and final recommendations to a project steering committee

The ROI analyses should be completed and presented to the project steering committee in the
following order at agreed upon time intervals; e.g. the HealthMatch ROI would be presented a
month after contract execution, the centralized EDMS ROI would be presented three weeks later,
etc…
1.   HealthMatch
2.   Centralized EDMS
3.   Centralized Call Center/Health Plan Enrollment
4.   Final, combined ROI for all projects
Required Tasks:

  • Quickly obtain an understanding of current DHS and county health care processes, DHS
    Business Process Design (BPR) and technology initiatives, issues, objectives, strategies and
    cross-dependencies by reviewing documentation and interviewing key personnel.

  • Validate that DHS has fully identified measurable critical success factors for each of the
    four technology projects sufficient to drive the identification of tangible and intangible
    benefits. If there are gaps or weaknesses, resolve them through working with the
    stakeholders.

  • Review DHS’s current methods for capturing project costs on the four major technology
    projects to ensure that we are accurately capturing all costs needed for effective ROI
    measurement.

  • Analyze the current process costs (fixed and variable) considering such things as labor,
    overhead, hardware/software, contract costs, supplies, mailing, equipment, training, travel,
    telecommunication costs, etc. The scope includes costs incurred at DHS offices, as well as
    at the counties.

  • Identify and recommend process metrics. Recommend specific tools and procedures to
    generate and report those metrics.

  • Work with DHS management to identify the specific measures and assess what it would
    take to implement them. Present findings using the DHS Performance Measurement
    Framework.

  • Identify ways to measure intangible factors such as customer satisfaction, increased
    customer access, relationships and collaboration between state and county personnel and
    other key partners such as medical providers. Measurements must include post-project
    evaluation as well as ongoing needs.

  • Prepare a work plan with specific tasks to ensure that all work is complete by the due date.
    Identify project deliverables and obtain DHS approval at specified project milestones.

  • Prepare and deliver intermittent updates/findings, specific milestone deliverables, as well as
    a formal ROI report at the conclusion of the project.


III. Required Skills

  1. Experience identifying and measuring cost benefit analysis (CBA) on government
     programs administration, involving different levels of government and the introduction of
     new technology.
  2. Experience in conducting cost/benefit analysis on technology-based projects.
  3. Experience recommending metrics that are suited to a public organization’s culture,
     environment, and available data.


IV. Desired Skills

  1. Knowledge of the workings of state government, including human resource management,
     administrative contracting and procurement, budget and fiscal management.
  2. Knowledge of health care program rules and regulations.
  3. Familiarity with health care terminology.
  4. Familiarity with electronic document management systems.
  5. Exposure to trends and issues in administering public health care programs.
  6. Experience writing formal reports and presenting them to senior-level management.
  7. Ability to quickly and efficiently conduct necessary research, synthesize high volumes of
     information, and reach logical and meaningful conclusions.
  8. Ability to communicate with a variety of stakeholders, negotiate compromises, and apply
     meeting facilitation techniques to help groups reach consensus.
  9. Experience leading or participating in business process reengineering initiatives.


Duration of Assignment:

The work must be complete by May 1, 2005. Given the scope of the analysis, we anticipate that
a team will be needed with someone to manage and coordinate the work.


Proposal Requirements:

DHS expects a written proposal describing how this work will be carried out, a description of
resources involved (including their experience and training), the recommended deliverables and
interim review points, and the means you will use to ensure the quality of the assessment and
recommendations. We require a description of similar projects you have satisfactorily
completed, including their size, cost, nature, and complexity, as well as references DHS may
contact.

Proposal must be in writing, and submitted on time. The proposal must be delivered in two
forms: written and electronic. The written proposals should be submitted in 12-point font on 8 ½
X 11 paper, single-spaced and should not exceed the suggested page limits set forth below. All
proposals, including required copies (6), must be submitted in a single sealed package. There
must be one original signed in ink by an officer of the company. The electronic version of the
proposal is to be included in the envelope on diskette or CD in Microsoft Word (2000 or newer).

The following is minimum contents of any proposal. Include a cover page, a transmittal letter
and a table of contents. Any omissions from the minimum contents may be considered as being
in non-compliance with this Statement of Work and may result in the rejection of the proposal.
Please provide the following information in the below order. Append any additional information
at the end of the proposal:
1.   Contact Information (limit to 1 page each)
     a.     President/CEO/Person in charge: Name, address, phone, e-mail
     b.     Engagement Manager: Name, address, phone, e-mail
     c.     Contractor(s) assigned to this project: Name, address, phone, e-mail and resume.

2.   Company Profile (limit to 2 pages)
     a.   History of the company
     b.   Ownership model (partnership, public, sole proprietor, subsidiary, etc.)
     c.   Staff resources (categorize staff by role/responsibility and skill level)
     d.   Organizational structure and philosophy
     e.   Financial information for the past two years

3.   Qualifications in measuring cost benefit analysis from business process reengineering and
     technology projects
     a.     Describe your experience and track record relevant to measuring cost benefit
            analysis on government programs administration, involving different levels of
            government and the introduction of new technology.
     b.     Describe your experience and track record relevant to conducting cost/benefit
            analysis on technology-based projects.
     c.     Describe your experience recommending metrics that are suited to a public
            organization’s culture, environment, and available data.
     d.     Provide resumes of the personnel who will be assigned to this project. (Identified
            staff must be available at the desired start date through the engagement.) Each
            resume should be limited to 2 pages.
     e.     Provide a list of project sponsors, customer references, and phone numbers
            relevant to this project that we may contact (limit to 1 page).

4.   Proposal – please use tabs to identify the following sections of your proposal
     a.    Specify in detail, your understanding of the business need and business
           requirements of this project.
     b.    Describe your experience and the methodology you will use for completing the
           analysis, measuring individual project ROI and ROI overall from process
           changes.
     c.    Specify in detail the tasks and deliverables you envision in this engagement.
     d.    Specify in detail any system requirements, disk space, operating system, hardware
           and other software needed to accomplish your work on this project.
     e.    Describe how you would validate your conclusions with ongoing measurements
           to be implemented.

5.   Project Plan
     a.      Define tasks and timelines to design, develop and deliver the cost benefit analysis
             report.
     b.      Describe your approach to project management.
6.      Terms, Conditions, and Engagement Cost Estimate
        a.     Hourly rates (categorized by role/responsibility and skill level)
        b.     Number of staff assigned to accomplish tasks outlined
        c.     Estimate cost per task
        d.     Costs for any software licenses you require
        e.     Overall project cost
        f.     Requirements for support and involvement of DHS staff
        g.     Estimate travel expenses


This Statement of Work does not obligate the state to award a contract or complete the
assignment, and the state reserves the right to cancel the solicitation if it is considered to be in its
best interest.

The designated project manager for this Statement of Work is Kathleen Henry. Other state
personnel are NOT authorized to discuss this statement of work with respondents.

Description of the evaluation process /Scoring

Written proposals will be scored by an Evaluation Team.

 •   Scoring/weighting:
           Step One: Pass/Fail, on Requirements/Required Skills.
           Step Two: Scoring of written proposals to identify top candidates to be invited in to
           deliver a management presentation.
           Demonstrated Skills and Experience in areas specified under Sections III and IV,
           Required and Desired Skills = 70, Ability to Deliver Project = 20, Rate = 10%
           Step Three: Final evaluation of points.

Response Requirements

Vendors must submit proposal packages (requirements described above) as follows.
   Sandy Triemert, DHS – Health Care Operations
   444 Lafayette Road
   St. Paul, MN 55155-3849.

Responses must be received by Sandy no later than 3:00 p.m. Central Time on the date responses
are due.

    • Location of Service Disclosure and Certification Statement
The Department of Human Services requires that all work done on this contract must be performed within
the United States.

Please select one of the following statements to include in your response certifying that you agree to this.

1. The services to be performed under the anticipated contract as specified in our proposal will be
    performed ENTIRELY within the State of Minnesota.

2. The services to be performed under the anticipated contract as specified in our proposal entail work
   ENTIRELY within another state within the United States.

3. The services to be performed under the anticipated contract as specified in our proposal will be
   performed in part within Minnesota and in part within another state within the United States.

The cover memo must include one of the listed certifications in order to comply with State of Minnesota
requirements.

Responses that do not include a Location of Service Disclosure statement will NOT be considered.


The vendor who is awarded the contract will be required to sign the State of Minnesota Location of
Service Disclosure and Certification form at the time of the contract signing. This form is located at the
back of this Statement of Work.


The items above must be completely satisfied in the submission in order for the candidate
to be considered.

Response Due Date: March 22, 2005 by 3:00 p.m. Central Time. Late responses will not
be accepted.

Questions
Any questions regarding this master roster contract should be submitted via mail or e-mail by:
March 14, 2005 by 3:00 p.m. (reference “BPR CBA Assessment” on the subject line of the
email)

Name: Sandy Triemert
Department: Human Services
E-mail Address: Sandy.Triemert@state.mn.us

Expected date of decision: April 11, 2005 by 3:00 p.m.
           SOW Attachment A – Project Summaries

                        Health Care Administration
                             Master Contract
                                STATEMENT OF WORK
                             FOR TECHNOLOGY SERVICES
                                       ISSUED BY
                          Minnesota Department of Human Services

To assist you in preparing your proposal, additional background follows on the DHS projects and
their status.

HealthMatch
Currently, Medical Assistance and General Assistance Medical Care are administered locally by
county governments and MinnesotaCare is administered centrally by the DHS. Counties have
the option of administering MinnesotaCare and 28 counties are currently performing enrollment
activities for a portion of the MinnesotaCare applicants and enrollees residing in these individual
counties.

DHS uses two large mainframe computer systems to assist with eligibility determination and
information retention for health care programs: MAXIS, Minnesota’s Family Assistance
Management Information System, (or “FAMIS”) and the Medicaid Management Information
System (MMIS). Neither MAXIS nor MMIS were designed specifically to support an automated
eligibility determination for health care programs. MAXIS was originally designed to automate
eligibility for cash and food support programs and added MA and GAMC late in the design.
MAXIS improved the level of automated support for health care programs in 2002. The primary
function of MMIS is to process and pay claims to health care providers for services delivered to
MA, GAMC and MinnesotaCare enrollees. To date, there is no “automated eligibility system”
for MinnesotaCare. Demographic data and eligibility results are entered into MMIS for an
automated calculation of premiums. The MMIS system also performs some eligibility editing,
sets dates for eligibility renewals and generates notices to enrollees.

The bifurcated administration results in duplication of effort as well as added complexity to an
already complex series of programs and processes. The lack of full automation contributes to
inconsistent application of policy and, consequently, a greater risk of error. The current systems
have limited capacity to provide data necessary to monitor regulatory compliance and provide
many opportunities for creative eligibility results.
The purpose of the HealthMatch project is to improve client access to services, deliver greater
efficiencies in health care program administration and improve the integrity of MHCP. This new
web based automated eligibility system, will combine all Minnesota Health Care Programs
(MHCP) into one system and chose the program offering the highest level of benefits at the
lowest cost for eligible consumers.
HealthMatch will allow people to apply for, renew or update health care program eligibility 24
hours a day, 7 days weeks and 365 days a year. The system will guide them and automatically
produce confirmation of their on-line activities and request for documentation to be validated by
an eligibility worker upon receipt.

HealthMatch has been designed to minimize worker intervention in the eligibility determination
process. This new system will automatically assess data, produce notices or requests for
information and calculate outcomes. The HealthMatch toolbox will provide immediate access to
policy resources for workers. Business conducted on-line will minimize the need for data entry.
The focus of an eligibility worker should shift from the programs to the people they serve.

HealthMatch will control the timing, accuracy and consistency of eligibility determinations.
The system will also provide state and county managers with tools to track and monitor
performance. In the event of mismanagement, intervention to resolve an issue can occur without
delay.

The current status of the HealthMatch Project is: The requirements and design phases of
development have concluded and construction has begun. The pilot of HealthMatch is currently
slated to commence in fall of 2005, with a phased implementation period to begin three months
later and continue through June of 2006.


Centralized Electronic Document Management System (EDMS) and Incoming
Mail Center

Currently, the MinnesotaCare operation receives thousands of paper applications, renewal and
other related documents each month. Once received, all applications and documents are scanned
and indexed to the EDMS. After an application or document is captured in the EDMS system, it
is available to all MinnesotaCare enrollment representatives. Local county agencies also receive
thousands of documents and establish files in their own electronic or paper file systems. Each
agency has access only to documents within their individual systems. When an MHCP enrollee
moves, the paper files are mailed to the new county of residence. When a family has members in
both MA and MinnesotaCare, an electronic file is maintained at DHS for the MinnesotaCare
enrollees and a second file is maintained at the county of residence for the MA enrollees.

Something as simple as providing a return address for applications is a challenge for DHS and
applicants. In an effort to keep the application form as “short” as possible, applicants are
instructed to send their application to MinnesotaCare or their local agency. The MinnesotaCare
address is printed in the instruction but county addresses are not. The challenge clearly rests
with the person trying to access health care. The purpose of the Centralized Electronic
Document Management System (EDMS) and Incoming Mail Center Project is to address this
critical business need. In the future, application or other documents will be scanned into a secure
EDMS. The client will have the freedom to request case specific assistance anywhere in the
state without delays and any state or county employee (with proper security level) will have
access to case documents to provide assistance. The added benefit of a single mailing address
will reduce confusion for clients and would allow a return address envelope to be included in the
application packet.

Centralized management of paper documents is the cornerstone of a seamless statewide system
of health care program enrollment. A single address to receive mail and an electronic document
management system (EDMS) to distribute applications and related documents statewide will
assure access to all materials necessary to provide services to health care program enrollees.
Without a central repository for documents and statewide access to retrieve them, other aspects
of business process reengineering are extremely limited.

The State-wide EDMS and Mail Center Project is currently in the planning phase.


Centralized Customer Contact Center
The DHS central office is moving to new office facilities, which is under construction. The
move will occur in mid-2005. As part of this move, DHS plans to integrate call centers, help
desks, and telecommunications equipment and support. The result will be a single statewide
client contact center.

This will strengthen the DHS role as a supervising agency and assure access to information and
assistance for consumers. A 1-800 number for general information and assistance will provide
clients with easy access to accurate information, referral and technical support for the
HealthMatch website to encourage online business relationships. Health plan enrollment via
telephone will expedite enrollment in health plans. Local agencies will benefit with a reduction
in their administrative activities and DHS will have a reliable tool to monitor local access for
people in need of personal assistance.

The charge of developing the enterprise call center infrastructure is to consider the best practices
in the call center industry and determine which practices could apply to DHS businesses and, if
implemented, could offer the greatest cost benefit by decreasing operating costs and improving
customer service. The following are the best practices in technology and operations that will be
implemented for the existing 12 DHS contact centers and would also be available for a newly
organized (or reformulated) centralized contact center for Health Care.

Technology Best Practices:
   • Voice Over Internet Protocol Phone System: This new telephone platform will make
      previously unavailable call handling and call routing tools possible for the first time and
      will save money on long distance calls, since calls are routed digitally (and securely) over
      the internet. Available with the relocation to each building.
   • Automatic Call Distribution (ACD) System: This software will allow better
      supervisory control over all types of customer contact. Following the automated rules
      specified by the supervisors, letters, emails and calls will be routed through the system
      and sent to the most appropriate agent for response. This is called “Intelligent Call
      Routing”. The ACD system will also allow supervisors to “click” on a call to silently
      monitor, assist the agent and, if necessary, take over the call. Available with the
    relocation to each new building.
•   Computer Telephone Integration (CTI): Software that will allow the caller (when
    appropriate) to input an identifier (MAID# or Provider ID #) which will “pop” the MMIS
    screen to the agent’s computer as the call is answered. This feature will save keying time
    for the agent and improve response time for the customer. Available after the relocation
    to new buildings.
•   Integrated Voice Response (IVR): Customers will be able to choose if they want to
    obtain information without waiting in a queue by selecting self service options, or
    automatically contact a human agent to assist them. (More robust IVR applications will
    be developed through Websphere with the relocations.)
•   Contact Tracking Software: Using the DHS owned MAGIC tracking software, agents
    will begin to document each call with a number of automated steps. This documentation
    will allow daily management reports on who is calling and what their issues are. This
    type of reporting will be valuable to the communications officers, training teams, web
    content teams and Senior Management. (Development is beginning now with Child
    Support and will start with other call centers soon.)
•   Knowledge Base Software: Agents answering calls about our very complex business
    and systems need solid, reproducible answers. These answers will be available through a
    Knowledge Base that will be integrated with DHS web content, automatically updating
    the Knowledge Base with any change occurring in the web content. (Development will
    begin soon.)
•   EDMS: Electronic Document Management Systems: Agents will be able to review real
    documents online, fax or email the document to others and print a hard copy to mail, if
    necessary.

Operational Best Practices
• Co-location of existing contact centers. Centers will be located next to each other and
   away from the business that they currently support. This will allow for workflow
   adjustments through cross training and better supervision and management.
• Conversion from “call center” to “Customer Contact Center”: Today’s business
   partners and customers want to utilize more than the telephone to do business with DHS.
   To that end we will “web enable” our contact centers. This new web enabled
   environment will allow phone agents to handle email and mail, “push” the appropriate
   web page to the customer, and use automated voice response for self service (when the
   customer wishes to use that channel.)
• Cooperative Hiring, Interviewing and Orientation: Many DHS call centers are using
   the same lists of applicants for agent positions. An applicant may be invited to many
   interviews for positions that are similar. There is interest in the possibilities of joint
   interviewing, hiring and orientation.
• Language Lines: Through the Contact Centers customers with limited English will be
   able to access an interpreter who will stay on the call and interpret the information for
   them.
   •   Cross Training: Cross training of co-located agents is possible once the new
       technologies are implemented. In reviewing project schedules, this appears to be two to
       three years in the future.
   •   Enterprise Management: Co-location and technology without a management structure
       that stretches across all administrations will not guarantee that technologies and
       opportunities are maximized for the benefit of the department.
   •   Quality Assurance: Customer feedback via online and telephone surveys, live silent
       monitoring of active calls, report analysis and benchmarking will all be mechanisms to
       assure our customers continue to receive quality service.


Health Plan Enrollment
Currently, health plan education and enrollment activities for all programs are performed via
USPS. Persons approved for MA/GAMC receive enrollment forms, an MA/GAMC booklet and
health plan booklets for each plan available in their county of residence. The core activities
related to local health plan options for MA and GAMC are currently automated in the MMIS
system. Reports are distributed electronically to counties to print, package and mail enrollment
materials to enrollees. Several counties still provide health care enrollment presentations where
the enrollment process is explained on site and enrollment materials are presented. Enrollment
materials are also explained by other county staff that are working with the clients. A similar
process occurs for MinnesotaCare applicants and enrollees; however, they receive a
MinnesotaCare booklet and may have different plan options to select from. MinnesotaCare
health plan enrollment materials are automatically distributed via MMIS to the IOC for printing,
packaging and mailing. In addition to the difference in plan options between MA/GAMC and
MinnesotaCare, the programs have differences in the length of time permitted to make a
selection and may have different default options if a plan selection is not made within the allotted
time frame. The cost for postage varies depending on the number of options available but
averages between $2 and $3 per packet plus the cost of a postage paid return envelope.
Hennepin County has reported postage exceeding $7 per packet for some of their enrollees. The
costs of printing and postage are absorbed by the agency mailing the packets. DHS currently
spends approximately $85,000 per year for MinnesotaCare enrollees. The exact cost for local
county agencies has not been determined.

HealthMatch will present a single program, MHCP, to enrollees and will also add to the existing
mixed households who currently have some family members enrolled in MinnesotaCare and
other family members enrolled in MA or GAMC. Approximately 18,000 mixed households are
anticipated following HealthMatch implementation.

The purpose of the Health Plan Enrollment Project is to improve customer service and reduce
administrative costs. Key components of this initiative include centralized distribution and
receipt of enrollment packets, data entry, and a Help Desk to answer questions on enrollment and
process enrollments over the telephone. This will reduce duplication, decrease current postage
costs, and simplify the enrollment process for a significant sector of the MHCP population.

The Centralized Health Plan Enrollment project is currently in the planning phase.
SOW Attachment B – Health Care Automation Request
                For Proposal




                 State of Minnesota
         Department of Human Services (DHS)


            Health Care Operations division
                Request For Proposal
                        For an
     Automated Solution for Eligibility and Access to
       Minnesota Health Care Programs (MHCP)
         (The Health Care Automation project)




                      May 20, 2002
                                                               Table of Contents
1       PROJECT INFORMATION ............................................................................................................................1
    1.1 INTRODUCTION ................................................................................................................................................1
       1.1.1   Conditions for RFP and Proposal .........................................................................................................1
       1.1.2   Procurement ..........................................................................................................................................1
    1.2 BACKGROUND ..................................................................................................................................................2
       1.2.1   Major Milestones ...................................................................................................................................3
    1.3 VISION .............................................................................................................................................................3
       1.3.1   Business Vision ......................................................................................................................................3
       1.3.2   Technical Vision ....................................................................................................................................4
    1.4 GOAL ...............................................................................................................................................................4
    1.5 OBJECTIVES AND DELIVERABLES .....................................................................................................................5
       1.5.1   Business Objectives................................................................................................................................5
       1.5.2   Technical Objectives..............................................................................................................................5
       1.5.3   Key Project Deliverables .......................................................................................................................5
    1.6 CONCEPTUAL OVERVIEW .................................................................................................................................6
    1.7 SCOPE ..............................................................................................................................................................6
       1.7.1   Items in Scope ........................................................................................................................................6
       1.7.2   Items Excluded from Scope....................................................................................................................7
    1.8 CRITICAL SUCCESS FACTORS ...........................................................................................................................9
    1.9 PROJECT APPROACH ......................................................................................................................................10
       1.9.1   Organization and Structure .................................................................................................................10
       1.9.2   Shared Commitment Design and Development....................................................................................11
       1.9.3   Project Management............................................................................................................................11
       1.9.4   Methodology and system deliverables .................................................................................................12
    1.10     PROJECT ORGANIZATION...........................................................................................................................13
       1.10.1 Project Roles and Responsibilities.......................................................................................................13
       1.10.2 Other Functions ...................................................................................................................................16
    1.11     RULES OF ENGAGEMENT ...........................................................................................................................17
       1.11.1 Software Solution, Ownership, and Licensing .....................................................................................17
       1.11.2 System Documentation.........................................................................................................................17
       1.11.3 System Deliverables.............................................................................................................................17
       1.11.4 Contract Term......................................................................................................................................11
       1.11.5 Contract Pricing ..................................................................................................................................11
       1.11.6 Online Reference Document Library ......................................................................................................11
    1.12     PROJECT ASSUMPTIONS AND CONSIDERATIONS ........................................................................................11
       1.12.1 Assumptions .........................................................................................................................................11
       1.12.2 Considerations.....................................................................................................................................19
2       PROJECT REQUIREMENTS .......................................................................................................................20
    2.1 BUSINESS REQUIREMENTS .............................................................................................................................20
       2.1.1 Business Processes ..............................................................................................................................20
       2.1.2 Multiple Languages .............................................................................................................................21
       2.1.3 Cost Allocation ....................................................................................................................................21
       2.1.4 Additional Analysis ..............................................................................................................................21
    2.2 TECHNICAL REQUIREMENTS ..........................................................................................................................21
       2.2.1 Capabilities..........................................................................................................................................21
       2.2.2 Design Standards.................................................................................................................................21
       2.2.3 Response Times....................................................................................................................................22
       2.2.4 Users....................................................................................................................................................22
       2.2.5 Multiple Character Sets .......................................................................................................................22
                                                               Table of Contents


                                                                                     i
       2.2.6  User Interaction...................................................................................................................................22
       2.2.7  Enhancements ......................................................................................................................................22
       2.2.8  Operating Environments......................................................................................................................22
       2.2.9  Usability Testing..................................................................................................................................22
       2.2.10 Electronic Signatures...........................................................................................................................22
    2.3 INTERFACE REQUIREMENTS ...........................................................................................................................23
    2.4 SECURITY REQUIREMENTS .............................................................................................................................24
3       RFP RESPONSE REQUIREMENTS ............................................................................................................25
    3.1 PROCESS REQUIREMENTS ...............................................................................................................................25
       3.1.1  Proposer Qualifications.......................................................................................................................25
       3.1.2  Proposal Qualifications.......................................................................................................................25
    3.2 GUIDELINES ...................................................................................................................................................26
    3.3 LEGAL REQUIREMENTS ..................................................................................................................................26
       3.3.1  Contract ...............................................................................................................................................26
       3.3.2  Affirmative Action................................................................................................................................26
       3.3.3  Workers Compensation........................................................................................................................27
       3.3.4  Availability Offered and State Employees ...........................................................................................27
       3.3.5  Organizational Conflict of Interest ......................................................................................................27
       3.3.6  Lobbying Restrictions ..........................................................................................................................27
       3.3.7  Vendor Cancellation ............................................................................................................................27
       3.3.8  State Cancellation................................................................................................................................27
       3.3.9  Debarment ...........................................................................................................................................27
       3.3.10 Certification.........................................................................................................................................27
    3.4 INSURANCE REQUIREMENTS ..........................................................................................................................28
    3.5 PROPOSAL SUBMISSION INSTRUCTIONS..........................................................................................................29
       3.5.1  Form and Format ................................................................................................................................29
       3.5.2  Mailing Instructions.............................................................................................................................31
       3.5.3  Proposal Withdrawal...........................................................................................................................32
       3.5.4  Submission Address and Schedule .......................................................................................................32
       3.5.5  Communication Between DHS and Vendors Prior to Selection ..........................................................32
       3.5.6  Proposer Conference ...........................................................................................................................32
       3.5.7  Questions .............................................................................................................................................33
       3.5.8  Timelines..............................................................................................................................................33
       3.5.9  Online Reference Document Library ...................................................................................................33
4       SELECTION PROCESS .................................................................................................................................34
    4.1 EVALUATION AND SELECTION .......................................................................................................................34
       4.1.1 Rules ....................................................................................................................................................34
       4.1.2 Process.................................................................................................................................................35
5       APPENDICES ..................................................................................................................................................36
    5.1     APPENDIX A: TECHNICAL SERVICES CONTRACT ............................................................................................37
    5.2     APPENDIX B: AFFIRMATIVE ACTION DATA PAGES ........................................................................................48
    5.3     APPENDIX C: ASSURANCES AND AGREEMENTS .............................................................................................51
    5.4     APPENDIX D: MAJOR PROGRAMS/ELIGIBILITY TYPES FOR HEALTH CARE AUTOMATION ..............................52
    5.5     APPENDIX E: BUSINESS REQUIREMENTS ........................................................................................................54
    5.6     APPENDIX F: DHS TECHNOLOGY AND SYSTEMS ...........................................................................................72
    5.7     APPENDIX G: LEGACY SYSTEM INTERFACE REQUIREMENTS .........................................................................74
    5.8     APPENDIX H: HEALTH CARE AUTOMATION WORK GROUP DESCRIPTIONS ....................................................77
    5.9     APPENDIX I: CAPABILITY MATURITY MODEL FOR SOFTWARE .......................................................................78
    5.10      APPENDIX J: DHS ONLINE REFERENCE DOCUMENT LIBRARY ..................................................................80




                                                                                   ii
                                         Health Care Automation RFP



Project Information

Introduction
The State of Minnesota through its Department of Human Services (hereafter “State,” “DHS” or “Department”) is
seeking professional and technical services to contract for the design and construction of an automated eligibility
system for the State of Minnesota’s health care programs (DHS-administered “Minnesota Health Care Programs” or
MHCP). DHS’ end vision is to build a custom system for the automation of health care program eligibility
including: information assistance, information referral, data collection, eligibility determination, case maintenance,
case retention, and other business operations within the DHS computing architecture.

Conditions for RFP and Proposal
    While it is the STATE’s intent to enter into a contract with a qualified responder for the
    provision of the professional and technical services set forth herein, this RFP does not
    obligate the STATE to complete the RFP process or to enter into a contract. The STATE
    reserves the right to cancel this RFP at any time and for any reason. Responders (or
    alternatively “Proposers”) to this RFP assume all risks and costs associated with the
    submission of their proposals.
    DHS’s Health Care Operations division will utilize any contract executed by the STATE as a
    result of this RFP.
    The purpose of this RFP is to contract for professional and technical consulting services with
    a qualified vendor to design and construct a health care eligibility system. This system will
    be a component of the Medicaid Management Information System (MMIS) and is one part of
    a comprehensive effort to automate health care eligibility determination. The effort and
    product encompassed by this RFP will be in addition to related work being performed and
    managed by state staff, to include interfaces, legacy system changes, and other components
    to enhance the delivery of Minnesota Health Care Programs. The latter functions, to be
    accomplished primarily by state staff, are separately budgeted.
    The portion of the project associated with design and construction of a health care eligibility
    system, to include hardware, software, state staff (dedicated to this phase of the overall
    project) and the technical development contract may not exceed $20 million. This RFP, for a
    qualified vendor, is anticipated to be a majority of that amount; however, this will be a value-
    based procurement. DHS is encouraging proposers to be creative, and will evaluate multiple
    proposals from individual vendors if they are submitted under separate covers and comply
    with all the proposal requirements contained in this RFP.
    Response to this RFP does not preclude any successful vendor awarded this contract from
    submitting proposals on subsequent phases of the overall Health Care Automation project.

Procurement
The procurement process for this RFP will be conducted in accordance with the federal regulations contained or
listed in the Assurances and Agreements appendix of this RFP, as well as applicable procurement policies and
procedures established by the State of Minnesota including Chapter 16C.




                                                          1
                                         Health Care Automation RFP


Background
DHS is the State’s largest Executive branch agency with primary responsibility for developing policy and
administering State human service programs such as cash and food assistance, health care, and services for the
elderly and disabled. The Department serves over 525,000 citizens with various Minnesota Health Care Programs
(MHCP) including Medical Assistance (MA), General Assistance Medical Care (GAMC), and MinnesotaCare.
Eligibility determination and case management for these programs is decentralized over 87 distinct county
governments, tribal governments, central DHS case-processing facilities, and other business partners. Decentralized
administration, complex programs, complicated eligibility requirements, frequent case transfers between entities,
and the ever-changing health care environment have resulted in high customer confusion with the process, task
duplication for workers, and reduced utilization of services and enrollee retention.
Currently, DHS uses two large mainframe computer systems to assist with eligibility determination and information
retention for various benefit programs: MAXIS, Minnesota’s Family Assistance Management Information System,
(or “FAMIS”) and the Medicaid Management Information System (MMIS). Neither MAXIS nor MMIS were
designed specifically for health care eligibility functions, resulting in the use of different systems for different
programs, duplicate data entry, and a largely manual, paper-based, eligibility determination process. This is in large
part due to these systems’ focus on other department business and the complexity of health care programs and
eligibility policy. While both MAXIS and MMIS have some functionality related to health care eligibility, neither
has ever held full responsibility for eligibility determination.
Numerous federal mandates and funding sources impact these systems. The U.S. Department of Agriculture requires
all states to operate a FAMIS for the Food Stamp program. MAXIS, Minnesota’s FAMIS, was developed in the late
1980s based on South Dakota’s FAMIS, with an expanded scope to include both the cash program – at that time,
Aid to Families with Dependent Children (AFDC), and the eligibility determination for Food Stamps. In addition to
the USDA mandates, the federal Department of Health and Human Services (HHS) Administration for Children and
Families (ACF) certifies each state’s automated cash system, and the HHS Centers for Medicare and Medicaid
Services (CMS) has a separate set of mandates and certification requirements for Medicaid.
MAXIS was the State’s first attempt at standardizing eligibility processes across the state’s 87 counties and tribal
governments. More than 2000 local Financial Workers are the primary users of MAXIS, and many are responsible
for determining eligibility for all public programs – cash, food stamps and health care. During MAXIS development,
Minnesota’s county leaders were concerned that DHS was requiring their staff to learn the new MAXIS system for
cash and Food Stamp eligibility while using another set of manual processes for the health care program eligibility.
Therefore, shortly before statewide implementation of MAXIS in 1990, a decision was made to add some health
care program eligibility functionality to the system as a means to automate some manual functions. However, due to
technical constraints, only a portion of the health care eligibility processes could be included on MAXIS. Health
care policies are often more complex than cash and Food Stamp policies and use different eligibility criteria, budget
determinations, income standards and asset guidelines for each individual member of a household. Health care
policies also change frequently as a result of new state and federal legislation. Sometimes these changes have been
incorporated into the automated system over the years, but many eligibility determinations have continued to require
manual calculation on the part of a financial worker. While a project to rewrite MAXIS health care functionality is
being installed this Memorial Day weekend that will automate some health care eligibility processes within MAXIS,
the financial worker is still required to enter duplicate information into MMIS in order to ensure the proper payment
of claims after eligibility is confirmed. The MAXIS health care rewrite is only a step toward more comprehensive
automated health care processes that will be achieved through this overall Health Care Automation project.
In addition to the federal mandates for a FAMIS system, each state is mandated by CMS to run a MMIS for the
payment of Medicaid claims. Minnesota’s MMIS is the largest claims payment system in Minnesota and one of the
largest in the country, and more than 525,000 Minnesotans currently receive services paid through the MMIS. DHS
health care claims examiners use MMIS to ensure that approximately four billion dollars in annual claims are paid to
the system users – the more than 35,000 providers of health care services. Secondary users include county workers.
At the time that both MAXIS and the current MMIS were developed, fewer health care programs were in existence,
and rules were significantly simpler. Since implementation of the two systems, the Minnesota Legislature has added
many new health care programs, all with different, complex eligibility requirements. Programs now administered by
DHS such as Medical Assistance for Employed People with Disabilities (MA-EPD) and MinnesotaCare, which
currently provides coverage for more than 100,000 individuals, did not exist when either system was developed. At
the same time that the Legislature was adding new state programs, DHS was directed to devote policy and technical
resources toward federal welfare reform efforts to change from the old AFDC program to the new TANF
(Temporary Assistance for Needy Families – our MFIP) program, and modify the legacy systems. This complex set


                                                          2
                                         Health Care Automation RFP


of circumstances has led to the current status of MAXIS and the MMIS. We have now received direction and
approval from both the Legislature and our federal authorities to develop a new, more comprehensive and cost-
effective eligibility system to better address the needs of both Minnesota Health Care Programs recipients and
system users.
In June 2000 the Department engaged KPMG Consulting, LLC to provide professional and technical services to
conduct an alternatives analysis, prepare recommendations and outline a strategy for the automation of health care
eligibility business processing using one Minnesota Health Care Program (MinnesotaCare) as a prototype. In April
2001 the Department also contracted with an independent vendor to make recommendations to redesign the
MinnesotaCare Operations business process. DHS is now developing the project plan to implement those business
process and redesign recommendations. The State is in the planning stages of a similar business process study for
the entire statewide health care eligibility and access process. The selected contractor for the Health Care
Automation project would be expected to use the deliverables from these projects as the basis for the new system
design1.
A project of this scope and size crosses several Department divisions resulting in a cross-functional team
representing technology systems, policy, training, outreach, user groups, and others. DHS is currently exploring the
trademark process in order to name this Health Care Automation technology.

Major Milestones
                                                                       Event
                            ate
    June 2000                      KPMG engaged to complete an automation analysis for MinnesotaCare.
    January 2001                   HCA Steering Committee approved final recommendation for project.
    April 2001                     Vendor engaged to redesign MinnesotaCare Ops business process.
    September 2001                 Health Care Operations develops/reviews the initial project RFP, and approves
                                   acceleration of scope to include programs covering Families With Children (see
                                   Appendix D) in the project’s first phase.
    December 2001                  HCA Steering Committee approves the RFP for publication.



Vision
Currently, state and county eligibility workers enter client health care data into multiple DHS systems and must
manually calculate the results. New technology developed for this project will reduce this need to enter data in
duplicate systems. This technology will also automate the existing (and disparate) health care eligibility functions
into a centralized tool. With the new Health Care Automation system, DHS is implementing an industry-wide shift
in health care policy orientation that is evolving from “public health care programs” to state-subsidized health
insurance.

Business Vision
The Department has a long-range vision for health care that is both comprehensive and enrollee-centered. This long-
range vision contains the following elements:
      Delivering greater efficiencies in health care program administration
      Expediting health care program enrollment
      Retaining health care coverage for DHS-administered MHCP enrollees
      Reducing the overall number of Minnesotans without health care insurance
      Providing on-demand access to health care eligibility and enrollment information
      Improving customer service
      Exchanging web-enabled information with business partners and enrollees
1   See the DHS Online Reference Document Library in APPENDIX J.


                                                          3
                                            Health Care Automation RFP


       Reducing language as a barrier to health care enrollment information and eligibility process
       Expanding access to the health care eligibility and enrollment process to enrollees and
       diverse business partners.
The new Health Care Automation system is part of this overall vision, will be a component of the current MMIS,
and should automate health care administration to allow health care eligibility workers to simplify processes, reduce
errors, and spend the majority of their time on qualitative customer care.
DHS wishes to provide customer service that rivals industry best practices while reducing the stigma of being on a
public health care program. The end product should more resemble best practices for insurance industry processes
and systems, and less resemble traditional welfare models. At a minimum, this includes the following best practices:
       Increased assistance to applicants and enrollees with limited English skills. This includes
       increased translated materials on the web, such as online health care applications and
       automatic routing of cases to available case workers who speak the primary language of
       applicants.
       More time for individualized assistance with the application and enrollment process.
       More time to educate on covered benefits, service delivery and other consumer related health
       care topics.
       Immediate access to client data and the eligibility system for authorized persons.
       Secure, electronic, workflow solutions that automatically track, measure, and trigger specific
       case management activities.
       Secure electronic data sharing capabilities that comply with HIPAA and other data practices
       regulations.
       Secure electronic transfer of cases across organizational boundaries.
       Increased capabilities for web-based client self-service.
       Increased capabilities to provide access to the health care process and system for non-
       traditional health care business partners, such as schools and community organizations.

Technical Vision
DHS envisions a system that will be based on an open architecture, yet will leverage the Department’s existing
technology investments. The system will be required to contain interfaces between several other internal and
external department computer systems2. The new Health Care Automation system will be web-enabled and designed
to meet present health care policy and program objectives, and any possible future program objectives. Architecture
must be flexible and scalable to allow DHS to develop efficient outreach and enrollment processes and provide the
highest level of customer service.



Goal
Health Care Automation will create an automated health care eligibility system to provide on-demand access to
health care eligibility and enrollment information and processes.




2   See the Interface Requirements section (2.3)


                                                          4
                                          Health Care Automation RFP


Objectives and Deliverables

Business Objectives
1.   Provide applicants/enrollees and operations staff on-demand access to health care eligibility and enrollment
     information and processes.
2.   Provide the highest level of customer service to support an efficient enrollment and outreach program.
3.   Expedite the eligibility and enrollment process so that the Department is able to make a preliminary eligibility
     determination and communicate to the applicant within 24 hours of receipt of the application. (DHS anticipates
     that the online application will determine presumptive eligibility within 30 seconds.)
4.   Retain eligible enrollees on Minnesota’s Health Care Programs until they are covered by non-subsidized health
     insurance.
5.   Meet health care policy and program objectives now and in the future.
6.   Provide the ability to share eligibility information with counties, tribal governments, and other business partners
     (e.g., providers, plans, school districts, etc.).
7.   Eliminate the need for duplicate data entry across systems.


Technical Objectives
1.   Deliver the business application in an open architecture.
2.   Create a web-enabled client interface.
3.   Build a flexible and scaleable architecture.
4.   Work seamlessly with current DHS systems.
5.   Allow for electronic exchange of information between DHS and its business partners.


Key Project Deliverables
The proposer will provide a complete process and plan to implement all phases of the software solution. The
solution recommendation to meeting key dates may include a phased approach. The following key deliverables must
be met:
     A complete eligibility automation design solution for Minnesota Health Care Programs
     (MHCP).
     Recommendation for implementation which meets key deliverables and deliverable dates.
     Analysis for ongoing costs of operations and support.
     A clear platform decision for Health Care Automation.
     Construction of the system in order to pilot by October 2003.
     Construction of the system in order to complete implementation by April 2004.




                                                           5
                                                Health Care Automation RFP



Key Project Deliverable Dates
A desirable project schedule would provide a working proof of concept by April 2003 and a pilot implementation
software solution by October 2003, to include:
    An identified phased implementation approach;
    Complete implementation plan for all phases by January 2003; and
    Approved pilot to be implemented by October 2003.

The implementation schedule is to be completed for the project by fourth quarter 2003.
Subsequent phases of this Health Care Automation project will include implementation of
additional state health care programs and or processes.
While these dates are considered ideal from a business standpoint, DHS will entertain proposals that can show just
cause for alternative delivery dates.



Conceptual Overview
     S ystem s
                                                                                Existing DHS Technolog y

                                                                 P RISM — child support
                                                                 enforcem ent system                                   M edicaid M anagem ent
                                                                                                                       Inform ation S ystem
           DHS Users                                     M AXIS — eligibility      DHS Data                            (M M IS )—
                                                         system for cash           W arehouse                             Claim s processing
                                                         assistance                                                       Fraud detection
                                                                                                                          Benefit recovery
                                     S ecure Internal                                                                     EDI & M N–ITS
                                                                        S ocial S ervices
                                     W eb Connection                                                                      Health Care Autom ation
                                                                        Inform ation S ystem
                                                                                                                             Eligibility determ ination
          County Users                                                                                                       Case m anagem ent
                                                                                                                             Data capture
                                                                                               Secure Web Connection
                                                                                               (OR pending MN CAFÉ)


                                                                                                                             S ystem s adm inistration
                                                                                                                             Com m on processes

                                        INTERNE T
                                        INTE RNET


             P roviders
                                                                                                                             E xternal S ystem
                                                                                                                                 Interfaces




            Ap plicants/E nrollees                O ther Business P artners




Scope
The above generic model provides a conceptual overview of key concepts of the scope of the Health Care
Automation project. Specifics for proposal consideration are found in the remainder of this document. The project
includes development and implementation of a solution that will address at a minimum Minnesota Health Care
Programs (MHCP) that cover families, children, and adults for Medical Assistance type programs. (See Appendix
D: Major Programs/Eligibility Types for Health Care Automation.)

Items in Scope
    Client Data Collection: Capture eligibility data, provide enrollee access to an online
    application form, provide health plan enrollment selection, and submit application and
    enrollment using current and new technologies that leverage and interface with DHS


                                                                    6
                                        Health Care Automation RFP


    integrated and non-integrated systems. The client data collection component includes
    incorporating the web-based online application system currently in development if feasible.
    Eligibility Calculations: Complete eligibility determinations, eligibility assessment self-
    screenings, enrollee obligation calculations, and reassessments based on revised eligibility
    information.
    Program Management: Add and modify new health care programs to the system as needed.
    Work Flow Functions/Case Management: Track eligibility and enrollee status and changes
    with data sharing among caseworkers and between organizations.
    Enrollee History Data Repository: Provide a secure repository that meets State and Federal
    security rules and regulations for all enrollee eligibility information required for new,
    renewing, and enrolled applicants or eligible enrollees.
    Financial Control: Calculate premiums, generate billings, and support collections and
    account receivables functions with flexibility to add other premium-based health care
    programs.
    Multilingual Enrollee Communication: Provide content and notices in multilingual forms
    and formats.
    Interfaces Between Legacy Applications: Ensure successful interfaces with MMIS and its
    components, and with MAXIS, PRISM (Providing Resources to Ensure Support for
    Minnesotans, the DHS child support enforcement system), SSIS (Social Services Information
    System, a DHS/county child welfare case management system), and other mandated systems.
    (See Appendix G: Legacy System Interface Requirements.)
    Secure Access: Provide secure access capability for enrollee eligibility verification.

Items Excluded from Scope
For this phase of the overall project, items excluded from scope cover eligibility determination for some DHS-
administered Minnesota Health Care Programs (MHCP), including:
    Long-term care
    Home-and-community-based care
    The Prescription drug program, or other waivered and non-waivered programs, such as:
     —Chemical Dependency            —MCSHN (MDH)
     —Insurance Extension            —Others
    Provider-related interfaces, provider payments, and other claim payments.
    Person Master Index (PMI) number management (this will remain in MAXIS)
    Business process redesign in preparation for technology development (See Background, 1.2)
    Management of redesigns internal to affected systems
    Changes in DHS legacy systems to accommodate Health Care Automation design. (These
    changes will be made by DHS staff as this project develops)




                                                         7
                                          Health Care Automation RFP


Critical Success Factors
The proposal solution and project deliverables must, at a minimum, address the project’s critical success factors
listed below. Failure to address these factors may result in the disqualification of the proposal. The following list is
in no particular order of priority.
    Immediate access to health care related information requested by the appropriate resource in
    the Department, a county, tribal government, health care provider, or by a MHCP
    applicant/enrollee. This access includes requests for information from persons with limited
    English skills.
    Eligibility determination within 30 seconds of data entry. This could include online
    application with preliminary determination (pending receipt of verifications or other required
    information), and worker-entered information for final eligibility determination.
    System-generated enrollee notification within 24 hours of eligibility determination.
    Seamless electronic transfer of cases and referrals between workers and across organizations
    (DHS, counties, tribal governments, private outreach organizations, and other public
    assistance offices), and secure communication between workers.
    A client self-service health care site on the web with at least the following features:
    —Program self-screening
    —Online application
    —Communication with workers (DHS, county, tribal government, etc.)
    —Health plan selection
    —Premium payments (electronic funds transfer and credit card)
    —Health care notices and statements containing information on eligibility status
    —Benefits
    —Other account information
    Customer communications, whether via the web, mail or phone, in the client’s language of
    choice. DHS supported languages include: Arabic, English, Hmong, Khmer, Laotian, Oromo,
    Russian, Serbo-Croatian, Somali, Spanish, and Vietnamese. The system should support the
    ability to add other languages in the future.
    Compliance with electronic government service requirements in all terms including data
    privacy for the Health Insurance Portability and Accountability Act (HIPAA) and other data
    practices statutes, the Minnesota Government Data Practices Act, and compliance with the
    state Office of Technology and the Department’s IT system architecture.
    Compliance with system and policy guidelines of the Centers for Medicare and Medicaid
    Services (CMS).
    Support of frequent changes in programs and eligibility policy, including legislative
    mandates. Program/policy changes must be able to be implemented within several weeks
    versus the current standard of several months.
    Flexibility to enable the subject matter experts to make program and policy changes on the
    system with the understanding that major large-scale, program additions or enhancements
    may require technical support or assistance.




                                                            9
                                        Health Care Automation RFP


    The ability of state technical staff to perform ongoing system maintenance and development
    upon implementation of the software. This is based on ongoing knowledge transfer between
    contracted and state staff throughout the duration of the project.
    A 24 by 7 by 365 availability basis except where system maintenance is required.
    Seamless system interfaces to the user when crossing multiple platforms.
    Interoperability of the framework, tools, infrastructure, architecture, connectivity, and
    integration of Health Care Automation system with existing and developing applications and
    interfaces.
    A proof of concept application ready by April 2003 to present to legislative leaders.

It is at the Department’s discretion to determine whether the proposal sufficiently addresses the
critical success factors. In addition to addressing the above key success factors, each proposal
must contain a thorough work plan, proposed schedule, and discussion of project management
practices. (See the Rules of Engagement section, 1.11. and the Proposal Submission Instructions,
Section 3.5).

Project Approach

Organization and Structure
The Health Care Automation project has been developed by the following DHS business units: Health Care
Eligibility and Access (HCEA), Health Care Operations (HCO), Information and Technology Strategies (ITS), and
other related system and program areas. DHS will make Department staff members available to the contractor as
needed to participate in requirement review, gap analysis and design sessions to answer questions regarding policy
and procedures.
The project organization reports to a management-level steering committee and coordinates through a Project
Director and a Project Manager in HCO. The project management methodology used by the State and DHS is taken
from the Project Management Book of Knowledge (PMBOK). As such, the Project Management Methodology
includes procedures, standards, and reporting requirements required to meet best practices of quality assurance
standards, particularly in relation to customer and business requirements. A Capability Maturity Model for
application development will be followed. The Health Care Automation project will follow the elements of project
management required to meet a Level Two status of project management standards and quality assurance metrics in
the model. (See Appendix I: Capability Maturity Model for Software.)
The Project Director will monitor progress of all tasks and subtasks against the work plan/task schedule submitted
by the contractor, as follows:
    The contractor shall maintain and update the work plan/task schedule on a monthly basis to
    reflect completion status and dates.
    Prior to the start of each project phase, the contractor will be required to submit a detailed
    work plan for the phase and a general work plan for subsequent phases.
    Approval of these work plans will be required as a part of the approval to proceed with
    subsequent phases.
    The Department must approve the work product of each phase prior to initiation of the next
    phase. “Approval” is defined as approval of phase-specific deliverables by both the project
    team and steering committee.
    The contractor must be prepared to make status/deliverable presentations to the project team
    and steering committee that minimally cover: project status, issues, changes, decision points,


                                                        10
                                         Health Care Automation RFP


    risk management, work plan, time-lines for subsequent phases, and product demonstrations
    (proof of concept, prototype, or test environment).
    The contractor shall provide an ongoing automated issue-tracking and control system which
    will supply DHS with timely information as to the priority and status of issues, changes and
    modifications. This issue-tracking and control system must be operational within twenty-five
    days after contractor starts work.
    Project changes impacting time, money, scope, deliverables, or the delivery schedule of
    deliverables must be presented to the steering committee for approval. Minor changes (such
    as test plans or coding updates) must be communicated to the project work groups but can be
    decided at the project level.
    The contractor shall follow a software development migration process with the following
    libraries:
    1.   Developers
    2.   Regression testing
    3.   Certification/pre-install
    4.   Production
    5.   Training
    6.   Lab
    A Vendor Project Lead must be designated to work with the DHS Project Director, Project
    Manager and other project leads to coordinate other integration and technical efforts required
    for implementing the solution.

Shared Commitment Design and Development
The design and development of this project must be a shared-commitment cooperative effort toward a common goal
between DHS project staff and contractor staff. Contractor staff will be co-located with state technical staff and
functional (business) analysts in a development environment. In some instances the work being done by state and
contractor staff will be on parallel tracks, connecting at various points along the way. However, in most instances
the contractor staff and state staff will work together to develop software solutions which satisfy each deliverable.
This team approach consisting of contractor and state staff is absolutely necessary to guarantee a smooth takeover of
a quality production system that is easily maintained. Contractor staff will be encouraged to bring forth ideas. DHS
project staff will be encouraged to provide maximum support and information in order for the Contractor to do the
best job possible. At the same time, state staff needs to be concerned with system takeover at some future date and
need a quality system that is easily maintained. During the development of the detailed project plan with the vendor,
we will build into that plan teams and assignments that ensure cooperative work between state and contractor staff.
In order to achieve true knowledge transfer of a system, there must be shared commitment and state staff will be
freed up from their current assignments and dedicated to the effort along with contractor staff. In order to prevent a
long-term dependence on contractor staff, state staff will be assigned and involved with the software development
effort.
Vendors responding to the RFP are encouraged to devote a portion of their proposal to comment on their
commitment to quality, and identify procedures or standards they have used in the past to promote quality, and their
proposal for a cooperative effort on this project in particular that will ensure a quality system.

Project Management
DHS will have an independent (e.g., non-state, different vendor) Project Manager or coordinator (PM) assigned to
the overall project whose responsibility will be to track all components of the project (which may include but are not
limited to cost, schedule, and functionality), including those components of the vendor. The respondent will be
required to perform project management for the entire effort identified within this document. In addition, the


                                                         11
                                       Health Care Automation RFP


Department intends to competitively procure an Independent Validation and Verification (IV&V) contractor to
adequately monitor the development and implementation of the Health Care Automation system.

Methodology and system deliverables
The methodology employed by the vendor will result in a number of system deliverables and system documentation
(these are described in 1.11 Rules of Engagement). The methodology and approach to the technical solution for the
Health Care Automation system should follow industry best practices for software development. This methodology
shall be employed at all phases of the project and should include the following phases:
              Business Design
             Technical Design (includes database design and data modeling)
             Software Build
             Testing
             Training
             System Documentation
             Implementation and Rollout
             System Acceptance and Closure




                                                       12
                                         Health Care Automation RFP



       Project Organization
Resources required to complete this project will be solicited from DHS business and technical divisions. Overall the
Project Director (through the Project Manager) will direct coordination and control of all projects related to the
Health Care Automation project.




 HCA Steering Committee                 HCA Project Director




                                        HCA Project Manager




           Business Project                   Vendor                    Technical Project
                Leads                       Project Lead                     Leads




                HCEA                          Vendor                         MMIS
            Business Staff               Development Staff                Development
                                                                             Staff
                                            Core Project Team
                                                                            MAXIS Resource

                                                                               Other Resources



Project Roles and Responsibilities
Health Care Automation Steering Committee
DHS has organized a project steering committee to manage the project, provide management direction and enable
the project organization to succeed by allocating resources as needed. The steering committee has overall
responsibility for the success of the project, as follows:
    Approve changes to the project scope.
    Allocate resources to support changes impacting time, money, and quality.
    Periodically review the project status with the Project Director.
    Approve changes to the work schedule and plan as they impact outcomes.
    Manage inter-organizational resource conflicts and balance organizational needs with those
    of the project.

Health Care Automation Project Director
The Department has assigned a full-time Project Director to provide overall project direction and to act as the
contractor’s primary liaison to work with other Department staff and other state departments. The position also
coordinates the approval of scope and plan changes with the steering committee. Other responsibilities of the Project
Director are to:
    Manage all phases of the Health Care Automation project.


                                                           13
                                         Health Care Automation RFP


    Manage funding and budgeting.
    Identify related and dependent applications, interfaces and connectivity.
    Coordinate with the DHS ITS Projects Management Office to assure integration with related
    DHS and state technology projects.
    Oversee development of a project plan with regular and specific checkpoints for reporting
    and quality assurance.
    Report to the steering committee and Health Care Operations division director.
    Facilitate the work of the project workgroups.
    Provide project leadership.
    Manage the work of the contracted Project Manager.

Project Manager (contractor)
The Department is engaging the services of a contracted Project Manager to act as overall project manager for
Health Care Automation. The Health Care Automation Project Manger will develop an overall project plan and
coordinate vendor, business, and technical resources. This position supports the Project Director and manages the
master project plan. The master project plan integrates the business plan with other intersecting project plans within
DHS. The position supports the coordination of other department tasks and activities required for completion of the
Health Care Automation project. This position will monitor progress of the vendor’s project plan. Other
responsibilities of the Project Manger are to:
    Report to the DHS Project Director.
    Develop, manage and coordinate the overall project plan and manage all aspects of its
    implementation.
    Manage all project deliverables.
    Maintain project scope.
    Gain commitments from project teams and ensure that responsibilities are carried out.
    Manage staff, provide training and assign allocated resources.
    Maintain project timelines and ensure that tasks are performed on schedule.
    Manage and approve change requests.
    Manage and address issues.
    Recommend technology approaches and make decisions regarding technology.
    Develop a risk mitigation plan and manage risk for the duration of the project.
    Develop and implement a quality assurance plan.
    Regularly report to the Health Care Automation Project Director, the Director of Health Care
    Operations, and the steering committee as requested.
    Manage and regularly report on cost estimate variations and deviation from schedule.
    Close out the project.

Project Leader (contractor, part of this vendor team)
The contractor awarded this contract will be expected to provide a Project Leader for all resources provided by the
contractor. The Contractor Project Leader will be required to perform all standard project management tasks



                                                          14
                                         Health Care Automation RFP


associated with good project management, and will be responsible for project plans, statuses, issue management,
change management, and other types of tasks associated with project management. The Contractor Project Leader
will have responsibility for all tasks identified within the Health Care Automation project including; the analysis,
design, construction, testing, and implementation activities required to develop the software solution. Within the
context of the project, the Contractor Project Leader will:
    Report to the Health Care Automation Project Manager.
    Be assigned 100 percent to this project.
    Be responsible for developing, managing and coordinating the vendor project plan.
    Manage all related project deliverables.
    Maintain project scope.
    Develop a detailed project plan and manage all aspects of its implementation.
    Gain commitments from project staff and ensure that responsibilities are carried out.
    Manage contractor staff, provide training, and assign allocated resources.
    Maintain project timelines and ensure that tasks are performed on schedule.
    Manage the approval of change requests.
    Manage and address project-related issues.
    Develop a technology approach and make recommendations regarding technology.
    Develop risk mitigation plan and manage risk for the duration of the project.
    Develop test and acceptance plans.
    Manage and regularly report on cost estimate variations and deviation from the schedule.
    Close out the project.

Workgroup Leads—DHS Business
DHS will designate staff members to act as Workgroup Leads for business resources. Workgroup Leads will provide
resources and identify tasks related to activities identified in the project and develop effort estimates. Workgroup
Leads will:
    Report to DHS HCEA/Electronic Government Services (EGS) Business Manager with
    project responsibility to the Project Manager.
    Chair business policy and process work groups.
    Develop/coordinate business requirements and testing project plans with DHS Project
    Manager.
    Assign/manage DHS resources to support the project.
    Coordinate DHS resources, tasks, and deliverables with the DHS Project Manager.
    Develop test and acceptance criteria.

Workgroup Leads—DHS Technical
DHS will assign staff members to act as Technical Workgroup Leads for their respective technical areas and serve
as resources within that area. The Workgroup Project Leads will coordinate interfaces to the DHS legacy systems
and will:
    Provide project plans for the integration effort.



                                                          15
                                         Health Care Automation RFP


    Develop effort estimates.
    Assign project resources to support the Health Care Automation project.
    Submit project plans to the Project Manager.
    Develop technology approaches and make decisions regarding technology.

Other Functions
Quality Management
The Department intends to competitively procure a Quality Assurance (QA) or Independent Validation and
Verification (IV&V) contractor to adequately monitor the development and implementation of the Health Care
Automation system. The level of quality of the Health Care Automation project is determined by the extent to which
the system performs, supports all of the functions specified, and meets the requirements of the RFP and meets the
needs of all of its users. Throughout the development process, the Department will require the contractor to conduct
formal walk-throughs of processes, system components and deliverables. In addition, the Department will conduct a
rigorous acceptance test of each component prior to the implementation task, and require prototypes and adequate
time in the project plan to include focus groups, alpha testing, and other means of stakeholder feedback.

Technical Communication Management
The proposer will develop a technical communication plan at the project initiation to cover status reporting, change
management notification, change approvals, general updates, plan changes, and other required state and federal
reporting. A communication matrix will be used to identify methods, notifications, and distribution of
communications.

Change Management Requirements
DHS expects to incorporate a formal change management process with review, approval, and escalation resolution
processes into the change process for this project. Changes initiated by the Legislature during the course of the
project will be handled utilizing change management principles. Decisions made will incorporate change
management as the project moves from the pilot phase into full implementation. Furthermore, the lessons learned
during the planning, development and implementation of Health Care Automation will be documented.




                                                         16
                                         Health Care Automation RFP



          Rules of Engagement
This section discusses the project deliverables, and includes rules and agreements required to be compliant with the
Health Insurance Portability and Accountability Act of 1996 (HIPAA). (Refer to Appendix C: Assurances and
Agreements.)

Software Solution, Ownership, and Licensing
All project deliverables are the property of the State of Minnesota. The system to be delivered, developed and
implemented will be 100% owned by the STATE.
System ownership shall consist of all object code, run time code, including but not limited to high priority level
source codes, applications framework (except third party software), low level and custom-computed source code,
data maps and structures, linkage command and operation command files, reference manuals, operations manuals,
and any other system-associated documentation used or produced by the contractor to design, develop, and
implement the system.
Any and all off the shelf (OTS) or-third party software components must be licensed to the STATE or if the
Contractor is a licensed reseller, the Contractor must show proof of licensure capability for any and all software
included in the software solution provided to the STATE as part of this contract.

System Documentation
System documentation is to include data flow diagrams, functional narratives, detailed processing and edit-logic,
input and output layouts, and data dictionary. Furthermore:
1. Documentation including all implementation phase deliverables and resulting system documentation (e.g., user
    documentation, operational procedures, etc.) shall be provided in hard copy and in electronic format using DHS
    standard software tools (i.e., Microsoft Office Suite and Visio for flow diagrams) for publication on the MMIS
    documentation site on the DHS Intranet.
2.   Documentation needs to include narrative text, flow diagrams, flow narratives, screen prints, reports, and tables,
     when applicable, and other document types (example: letters) if needed. The electronic versions of the
     documentation shall be accessible to users on-line through the DHS Intranet.

The documentation needs to conform to existing HCO standards. Browse and search capabilities,
using hypertext markup language (HTML), must be provided to permit users to easily locate
specific information in the documentation. Current system documentation publication processes
use Microsoft FrontPage 2002 or 2000 and MS Visual Source Safe.

System Deliverables
The vendor who is awarded this contract will be expected to produce the following deliverables:
1) Project Protocol Document
     a)   Work Plan and Schedule
     b) Detailed Implementation Plan
     c)   Issue Tracking Log
     d) Change Control Procedures
     e)   Risk Management Log
     f)   Status reports and presentations scheduled according to the work plan
2) Design Session Documentation
     a)   Business Design Document with Approval
     b) Technical Design Document with Approval, to include:
          i)   Client data collection                                    ii) Eligibility determination engine



                                                          17
                                         Health Care Automation RFP


         iii) Case management                                            vi) System administration design
         iv) Financial Control                                           vii) Database design
         v)   Common processes design
    c)   Technical Design Document with Approval; to include:
              (1) Recipient and Financial Control component analysis and recommendation
              (2) Cost and time estimates
    d) Conversion and Interface Design Document with Approval
3) Build Phase: Software solution, including proof of concept and prototypes, when requested
4) Test Plans Executed and Approved
    a)   Requirements Test Plan                                     d) User Acceptance Test Plan
    b) System Test Plan                                          e) Application Software Solution Tested and
                                                                      Accepted
   c) Functional Test plan
5) Transfer of knowledge to state staff, including documentation and formal training,
   if necessary
    a)   Business and Technical User Guides
    b) Operations documentation
    c)   Other
6) Project closure documents and related acceptance and sign off agreements


Contract Term
The Contract term shall begin August 15, 2002, or the date it is executed by the State, whichever occurs later. The
term of this contract shall continue through April 2004, or until all services have been provided, whichever occurs
first.
DHS also intends to seek a post production warranty period of 12 months. DHS will negotiate the warranty period
duration and requirements.

Contract Pricing
The State will pay the Contractor on a fixed-price basis. Proposers must provide only the total price they will require
to complete the project deliverables set forth in their proposals, including all anticipated travel and other costs.
                      1.11.6 Online Reference Document Library
An Online Reference Document Library has been established in a secure section of the DHS website. The contents
of the library are listed in Appendix J. Public documents related to DHS and this project will be available for
reference.

         Project Assumptions and Considerations

Assumptions
DHS will have a majority of the detailed analysis business requirements completed prior to approval of this contract.
The vendor will be required to do a gap analysis on these requirements prior to the beginning of the design phase.
The KPMG documents located in the Online Reference Document Library (Appendix J) are provided as additional
information for review, but the documents were developed for the MinnesotaCare program only. Although there are
parallel processes between MinnesotaCare and other DHS health care programs, a direct correlation can only be
made with a detailed analysis of the other programs and any correlation made is based on assumption and
speculation.




                                                          11
                                        Health Care Automation RFP


Considerations
Based on the DHS strategic planning and technology direction, the following areas need to be considered within the
proposed solutions:
    Public access via the Internet to include electronic signature capability
    Integration with other state systems for information collaboration
    County and local government infrastructure
    Complete migration of other health care programs in future projects

Also, please consider the following when responding to the RFP:
    DHS will handle required MAXIS and MMIS changes outside of this process. The contractor
    must define the requirements and provide a design detail for the interface/integration.
    DHS staff continues to document lower-level interface requirements. (See Section 2.3.)
    Until all phases of automation are complete, MAXIS will still have other segments of Health
    Care programs running, such as programs for the aged and disabled. Any changes to the
    MAXIS system need to ensure that the programs still work and capture the required data for
    processing.
    Health care programs not included in the first phase of the implementation will remain in
    MAXIS and MMIS.
    Other system exclusions include claims processing and payments to providers.




                                                        19
                                           Health Care Automation RFP



Project Requirements
This section provides the highest level of requirements and processes that identify what the DHS organization
desires in their business solution. (More detail can be found in Appendix E.)

Business Requirements

Business Processes
There are eight high-level business processes that the new system must support:
1. Data Collection – The assembling of enrollee data. Data collection includes the client data captured through the
    on-line application.
2.   Application – The completion of an application for Minnesota Health Care Programs (MHCP). This can occur
     using manual or electronic forms. For an enrollee using the Internet-based process, a preliminary eligibility
     determination feature must be available. A registration process will occur for applications completed via the
     Internet.
3.   Intake – The determination of whether or not an enrollee already exists within the system. New enrollees will be
     added to the system. The information for existing enrollees is validated and existing benefits identified.
4.   Eligibility Determination – A complicated, rules-based process used to examine all factors associated with an
     enrollee and identify all programs for which the enrollee is eligible. This process will also determine enrollee
     financial obligation for each program. All programs will be presented with the most advantageous coverage
     listed first. The ability to enroll in a managed care plan will be available. Eligibility coverage can be retroactive.
5.   Processing Health Care Coverage – The implementation of health care coverage. Includes coverage disposition,
     enrollee notifications, renewals, appeals, interim changes, enrollee reporting requirements and re-determination.
     Also includes periodic system-based processes that don’t require worker intervention.
6.   General Workflow – The process used by a county or state worker to manage their workflow. Includes the need
     to store enrollee and case-related notes, to receive system-generated alerts regarding enrollees and cases, to
     receive system-generated reports, to manage cases, and to manage workflow. Also includes the ability to share
     or transfer parts or all of eligibility information between persons within the same organization or across
     organizations.
7.   Reports – The generation of Federal, State and Department reports.
8. Accounts Receivable – The accounting of premium payments for those programs where
   premiums are required. Integrates with eligibility determination process for system
   automated opening and closing based on premium payments and premium due dates.
   Completed daily and monthly billing processes and interfaces seamlessly with a check
   scanner and State-Wide Accounting. Ability to make payments via automatic withdrawal,
   credit cards, EBT, and tax refunds.

More detail on business requirements for these processes are found in Appendix E.




                                                            20
                                         Health Care Automation RFP



Multiple Languages
Each enrollee will be able to choose one of the following languages:
    Arabic                                                          Russian
    English                                                         Serbo-Croatian
    Hmong                                                           Somali
    Khmer (Cambodian)                                               Spanish
    Laotian                                                         Vietnamese
    Oromo

Once a language is chosen, all further official, written communication with that enrollee will be
in the selected language. These language options will also be available for Internet-based
sessions. Once a language is selected, all subsequent screens displayed in that session will use
the selected language. Screens used by state and county workers will be in English. The technical
solution should allow for additional languages to be added in the future.

Cost Allocation
The new system must be able to track all volume transaction activity by programs and by enrollee status. This is
needed to support an allocation of operational costs for the system.

Additional Analysis
During May, June, and July of 2002, additional analysis will be conducted at DHS to document lower-level
requirements, the rules associated with these requirements and any exceptions to these rules. At the same time, a list
of desired fields will also be developed. This information, completed to-date, will be made available to the
successful proposer at the time the contract is awarded. Please note that the data dictionary found in the KPMG
Study document (Task 6) in the DHS Online Reference Document Library was developed to support only the
MinnesotaCare program, and contains approximately ten percent of the total number fields that will be required to
support all Minnesota Health Care Programs.



Technical Requirements

Capabilities
The system must be available 24/7/365 with the exception of required system maintenance. It must be web enabled.

Design Standards
DHS and Americans with Disability Act (ADA) web design standards will be used as guidelines. The Appearance
and Navigation sections of DHS web standards are available through the project’s Online Reference Document
Library. Additional standards that will apply to all State of Minnesota applications are currently being developed
and should be available in the second quarter of 2002.

General DHS web standards for accessibility are as follows:
    Include alternative text tags (alt tags) with all graphic images.
    Do not place red font or images adjacent to green font or images. Users with red-green color
    blindness would be unable to detect the differentiation.



                                                          21
                                         Health Care Automation RFP


    All pages must be fully accessible using keyboard navigation (arrow & tab keys, etc.).

Response Times
The anticipated average response time for Intranet users should be less than one second. Internet-based preliminary
eligibility determinations should be completed within 30 seconds.

Users
There will be both an Intranet and an Internet component. The Intranet will have 500 DHS staff and 2000
county/tribe workers using the system on a full-time basis. The Intranet will also have an unknown number of
business partners using the system on a part-time or sporadic basis. No estimates for the number of public Internet
users are available.

Multiple Character Sets
Data entered in a language other than English will need to be translated and stored in English. A requirement to
present stored data in the language in which it is originally entered is being considered. This could require the
system to store data using multiple character sets. The system must also be ADA compliant.

User Interaction
The desired method of collecting data will be in a question and answer format. The answer to one question will
determine subsequent questions. A context based Help feature will be available for every question.

Enhancements
The system must be designed so that new policies, legislative mandates and rule changes can be implemented within
one month.

Operating Environments
The system should be developed and run in one of the following environments:
    In House – Server based using an operations environment provided by DHS Health Care
    Operations. The in-house solution is a JAVA based front end deployed on a Sun production
    environment. (See Appendix F for additional information)
    Mainframe –IBM mainframe based using an operations environment provided by the State of
    Minnesota InterTechnologies Group.

A major system is currently in development using the “in house” approach. It should be
considered as the preferred environment if the business case study supports an “in house”
decision. Descriptions of DHS technology and core systems are found in Appendix F.

Usability Testing
Usability testing for all Internet screens will be required. Depending on the design of the total solution, DHS
reserves the right to require usability testing for all screens.

Electronic Signatures
The system must be capable of processing electronic signatures in compliance with 21CFR11.




                                                          22
                                         Health Care Automation RFP


Interface Requirements
Interfaces will be needed between the new system and county systems, other DHS systems, other State of Minnesota
systems, Federal systems and health plans. These interfaces might be required for all programs (MA, GAMC, and
MinnesotaCare), some programs, or one program. Interface types will include:
    Obtaining data from another system
    Requesting validation of data by another system
    Passing common data to another system
    Receiving and processing unsolicited data from another system
    Passing data unique to another system that was captured in the new system as part of a
    logical business process.

Please refer to Appendix G for the matrix containing additional details on these interfaces. The
DHS systems that could require interfaces include:
    MAXIS (economic assistance)
    Medicaid Management Information System (MMIS)
    PRISM (child support enforcement)
    Social Services Information System (SSIS, a child welfare case management system)
    EIS/data warehouse
    Document Management (FileNet)
    IVR/CTI
    Wausau (Cashiering)

Other State of Minnesota systems include those at the:
    Department of Children, Families and Learning (DCFL)
    Department of Economic Security (DES).

Interfaces with Federal systems include those at the:
    Social Security Administration (SSA)
    Centers for Medicare and Medicaid Services (CMS, previously HCFA)
    Internal Revenue Service (IRS).

The required frequency of these interfaces may be immediate, daily, weekly, every two weeks,
twice a month, three times a month and monthly. Although most of the data will be transferred
electronically through network connections, some counties may still require that tapes be created
and sent.
The health care eligibility determination features currently existing within MAXIS and MMIS will migrate to the
new eligibility system. A strategy for sharing data required by any two or all three of these systems needs to be
developed. This strategy will determine the internal interfaces needed between these three systems. The successful
proposer will be responsible for leading the development of this data strategy.
The successful proposer will also be responsible for the development of an external interface strategy for these three
systems. Some external interfaces currently handled by MAXIS and MMIS might remain in these systems. Others




                                                          23
                                          Health Care Automation RFP


might migrate to the new system. In some cases, interfaces may remain in the existing system and some may migrate
to the new system. No additional external interfaces are anticipated for MAXIS or MMIS.
Currently, PRISM (the State’s child support enforcement and payment system) does not support an “immediate”
interface. If the external interface strategy identifies this as a need, this new feature will have to be added to PRISM.
Modifications required of MAXIS, MMIS, and PRISM as a result of the previously mentioned strategies will be the
responsibility of DHS teams currently supporting these systems. Development of the external interfaces for the new
system will be the responsibility of the successful proposer. The MAXIS team, the MMIS team, and the successful
proposer will share the responsibility for the development of the internal interfaces.
In addition to the existing interfaces identified in this section, proposers should note that the
Department is currently developing an initiative to examine the need for a Common Access
Front End (CAFE) and/or a State Master Index (SMI) across all DHS systems. It is expected that
the proposer awarded this contract would coordinate automation efforts with the CAFE/SMI
project to facilitate integration of future technologies.


Security Requirements
The successful proposer will be responsible for designing a security feature consistent with industry best practices.
Government health care programs operate under stringent data practices and security requirements. The security
feature must comply with HIPAA requirements, the Minnesota Government Data Practices Act and other applicable
data privacy statutes and regulations. As part of the HIPAA technical project, DHS is re-engineering the firewall
infrastructure to create five network zones (external, replicated database, VPN internal and management) to manage,
control and log the flow of traffic between external customers and internal computing assets.
DHS plans to employ technology for authentication and access within the Health Care Automation project. This
technology has not yet been selected.
DHS technical security is being focused on four main areas; access control, data integrity, activity auditing, and
network monitoring.
1) Access Control - Network access is controlled via a logical separation of network and system
   areas which provides designated areas for various types of activity and various types of
   users/entities.
2) Data Integrity – Provides a logical separation of areas (zones), replicating components (such as data bases), in
   addition to creating rules for conduct within various zones so that due diligence toward preserving data integrity
   is demonstrated.
3) Auditing of Activity - Robust intrusion detection will be integrated within each zone in order to provide an
   enhanced capacity for auditing activity occurring within.
4) Network Monitoring – Systems will be logically separated and monitoring/auditing components put into affect
   to guard the availability of data and systems.




                                                           24
                                         Health Care Automation RFP



RFP Response Requirements
This section defines the general proposal qualifiers, content requirements, and the process required for submitting a
qualified proposal. Specific formats are described in the Proposal Submission Instructions section (3.5).



Process Requirements

Proposer Qualifications
1. Proposer must have demonstrated system design and development success in a web and
   N-tier technology environment.
2.   Proposer must have experience in the design and development of a client or customer identification and tracking
     system.
3.   Proposer must have experience in the design and development of a health care eligibility and case management
     system.
4.   Proposer must have experience in the public and private sector health care industry and have demonstrated
     expertise with HIPAA requirements.
5.   Proposer must have demonstrated skills in managing large scale, multi-phased and integrated systems solutions
     projects.
6.   Proposer must demonstrate the ability to provide qualified, specific staffing resources to complete the design,
     development, and implementation for the project timeframe.
7.   Proposer must demonstrate the ability to provide post-implementation support for a bonding period of a
     minimum of one year.


Proposal Qualifications
All proposals will be expected to address the following requirements to be considered for contract award:
1. Responders must describe their experience and ability to carry out tasks that will arise after a contract is
     awarded. Responders must submit at least two references from similar projects. Responders should describe in
     detail their experience working with health care eligibility determination and Medicaid systems.
2.   Responders must demonstrate experience in development or knowledge of models that include managing data
     and transactions via the Internet. Experience and references are required. Responders must deliver a general
     overview of the proposal in sufficient detail so reviewers of the proposal can determine if the proposal meets the
     goals of the project.
3.   Responders must submit a work plan and schedule that describes how they intend to successfully complete the
     project. The plan should detail the order in which the tasks need to be accomplished; tasks that can be done in
     parallel; required resources and their percentage of time devoted to the project, estimated costs and timeframes
     needed to complete each task.
4.   Responders must provide an outline of their background (company history), financial information for the past
     two years, examples of similar work completed, and a list of proposed personnel assigned to the project that
     details their training and work experience. Responders must provide a specific name of the contractor Project
     Manager. No change in personnel assigned to this project will be permitted without the written approval of the
     State’s Project Director. Key personnel assigned to the project must be located on-site, assigned 100 percent to
     this project, and approved by the State’s project director.
5.   The responder’s business solution must address the critical success factors (CSF) identified in the CSF section
     (1.8).
6.   The proposal must address the project requirements and based on the business solutions, propose how to
     address each area of the project requirements:


                                                          25
                                           Health Care Automation RFP


              •    Business Requirements
              •    Technical Requirements
              •    Interface Requirements
              •    Security Requirements.
7.   The proposer must identify a deployment strategy for each class or segment of the user population.
8.   The proposer must identify what alternative solutions or solution variables the responder can recommend.




Guidelines
Proposers must submit solution(s) that satisfy Department objectives, operational constraints, timelines and budget.
The proposal must contain sufficient explanatory detail to support the proposal.
1.   Alternative proposed solutions that deviate from the outcomes, requirements and features prescribed in this RFP
     are welcome and may be evaluated as part of Section IV of the RFP (see Section 3.5.1: Form and Format).
     However, alternative solutions must be clearly marked and may not exceed 5 pages in addition to the pages
     prescribed for Section IV.

2.   The Cost Proposal (Section X of the Form and Format section) must be submitted in a separate sealed envelope
     within the proposal package or container. No other mention of costs or expenses may be included in any other
     parts of the proposal. Failure to abide by these instructions for submitting cost proposals will result in the
     disqualification of any non-complying proposal.

3.   Cost proposals must include all expenses for the proposed work, including travel and other reimbursable
     expenses, if any. Proposers must list the titles of all persons to be assigned to the contract, their hourly rates, and
     the total number of hours the proposer will utilize them on the contract through completion of the study. For
     potential services to be provided after completion of the study, only hourly rates should be listed, as the STATE
     will utilize such services at its discretion (and therefore will evaluate such costs at an assumed number of hours
     of services provided).


Legal Requirements

Contract
A boilerplate State of Minnesota professional and technical services contract is attached to this RFP as Appendix A.
The State will assume that responders will accept all provisions in the boilerplate contract unless specific exceptions
are taken to particular terms or conditions in the proposal. All such exceptions must be noted in Section VI of the
proposal. (See Section 3.5.1: Form and Format.) Although it is possible that some exceptions may be negotiated,
such negotiation will be limited to specified exceptions in the responders’ proposal. The State reserves the right to
refuse to negotiate requested exceptions at its discretion. Failure to note exceptions in the proposal to terms or
conditions in the contract constitutes acceptance of all such terms and conditions. Proposals that take blanket
exception to all or substantially all boilerplate contract provisions will be considered non-compliant proposals and
rejected from further consideration for contract award.

Affirmative Action
All responders must comply with affirmative action provisions contained in Minnesota Statutes Section 363.073. To
establish compliance, all responders must complete and submit with their proposals the Affirmative Action Data
Pages, which is attached to this RFP in Appendix B.




                                                            26
                                          Health Care Automation RFP


Workers Compensation
Prior to executing a contract with DHS, the successful responder must submit evidence that it is in compliance with
the Minnesota workers’ compensation requirements in Minnesota Statutes Sections 176.181 and 176.182.

Availability Offered and State Employees
In compliance with Minnesota Statutes Section 16C.08, the availability of this contracting opportunity is being
offered to state employees. The State will evaluate the responses of any state employee, along with other responses
to the RFP.

Organizational Conflict of Interest
The proposer warrants that, to the best of its knowledge and belief, and except as otherwise disclosed, there are no
relevant facts or circumstances which could give rise to organizational conflicts of interest. An organizational
conflict of interest exists when, because of existing or planned activities or because of relationships with other
persons, a vendor is unable or potentially unable to render impartial assistance or advice to the State, or the vendor's
objectivity in performing the contract work is or might be otherwise impaired, or the vendor has an unfair
competitive advantage. The contractor agrees that, if after award, an organizational conflict of interest is discovered,
an immediate and full disclosure in writing shall be made to the Assistant Director of the Department of
Administration's Materials Management Division which shall include a description of the action which the
contractor has taken or proposes to take to avoid or mitigate such conflicts. If an organizational conflict of interest is
determined to exist, the State may, at its discretion, cancel the contract. In the event the contractor was aware of an
organizational conflict of interest prior to the award of their contract and did not disclose the conflict to the
contracting officer, the State may terminate the contract for default. The provisions of this clause shall be included
in all subcontracts for work to be performed similar to the service provided by the prime contractor, and the terms
"contract," "contractor," and "contracting officer" modified appropriately to preserve the State's rights.

Lobbying Restrictions
The successful responder will be required to sign a lobbying restriction, certifying that no funds from the contract
awarded through this RFP will be used for purposes of lobbying federal lawmakers.

Vendor Cancellation
The proposer may withdraw the Proposal at any time prior to the proposal due date. A proposal may be withdrawn
upon written request of the proposer. Negligence of the proposer in preparing the proposal confers no rights to
withdraw the proposal after the proposal due date.
The vendor may change the proposal if changes are made prior to the proposal due date, provided that the change is
initialed by the proposer’s corporate representative or agent. The vendor may not cancel the contract without cause
and in accordance with the contract and the State and Federal Laws and Regulations governing this project.

State Cancellation
The State reserves the right to cancel this RFP at any time and for any reason. Upon execution of a contract with a
successful responder, Minnesota Statutes Section 16C.08 mandates that DHS and the Commissioner of
Administration have the right to terminate the contract for convenience at any time after the contract is executed.

Debarment
Federal Regulations 45 CFR 92.35 prohibits the State of Minnesota from purchasing goods or services with federal
money from vendors that have been suspended or debarred by the federal government. Similarly, Minnesota Statutes
Section 16C.03, subdivision 2 provides the Commissioner of Administration with the authority to debar and suspend
vendors who seek to contract with the State. Vendors may be suspended or debarred when it is determined, through
a duly authorized hearing process, that they have abused the public trust in a serious manner.

Certification
Before signing any contract through this RFP, the successful responder must certify that it and its principals:


                                                           27
                                           Health Care Automation RFP


1.   Are not presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded
     from transacting business by or with any federal, state or local governmental department or agency; and
2.   Have not within the preceding three-year period: a) been convicted of or had a civil judgment rendered against
     them for commission of fraud or a criminal offense in connection with obtaining, attempting to obtain or
     performing a public (federal, state or local) transaction or contract; b) violated any federal or state antitrust
     statutes; or c) committed embezzlement, theft, forgery, bribery, falsification or destruction of records, making
     false statements or receiving stolen property offenses; and
3.   Are not presently indicted or otherwise criminally or civilly charged by a governmental entity for: a)
     commission of fraud or a criminal offense in connection with obtaining, attempting to obtain or performing a
     public (federal, state or local) transaction; b) violating any federal or state antitrust statutes; or c) committing
     embezzlement, theft, forgery, bribery, falsification or destruction of records, making false statements or
     receiving stolen property; and
4.   Are not aware of any information and possess no knowledge that any subcontractor(s) that will perform work
     pursuant to the Contract are in violation of any of the certifications set forth above.

In accordance with Minnesota Rules part 1230.1810, subpart B and Minnesota Rules part
1230.1830, certified Targeted Group Businesses and individuals submitting proposals as prime
contractors will receive the equivalent of up to a six percent preference in the evaluation of their
proposal. Certified Economically Disadvantaged Businesses and individuals submitting
proposals as prime contractors will receive the equivalent of a six percent preference in the
evaluation of their proposals. For information regarding certification, contact the Department of
Administration, Materials Management Help Line at (651) 296-2600, TTY (651) 282-5799.
Other legal requirements are contained in the boilerplate contract (Appendix A).

Insurance Requirements
A certificate of insurance for each type of insurance required under this contract must be filed with the Project
Director within 30 days of execution of the contract and before commencement of any work under the contract.
Contractor’s policies shall be primary insurance to any other valid and collectible insurance available to the State Of
Minnesota with respect to claims arising out of this contract.
1) Each policy must contain a thirty-day Notice of Cancellation, non-renewal, or material change to all named and
    additional insured, where required.
2) The successful responder awarded this contract must maintain and furnish satisfactory evidence of the following
   types of insurance policies:
     A. The successful responder must furnish satisfactory evidence of insurance against loss by any means of data
        furnished to the contractor by the STATE, and for any partially completed data for which the STATE has
        made payment.
     B. Workers’ Compensation Insurance: The successful responder will provide Workers’ Compensation
        Insurance for all of the Proposer’s employees. In the case of Sub-contractors, the successful responder will
        require the sub-contractor to provide Workers’ Compensation Insurance in accordance with the statutory
        requirements of the state of Minnesota, and including Coverage B, Employer’s Liability, at limits of not
        less than $100,000.00 bodily injury by disease per employee; $500,000.00 bodily injury by disease
        aggregate; and $100,000.00 bodily injury by accident. Evidence of sub-contractor’s insurance shall be filed
        with the successful responder.
     C. Commercial General Liability: The successful responder will maintain insurance protecting the Contractor
        from claims for damages for bodily injury, including sickness or disease, death, and for care and loss of
        services as well as from claims for property damage including loss of use which may arise from operations
        under this contract directly or indirectly employed under this contract. Unless otherwise specified within
        this contract, the successful responder insurance minimum amounts will be as follows:
              (1) $1,000,000.00 – Per Occurrence



                                                             28
                                         Health Care Automation RFP


             (2) $2,000,000.00 – Annual Aggregate
         In addition, the following coverage should be included:
              (3) Products and Completed Operations Liability
             (4) Blanket Contractual Liability
             (5) Personal Injury
       And name the STATE as an additional Insured.
    D. Commercial Automobile Liability: The successful responder will maintain insurance protecting the
       Contractor from claims for damages for bodily injury including sickness or disease, death, and for care and
       loss of services as well as from claims for property damage including loss of use which may arise from
       operations under this contract directly or indirectly employed under this contract. Unless otherwise
       specified within this contract, the contractor’s insurance minimum amounts will be as follows:
             (1) $1,000,000.00 – per occurrence combined single limit for bodily injury and property damage.
         In addition, the following coverage should be included:
              (2) Owned, Hired, and Non-owned
       And name the STATE as an additional Insured.
    E. Professional/Technical, Errors and Omissions, and/or Miscellaneous Liability Insurance:
             (1) Unless otherwise specified within the contract, The Contractor insurance minimum limits will be
                 set at $1,000,000.00 per occurrence
             (2) The contractor must submit a certified financial statement that provides evidence that the
                 Contractor has adequate assets to cover any deductible that applies to this policy.
             (3) This policy will provide coverage for all claims the contractor will become legally obligated to
                 pay resulting from any actual or alleged negligent act, error, or omission related to the
                 Contractor’s professional services required under this contract.
3) The Contractor must include legal defense fees in addition to its liability policy limits except for professional
   liability, and obtain insurance policies from an Insurance Company having a an “AM Best” rating of A- or
   better; and FSC/VIII or better.
4) The STATE reserves the right to immediately rescind this contract if the Contractor is not in compliance
   with the insurance requirements and retains all right to pursue any legal remedies against the
   Contractor. All insurance policies must be open to inspection by the STATE, and copies must be
   submitted to the Project Director upon written request.
5) The insurance company(s) waives their rights to assert the immunity of the State as a defense to any claims
   made under said insurance.


Proposal Submission Instructions
In order to be considered a valid proposal, the proposal shall be in writing, submitted on time and accordance with
the RFP process, and signed in ink by an officer of the company accountable for the content of the submitted
proposal. This section provides the physical instructions to submit a valid proposal that meets the proposal
requirements.

Form and Format
The proposal must be delivered in two forms; written and electronic. The written proposals should be submitted in
12-point font on 8 ½ x 11 paper single-spaced and should not exceed the suggested page limits set forth below. All
proposals, including required copies, must be submitted in a single sealed package or container. The electronic
version of the proposal is to be included in the container on diskette or CD in Microsoft Word (Office97 or newer).
The format should be completed in accordance with the following outline of sections:
         Section I          Table of Contents
         Section II         Executive Summary (in non-technical language, not to exceed 4 pages) and Business
                            Requirements (Section 2.1 and Appendix E)



                                                          29
                                    Health Care Automation RFP


       Section III    Contractor Qualifications and Experience. This section must include:
                      1. Proposer qualifications demonstrating that the proposer meets the requirements per
                         Section 3.1.1 of this RFP and that explains why your experience and qualifications
                         make you eligible to respond to this RFP (not to exceed 20 pages)
                      2.   Business profile describing your organization and related services required for
                           successful completion of the project (two to four pages)
                      3.   Three to six project success stories related to this type of project. (Each summary
                           may not exceed two pages)
                      4.   At least two references for similar projects successfully completed within the past
                           three years. The contact person given as a reference must be a project sponsor and
                           must be someone we can contact for supplementary information related to your
                           work. Projects referenced must demonstrate the capabilities of members of the
                           proposed project team.
                      5.   Proposed Personnel with resumes, and related experience. (Include actual resumes
                           and percentage of time dedicated to this project, 2 pages per individual, for staff to
                           be assigned to this project.)

Section IV     Proposed Solution(s), must, at a minimum, address how outcomes will be met
using the requirements and features set forth in the business and technical requirements in this
RFP. Solutions must address the critical success factors per RFP Section 1.8 and must include:
                      1.   Project Assumptions and Considerations (Section 1.12 of RFP)
                           a) Identify any and all assumptions you are making based on the content of the
                           RFP and your needs as a Proposer to make this a successful implementation. Identify
                           all assumptions related to the DHS organization in the way of support.
                           b) Describe how you have taken into consideration the items listed in
                                considerations in your response. For any area not already      addressed
                           elsewhere in the proposal, use this area to describe how you will manage and
                           incorporate these project considerations.
                           c) Describe any alternative solutions per section 3.2 in this RFP. If
                                alternatives result in significant scheduling and/or estimate  changes, please
                           outline these changes.
                      2.   Technical Approach - This section must contain both narrative text and diagrams. All
                           items outlined in Section 2.2, 2.3, and 2.4 of the RFP should be included in addition
                           to any other pertinent items.
                      3.   Project Approach
                           a) Describe the methodology you will use to manage the software
                                development effort through all phases of the project. A detailed
                                description of your approach to design, software development,              testing,
                           training, system documentation, implementation and           rollout, and system
                           acceptance should be included. This should be a description related directly to this
                           project in addition to your      overall software development methodology. Any
                           software tools          you will use to build the HCA system should be described
                           here.
                           b) Outline your plan for issue tracking, change control, ongoing scope
                           management and communications management.
                           c) Describe your plan for software migration and the development
                                environment structure.
                           d) Identify resources required for the project and the percentage of            time
                           available for the project. Include plans for how you would             involve the state
                           staff and necessary skill sets and knowledge base.           Describe how you will
                           accomplish the goal of knowledge transfer.          Please provide actual resources that
                           may be used on the project by submitting actual resumes. (Describe how many of
                           these resources         will be sub-contracted vs. contractor employees.) Also include



                                                     30
                                           Health Care Automation RFP


                                     your requirements for work location, access, physical space, software, and
                                connectivity. Use this section to describe the project     management you will use
                                on the project in addition to any other organizational items as listed in section 1.9
                                of this proposal.
                                e) Describe your strategy for a structure for on-going support and
                                     maintenance of the new HCA system that includes necessary resources for
                                administrative, technical, and help desk support.
Section V     Proposed Statement of Work and Work Plan, including descriptive text in
business language as well as an MS Project schedule. This section must also contain:
                           1.   Work Breakdown Structure
                           2.   Schedule
                           3.   Task assignments (roles) between DHS and contractor and percentages of time
                                assigned to the project.
                           4.   Deployment strategy for each class or segment of the user population
Section VI        Proposer Suggested Revisions (if any, not to exceed 4 pages)
Section VII       Miscellaneous Concerns (if any – not to exceed 2 pages)
         Section VIII      Other certifications, forms, or affidavits (as required) per section 3.2 of this RFP. This
                           includes the following:
                           –Affirmative Action data page
                           –Statement regarding organizational conflicts of interest
                           –Financial information for the past two years (per section 3.1.2-4)
                           –Identifying if the certified Targeted Business Group designation applies.
         Section IX        Terms and Conditions (as required)
         Section X         Cost Proposal (see instructions below)
                           The Cost Proposal (Section X) must be submitted in a separate sealed envelope within the
                           proposal package or container. No other mention of costs or expenses may be included in
                           any other parts of the proposal.
                           Failure to abide by these instructions for submitting Cost Proposals may result in the
                           disqualification of any non-complying proposal.

Mailing Instructions
Within the required sealed proposal package or container, each responder must submit one (1) original proposal
signed in ink by an authorized party, one (1) electronic copy, fourteen (14) hard copies of the original proposal and
one (1) Cost Proposal in a separate and clearly marked envelope. Include the contact name and telephone number
and e-mail address for your agency. Send the container and contents to the address identified in the subsequent
Submission Address and Schedule section of the RFP. Faxed or e-mailed proposals will not be considered. Late
proposals will not be considered.
Once submitted, all proposals shall constitute binding irrevocable offers to enter into a business relationship with the
State for a period of 180 days after the proposal submission deadline date. Acceptance of any proposal shall occur
upon final execution of a contract.
All materials submitted in response to this RFP will become the property of the STATE and will become public
record after the evaluation process is completed and an award decision made. If the Responder submits information
in response to this RFP that it believes to be trade secret materials, as defined by the Minnesota Government Data
Practices Act, Minnesota Statutes Section 13.37, the Responder must:
     a) Clearly mark all trade secret materials in its response at the time the response is submitted,
    b) Include a statement with its response justifying the trade secret designation for each item, and
    c)   Defend any action seeking release of the materials it believes to be trade secret, and indemnify and hold
         harmless the STATE, its agents and employees, from any judgments awarded against the STATE in favor
         of the party requesting the materials, and any and all costs connected with that defense. This
         indemnification survives the STATE’s award of a contract. In submitting a response to this RFP, the
         Responder agrees that this indemnification survives as long as the trade secret materials are in the



                                                          31
                                        Health Care Automation RFP


        possession of the STATE. The STATE is required to keep all the basic documents related to its contracts,
        including responses to RFPs for a minimum of seven years.

The STATE will not consider prices submitted by the Responder to be trade secret materials.

Proposal Withdrawal
A proposal may be withdrawn under the following conditions:
    Upon written request of the proposer prior to the proposal due data. Negligence of the proposer in preparing the
    proposal confers no right to withdraw the proposal after the proposal due date.
    Prior to opening, changes may be made, provided the proposer initiates the change. If the intent of the proposer
    is not clearly identifiable, the interpretation most advantageous to the State will prevail. Once submitted, a
    proposal becomes public property and will not be returned.


Submission Address and Schedule
                               All proposals must be received no later than July 10, 2002 2:00 p.m.
                               Proposals must be submitted to:
                                       Minnesota Department of Human Services
                               Attention: Joyce Fischer
                               C/O: Information Desk
                               444 Lafayette Road N.
                               1st Floor
                               St. Paul, Minnesota 55155
Proposals submitted after the proposal deadline will not be considered. Fax and E-mail-only
responses will not be considered. All costs incurred in responding to this Request for Proposal
will be borne by the responders.

Communication Between DHS and Vendors Prior to Selection
Prospective proposers will have an opportunity to ask questions to clarify any uncertainties which may exist in this
RFP using the Proposer Conference and the Question period preceding the Proposer Conference. All communication
will be shared with all other proposers equally. Additionally, an Online Reference Document Library has been
established that contains other DHS related documentation related to this project. Any non-written answers provided
in response to questions at the Proposer Conference will be non-binding; a written addendum with binding responses
to all questions will be furnished to all prospective proposers within two weeks of the Proposer Conference.

Proposer Conference
A Proposer Conference will be held on Thursday, June 13, 2002 at 10:00 a.m. CDT. The purpose of the
conference is to allow the DHS project managers to present the project content to potential proposers. The
conference will be held at the address below:
                                         Metro State University Auditorium
                                                700 E. Seventh Street
                                             St. Paul, Minnesota 55106
Attendance at the Proposer Conference is not mandatory but is highly recommended. You must RSVP by e-mail or
in writing to Joyce Fischer at joyce.fischer@state.mn.us or to the address listed below.
Binding responses to all questions will be sent to all prospective proposers and will be available online to all
prospective proposers within two weeks after the Proposer Conference.




                                                         32
                                        Health Care Automation RFP


Questions
All questions for the Proposer Conference regarding this proposal must be submitted in writing no later than June 3,
2002. Question responses will be sent to responders after the Proposer Conference and made available in the online
library.
Written questions will be accepted prior to the Proposer Conference by e-mail or in writing to Joyce Fischer at
joyce.fischer@state.mn.us or to the address listed below. Questions should identify the RFP section or subsection
being addressed or toward specific Appendix and section or item referencing the page number(s) of the RFP.
Questions are to be submitted to:
                                                  Ms. Joyce Fischer
                                         MN Department of Human Services
                                           Health Care Operations division
                                                444 Lafayette Road N.
                                              St. Paul, MN 55155-3849
No further substantive questions will be accepted about the RFP after the completion of the Proposer
Conference.

Timelines
    Question Submission Due Date:                                      June 3, 2002
    Proposer Conference RSVP Due Date:                                 June 3, 2002
    Proposer Conference Date:                                          June 13, 2002
    Q & A Summary Mailed/Posted in Online Library:                     June 24, 2002
    Proposal Due Date:                                                 July 10, 2002
    Award Notification Date:                                           August 9, 2002

Online Reference Document Library
An Online Reference Document Library has been established that contains additional information on this project and
about DHS. Access to this library has been secured and will require access approval from DHS. Contact Joyce
Fischer at joyce.fischer@state.mn.us or at the address above to obtain access log-in and password information.




                                                         33
                                          Health Care Automation RFP



Selection Process
The proposal selection will be made in a multi-step process. Responses will be weighed based on
the proposer’s understanding of the project scope and size as well as the proposed solution. This
includes both the solution and the project approach. This project will be awarded to the proposer
who demonstrates knowledge and an understanding of DHS’ business needs and has had success
in completing a large project in a highly regulated environment of a public entity. Upon
evaluation of the project proposals, the pricing component will be evaluated.

Evaluation and Selection
The following sections discuss the evaluation and selection process the State will use to evaluate each proposal.

Rules
     Proposals that comply with the instructions set forth above will be evaluated by DHS.
     However, DHS reserves the right to reject any or all proposals received, in whole or in part.
     At its sole discretion, DHS may choose to waive immaterial deviations from the RFP
     instructions.
     The State reserves the right to waive any minor irregularities in the proposal process.
     The State reserves the right to solicit additional information from any or all proposers for
     clarification purposes.

Proposals will be evaluated in a multi-step process:
Step One: Validation. Only those proposals deemed valid per Section 3.5 of this RFP will be evaluated in step two
of this process.
Step Two: Reference Checks. Proposals deemed valid in step one will undergo reference checks. Upon
determination that references given accurately reflect successful experience, proposals will proceed to step three. If a
responder’s references do not pass step two, their proposal(s) will not be considered for further evaluation.
Step Three: Evaluation of qualifications, experience, business and project approach as follows:
1. Understanding of the business needs and project goals                          20%
2.   Qualifications/experience of assigned personnel and company          30%
3.   The ability to deliver the project within the goal timeframe                  20%
4.   The project work plan; text and timeline                                      30%
Proposals deemed acceptable in step three will move on to Step Four of this process.
Step Four: Evaluation of the technical approach. Proposals will be evaluated in this step in order to rate the technical
solution’s ability to meet project goals.
Evaluation summary scores will be tabulated for steps three and four. Only those proposals that are within a
competitive range upon completion of the evaluation of the other numbers will be evaluated in Step Five.
Step Five: The total cost of this project (project cost detail). Only the highest-scoring proposals will move on to this
step of the process. At this step, the separate sealed envelopes will be opened, and the cost proposals will be
evaluated per the following formula:
         1. Lowest price ÷ proposal price = y
         2. Total points possible x y = price points
Step Six: Risk Assessment. An independent risk assessment will be conducted.




                                                           34
                                         Health Care Automation RFP


Upon completion of the evaluation process, the State will enter into negotiations with the responder whose proposal
offers DHS the best value, as determined in the evaluation process. The State reserves the right to conduct oral
interviews, simultaneously negotiate with more than one responder, ask responders to provide additional references,
or to ask for best and final offers from one or more responders.
If negotiations are successful, the State will award a contract to the responder it has deemed will provide the best
value possible. After the contact is awarded, all responders who submitted unsuccessful proposals will be notified.
Until a contract is awarded, no information will be provided about the status of the evaluation process. All
responders must assume that until the 180-day offer period expires or until they are notified otherwise, they could be
asked to enter contract negotiations with DHS.



                                                          1. Validation

                                                     2. Reference Checks


                                      3. Evaluation of qualifications, experience, business
                                               approach, project approach, etc.




                                              4. Evaluation of technical approach




                                                     5. Evaluation of price




                                                            6. Risk
                                                          Assessment


                                                             Offer




Process
An evaluation committee will be comprised of business and technical resources knowledgeable with the project. An
evaluation matrix has been developed to maintain consistency in the evaluation process. The process will include a
review of the proposal for compliance and for content as well as a review for capability and methodology and for the
understanding of the business needs. The process steps are as follows:
    The evaluation committee will review each proposal and complete the evaluation matrix.
    The reviewers will compile any questions or clarifications required to be addressed to the
    proposer.
    Questions and clarifications will be resolved.
    Results will be tabulated with weights applied to the proposal content.
    A risk assessment will be performed.




                                                              35
                                                 Health Care Automation RFP



Appendices
 5.1    APPENDIX A: TECHNICAL SERVICES CONTRACT ............................................................................................37
 5.2    APPENDIX B: AFFIRMATIVE ACTION DATA PAGES ........................................................................................48
 5.3    APPENDIX C: ASSURANCES AND AGREEMENTS .............................................................................................51
 5.4    APPENDIX D: MAJOR PROGRAMS/ELIGIBILITY TYPES FOR HEALTH CARE AUTOMATION ..............................52
 5.5    APPENDIX E: BUSINESS REQUIREMENTS ........................................................................................................54
 5.6    APPENDIX F: DHS TECHNOLOGY AND SYSTEMS ...........................................................................................72
 5.7    APPENDIX G: LEGACY SYSTEM INTERFACE REQUIREMENTS .........................................................................74
 5.8    APPENDIX H: HEALTH CARE AUTOMATION WORK GROUP DESCRIPTIONS ....................................................77
 5.9    APPENDIX I: CAPABILITY MATURITY MODEL FOR SOFTWARE .......................................................................78
 5.10     APPENDIX J: DHS ONLINE REFERENCE DOCUMENT LIBRARY ..................................................................80




                                                                      36
                                            Health Care Automation RFP

Appendix A: Technical Services Contract
STATE OF MINNESOTA
PROFESSIONAL/TECHNICAL CONTRACTUAL (non-state employee) SERVICES

Originator - fill in the Account(s) (Org #) and Requisition Agency # this contract will be charged to.
Fill in the total amount of contract and the amount to be encumbered IF this contract spans more than
one fiscal year. Use the assigned CFMS Contract number below to pay invoices for this contract.
          Org #___ ___ ___ ___ Req#H55 ___ ___ ___

Total amount of contract: $______________amount of contract first FY: $______________




Accounting Information Contract Coordinator - fill in fields below when encumbered:
fiscal year:        __________     vendor number: _____________________________

Accounting Distribution 1:       Accounting Distribution 2:
Org #:                 __________                 Org #:          ______________
compensation:          __________                 expenses:       ______________
commodity code:        __________                 commodity code: ___________
object code: __________                  object code:     ______________
Amount:                __________                 Amount:         ______________
CFMS Contract #: ___________________________________________
                                         Number/Date/Initials
Individual signing certifies that funds have been encumbered as required by MS § 16A15.]




NOTICE TO CONTRACTOR: You are required by Minnesota Statutes, Section 270.66 to provide your social
security number or Federal employer tax identification number and Minnesota tax identification number if you do
business with the State of Minnesota. This information may be used in the enforcement of federal and state tax
laws. Supplying these numbers could result in action to require you to file state tax returns and pay delinquent
state tax liabilities. This contract will not be approved unless these numbers are provided. These numbers will be
available to federal and state tax authorities and state personnel involved in approving the contract and the
payment of state obligations.
Proposer Name and Address:                               ______________________________
                                                         ______________________________
                                                         ______________________________
                                                         City State Zip Code
Soc. Sec. or Federal Employer I.D. No.                ________________________
Minnesota Tax I.D. No. (if applicable)                ________________________

          THIS PAGE OF THE CONTRACT CONTAINS PRIVATE INFORMATION.
 EXCEPT AS DEFINED ABOVE, THIS PAGE SHOULD NOT BE REPRODUCED OR DISTRIBUTED
    EXTERNALLY WITHOUT EXPRESS WRITTEN PERMISSION OF THE CONTRACTOR

           If you circulate this contract internally, only offices that require access to the tax identification number
                      AND all individuals/offices signing this contract should have access to this page.


Page # 37         Revised 10/2004
of CFMS #
                                      Health Care Automation RFP

                           STATE OF MINNESOTA
              PROFESSIONAL AND TECHNICAL SERVICES CONTRACT

THIS CONTRACT, and amendments and supplements thereto, is between State of Minnesota, acting through its
(hereinafter STATE), and _________________, an independent contractor, not an employee of the State of
Minnesota, (address)                                                  (hereinafter CONTRACTOR).

Recitals
Under Minnesota Statutes section _____________ , the STATE, is empowered to enter into contracts to provide
services and engage such assistance as deemed necessary to carry out its mission.
The STATE is in need of the following services:_____________________________
____________________________________________________________________.
The CONTRACTOR represents that it is duly qualified and agrees to perform all services described in this
contract to the satisfaction of the STATE.

1.      Term Of Contract.

        1.1    Effective date: This contract will be effective on             , or the date that the STATE
               obtains all required signatures under Minnesota Statutes, section 16C.05, subdivision 2,
               whichever is later. The CONTRACTOR must not begin work under this contract until
               ALL required signatures have been obtained, and CONTRACTOR has been notified by the
               STATE'S Authorized Representative to begin work.
        1.2    Expiration date: This contract will remain in effect through                            , or until all
               obligations have been satisfactorily fulfilled, whichever occurs first.

        1.3    Survival of Terms: The following clauses survive the expiration or cancellation, or termination
               of this contract: 8. Liability; 9. State Audits; 10. Information Privacy Protection; 11. Intellectual
               Property Rights; 14. Publicity and Endorsement; 15. Governing Law, Jurisdiction and Venue;
               and 19. Data Disclosure.

2.      Contractor's Duties. CONTRACTOR, who is not a state employee, will (Attach additional page if
        necessary which is incorporated by reference and made a part of this agreement.):

3.     Time. CONTRACTOR will perform its duties within the time limits established in this contract unless
       prior approval is obtained from STATE.

4.     Consideration And Payment.

       4.1.    Consideration. The STATE will pay for all services performed by the CONTRACTOR under
               this contract as follows:

               (a)      Compensation. The CONTRACTOR will be paid as follows [hourly, monthly,
                        quarterly, or per the attached payment schedule, which is incorporated by reference]:

               (b)      Reimbursement for travel and subsistence expenses actually and necessarily incurred by
                        CONTRACTOR in performance of this contract in an amount not to exceed
                        dollars ($       ); provided, that CONTRACTOR will be reimbursed for travel and
                        subsistence expenses in the same manner and in no greater amount than is provided in
                        the current Commissioner’s Plan (which is incorporated by reference) established by the
                        Commissioner of Employee Relations. CONTRACTOR will not be reimbursed for
                        travel and subsistence expense incurred outside the State of Minnesota unless it has
                        received prior written approval for such out of state travel from the STATE.

               (c)      The total obligation of the STATE for all compensation and reimbursements to
                        CONTRACTOR will not exceed             dollars ($         ).

Page # 38       Revised 10/2004
of CFMS #
                                    Health Care Automation RFP

              (d)      (If applicable.) For compensation payable under this contract, which is subject to
                       withholding under state or federal law, appropriate amounts will be deducted and
                       withheld by STATE as required.

     4.2.     Payment.

              (a)      Invoices. The STATE will promptly pay the CONTRACTOR after the CONTRACTOR
                       presents itemized invoices for services performed and the STATE'S authorized
                       representative accepts the invoiced services. Invoices will be submitted timely, in a
                       form prescribed by the STATE and according to the following schedule:_____________

              (b)      Retainage. Under Minnesota Statutes, section 16C.08, subdivision 5(b), no more than
                       ninety (90%) percent of the compensation due under this contract may be paid until the
                       final product(s) of the contract has been reviewed by the STATE and it has been
                       determined that the CONTRACTOR has satisfactorily fulfilled all the terms of the
                       contract.

              (c)      Federal funds. (Where applicable, if blank this section does not apply) Payments under
                       this contract will be made from federal funds obtained by the STATE through Title
                       _______________, Catalog of Federal Domestic Assistance (CFDA) Number
                       _______________, of the _______ Act of (year)                                 (Public law
                       and amendments thereto). The CONTRACTOR is responsible for compliance with all
                       applicable federal requirements imposed on these funds and accepts full financial
                       responsibility for any requirements imposed by CONTRACTOR’S failure to comply
                       with federal requirements. If at any time such funds become unavailable, this contract
                       will be terminated immediately upon written notice of such fact by the STATE to the
                       CONTRACTOR. In the event of such termination, CONTRACTOR will be entitled to
                       payment, determined on a pro rata basis, for services satisfactorily performed.

5.   Conditions Of Payment. All services provided by CONTRACTOR under this contract must be
     performed to the STATE’S satisfaction, as determined at the sole discretion of the STATE’S authorized
     representative, and in accordance with all applicable federal, state, and local laws, ordinances, rules and
     regulations. CONTRACTOR will not receive payment for work found by the STATE to be
     unsatisfactory, or performed in violation of federal, state or local law, ordinance, rule or regulation.

6.   Authorized Representatives.

     6.1      The STATE'S authorized representative is                             or his/her successor, who has
              the responsibility to monitor the CONTRACTOR’S performance and the authority to accept the
              services provided under this contract. If the services are satisfactory, the STATE’S Authorized
              Representative will certify acceptance on each invoice submitted for payment, in accordance
              with Clause 4.2, paragraph b.

     6.2      The CONTRACTOR’S Authorized Representative is                                 or his/her
              successor. If the CONTRACTOR’S Authorized Representative changes at any time during this
              contract, the CONTRACTOR must immediately notify STATE.

7.   Assignment, Amendments, Waiver, and Contract Complete.

     7.1      Assignment. The CONTRACTOR may neither assign nor transfer any rights or obligations
              under this contract without the prior consent of the STATE and a fully executed Assignment
              Agreement, approved by the same parties who executed and approved this contract, or their
              successors in office.
     7.2      Amendments. Any amendment to this contract must be in writing and will not be effective until
              it has been executed and approved by the same parties who executed and approved the original
              contract, or their successors in office.
Page # 39      Revised 10/2004
of CFMS #
                                        Health Care Automation RFP
         7.3     Waiver. If the STATE fails to enforce any provision of this contract, that failure does not waive
                 the provision or STATE’S right to enforce it.
         7.4     Contract Complete. This contract contains all negotiations and agreements between the STATE
                 and the CONTRACTOR. No other understanding regarding this contract, whether written or
                 oral, may be used to bind either party.

8.       Liability. CONTRACTOR agrees to indemnify and save and hold the STATE, its representatives and
         employees harmless from any and all claims or causes of action, including all attorney's fees incurred by
         the STATE, arising from the performance of this contract by CONTRACTOR or CONTRACTOR’S
         agents or employees. This clause will not be construed to bar any legal remedies CONTRACTOR may
         have for the STATE'S failure to fulfill its obligations pursuant to this contract.

9.     State Audits. Under Minn. Stat. §16C.05, subd. 5, the books, records, documents, and accounting
       procedures and practices of the CONTRACTOR and its employees, agents, or subcontractors relevant to
       this contract will be made available and subject to examination by the STATE, including the contracting
       Agency/Division, Legislative Auditor, and State Auditor for a minimum of six years from the end of this
       contract.
(Choose one of three options)
(Option #1 – does not handle any private data or protected health information)
10. Information Privacy Protection.

It is expressly agreed that the CONTRACTOR will not be handling private information collected by DHS and is
therefore not a member of or included within the “welfare system” for purposes of the Minnesota Government
Data Practices Act (hereinafter “Data Practices Act,” Minnesota Statutes, Chapter 13, and in particular §13.46) as
a result of this contract. The CONTRACTOR agrees to indemnify and save and hold the STATE, its agents and
employees, harmless for all claims arising out of, resulting from, or in any manner attributable to any violation by
CONTRACTOR or its employees or agents, of any provision of the Data Practices Act including legal fees and
disbursements paid or incurred to enforce this provision of the contract.

It is expressly agreed that CONTRACTOR will not be handling "protected health information" collected by DHS
(information that identifies an individual as having applied for, being or having been eligible for, or receiving or
having received health care services, as set forth in 45 CFR §160.102). CONTRACTOR is not a "business
associate" of DHS, as defined in the Health Insurance Portability Accountability Act ("HIPAA"), 45 CFR
§160.103. Therefore, CONTRACTOR is not required to comply with the privacy provisions of HIPAA as a result
of or for purposes of performing under this contract. If CONTRACTOR has responsibilities to comply with
HIPAA for reasons other than this contract, CONTRACTOR will be responsible for its own compliance.

OR     Option #2 (Handles private data and possibly some protected health information, but does not perform
any payment, eligibility or program assessment on behalf of DHS)

10. Information Privacy Protection.

For purposes of executing its responsibilities and to the extent set forth in this contract, the CONTRACTOR will
be considered part of the “welfare system,” as defined in Minnesota Statutes §13.46, subdivision 1. The
CONTRACTOR’S employees and agents will have access to private or confidential data maintained by the
STATE to the extent necessary to carry out CONTRACTOR’S responsibilities under this contract. The
CONTRACTOR agrees to comply with all relevant requirements of the Minnesota Government Data Practices
Act (hereinafter “Data Practices Act,” Minnesota Statutes, Chapter 13) in providing services under this contract.
__________ (CONTRACTOR’S employee or agent) or his/her successor is the responsible authority in charge of
all data collected, used, or disseminated by the CONTRACTOR in connection with the performance of this
contract. See Minnesota Statutes section 13.46, subdivision 10.

A. Duty to ensure proper handling of data: CONTRACTOR shall be responsible for training its employees who
   are authorized to access and use the data collected under the terms and for the purposes specified in this
   contract. This responsibility includes ensuring that staff are properly trained regarding:

     •    The Minnesota Government Data Practices Act (MGDPA), Minnesota Statutes Chapter 13, in particular,
          §13.46 (“welfare data”);
Page # 40         Revised 10/2004
of CFMS #
                                                             Health Care Automation RFP
                 •    The Minnesota Medical Records Act, Minn. Stat. §144.335;
                 •    Federal law and regulations that govern the use and disclosure of substance abuse treatment records, 42
                      USCS § 290dd-2 and 42 CFR § 2.1 to § 2.67.
                 •    The Health Insurance Portability Accountability Act (“HIPAA”), 45 CFR Parts 160 and 164 (if
                      applicable); and
                 •    Any other applicable state and federal statutes, rules, and regulations affecting the collection, storage, use
                      and dissemination of private or confidential information.

           B. Minimum necessary access to data:
           The CONTRACTOR shall comply with the “minimum necessary” access and disclosure standards set forth in the
           Data Practices Act. The dissemination of “private” and/or “confidential” data on individuals is limited to “that
           necessary for the administration and management of programs specifically authorized by the legislature or local
           governing body or mandated by the federal government.” See Minnesota Statutes, §13.05, subd. 3.

           C. CONTRACTOR shall:

                 (1) Not use or further disclose the information other than as permitted or required by this contract or as
                 required by law;
                 (2) Use appropriate safeguards to prevent use or disclosure of the information by its employees other than as
                 provided for by this contract;
                 (3) Report any use or disclosure of the information not provided for by this contract of which it becomes
                 aware;
                 (4) Consistent with this contract, ensure that any agents (including contractors and subcontractors), analysts,
                 and others to whom it provides private or confidential data, agree to be bound by the same restrictions and
                 conditions that apply to them with respect to such information;
                 (5) At termination of this contract, extend the protections of this contract to the information collected during
                 the course of this contract.

           D. Release of data

           No private or confidential data created, collected, received, stored, used, maintained or disseminated in the course
           or performance of this contract will be disseminated except as authorized by statute, either during the period of
           this contract or hereafter. If the CONTRACTOR is independently required to comply with any requirements of
           the Minnesota Government Data Practices Act or the privacy provisions of the Health Insurance Portability
           Accountability Act (“HIPAA,” 45 CFR §§160 and 164), the CONTRACTOR acknowledges that the STATE will
           not be liable for any violation of any provision of either Act indirectly or directly arising out of, resulting from, or
           in any manner attributable to actions of the CONTRACTOR or its employees or agents.

           The CONTRACTOR agrees to indemnify and save and hold the STATE, its agents and employees, harmless for
           all claims arising out of, resulting from, or in any manner attributable to any violation by CONTRACTOR or its
           employees or agents, of any provision of the Data Practices Act including legal fees and disbursements paid or
           incurred to enforce this provision of the contract.

           OR Option #3 (Handles protected health information which is used to provide eligibility, payment or assessment
           services on behalf of DHS )

           10. Information Privacy Protection.

For purposes of executing its responsibilities and to the extent set forth in this contract, the contractor will be processing health care bills or payments
on behalf of DHS, and/or conducting other health care operations on behalf of DHS. In carrying out its duties, contractor will be handling protected
health information and other private information concerning individual DHS clients. As such, CONTRACTOR agrees to be bound by the state and
federal laws protecting the privacy of information.

Because CONTRACTOR is handling protected health information and providing health care services to clients on behalf of DHS, CONTRACTOR is
a “Business Associate” of DHS, and must sign and comply with the terms of the attached “Business Associate Agreement,” Attachment __, of this
contract, which is incorporated herein by reference.

           Because CONTRACTOR is also handling other private data concerning DHS clients, CONTRACTOR will be
           considered part of the “welfare system,” as defined in Minnesota Statutes §13.46, subdivision 1. The

           Page # 41             Revised 10/2004
           of CFMS #
                                        Health Care Automation RFP
CONTRACTOR’S employees and agents will have access to private or confidential data maintained by the
STATE to the extent necessary to carry out CONTRACTOR’S responsibilities under this contract. The
CONTRACTOR agrees to comply with all relevant requirements of the Minnesota Government Data Practices
Act (hereinafter “Data Practices Act,” Minnesota Statutes, Chapter 13) in providing services under this contract.
__________ (CONTRACTOR’S employee or agent) or his/her successor is the responsible authority in charge of
all data collected, used, or disseminated by the CONTRACTOR in connection with the performance of this
contract. See Minnesota Statutes section 13.46, subdivision 10. CONTRACTOR accepts responsibility for
providing adequate supervision and training to its agents and employees to ensure compliance with the Data
Practices Act, and other relevant laws protecting private information.

The CONTRACTOR agrees to indemnify and save and hold the STATE, its agents and employees, harmless for
all claims arising out of, resulting from, or in any manner attributable to any violation by CONTRACTOR or its
employees or agents, of any provision of the Data Practices Act including legal fees and disbursements paid or
incurred to enforce this provision of this contract.

***SELECT ONE OF THE OWNERSHIP OPTIONS BELOW AND DELETE THE OTHER*** OPTION 1 -
STATE OWNS MATERIALS:

11.     Intellectual Property Rights.

        11.1    Definitions. Works means all inventions, improvements, discoveries (whether or not patentable
                or copyrightable), databases, computer programs, reports, notes, studies, photographs, negatives,
                designs, drawings, specifications, materials, tapes, and disks conceived, reduced to practice,
                created or originated by the CONTRACTOR, its employees, agents, and subcontractors, either
                individually or jointly with others in the performance of this contract. Works includes
                “Documents.” Documents are the originals of any databases, computer programs, reports, notes,
                studies, photographs, negatives, designs, drawings, specifications, materials, tapes, disks, or other
                materials, whether in tangible or electronic forms, prepared by the CONTRACTOR, its
                employees, agents, or subcontractors, in the performance of this contract.
        11.2    Ownership. The STATE owns all rights, title, and interest in all of
                the intellectual property, including copyrights, patents, trade secrets, trademarks, and service
                marks in the Works and Documents created and paid for under this contract. The Works and
                Documents will be the exclusive property of the STATE and all such Works and Documents
                must be immediately returned to the STATE by the CONTRACTOR upon completion or
                cancellation of this contract. To the extent possible, those Works eligible for copyright
                protection under the United States Copyright Act will be deemed to be “works made for hire.”
        11.3     Responsibilities.
                 a. Notification. Whenever any Works or Documents (whether or not patentable) are made or
                 conceived for the first time or actually or constructively reduced to practice by the
                 CONTRACTOR, including its employees and subcontractors, and are created and paid for
                 under this contract, the CONTRACTOR will immediately give the STATE’S Authorized
                 Representative written notice thereof, and must promptly furnish the Authorized Representative
                 with complete information and/or disclosure thereon. The CONTRACTOR will assign all right,
                 title, and interest it may have in the Works and the Documents to the STATE.
                 b.         Filing and recording of ownership interests. The CONTRACTOR must, at the request
                 of the STATE, execute all papers and perform all other acts necessary to transfer or record the
                 STATE’S ownership interest in the Works and Documents created and paid for under this
                 contract. The CONTRACTOR must perform all acts, and take all steps necessary to ensure that
                 all intellectual property rights in these Works and Documents are the sole property of the
                 STATE, and that neither CONTRACTOR nor its employees, agents, or subcontractors retain
                 any interest in and to these Works and Documents.
                 c.     Duty not to Infringe on intellectual property rights of others. The CONTRACTOR
                 represents and warrants that the Works and Documents created and paid for under this contract
                 do not and will not infringe upon any intellectual property rights of other persons or entities.
                 Notwithstanding Clause 8, the CONTRACTOR will indemnify; defend, to the extent permitted
Page # 42        Revised 10/2004
of CFMS #
                                           Health Care Automation RFP
                    by the Attorney General; and hold harmless the STATE, at the CONTRACTOR’S expense,
                    from any action or claim brought against the STATE to the extent that it is based on a claim that
                    all or part of these Works or Documents infringe upon the intellectual property rights of others.
                    The CONTRACTOR will be responsible for payment of any and all such claims, demands,
                    obligations, liabilities, costs, and damages, including but not limited to, attorney fees. If such a
                    claim or action arises, or in the CONTRACTOR’S or the STATE’S opinion is likely to arise,
                    the CONTRACTOR must, at the STATE’S discretion, either procure for the STATE the right or
                    license to use the intellectual property rights at issue or replace or modify the allegedly
                    infringing Works or Documents as necessary and appropriate to obviate the infringement claim.
                    This remedy of the STATE will be in addition to and not exclusive of other remedies provided
                    by law.

                   ***** OR*******OPTION TWO - CONTRACTOR OWNS MATERIALS:
 11.      Intellectual Property Rights.

         11.1     Definitions. Works means all inventions, improvements, discoveries (whether or
                  not patentable or copyrightable), databases, computer programs, reports, notes, studies,
                  photographs, negatives, designs, drawings, specifications, materials, tapes, and disks conceived,
                  reduced to practice, created or originated by the CONTRACTOR, its employees, agents, and
                  subcontractors, either individually or jointly with others in the performance of this contract.
                  Works includes “Documents.” Documents are the originals of any databases, computer programs,
                  reports, notes, studies, photographs, negatives, designs, drawings, specifications, materials, tapes,
                  disks, or other materials, whether in tangible or electronic forms, prepared by the
                  CONTRACTOR, its employees, agents, or subcontractors, in the performance of this contract.
       11.2       Use of Works and Documents. If any Works or Documents are developed by the
                  CONTRACTOR in the performance of this contract, the STATE and the U.S. Department of
                  Health and Human Services will have royalty free, non-exclusive, and irrevocable right to
                  reproduce, publish, or otherwise use, and to authorize others to use, the Works or Documents for
                  government purposes.

12.     Affirmative Action And Non-Discrimination.

        12.1        Affirmative Action requirements for Contractors with more than 40 full-time employees
                    and contract in excess of $100,000). If CONTRACTOR has had more than 40 full-time
                    employees within the State of Minnesota on a single working day during the previous twelve
                    months preceding the date CONTRACTOR submitted its response to the STATE, it must have
                    an affirmative action plan, approved by the Commissioner of Human Rights of the State of
                    Minnesota, for the employment of qualified minority persons, women and persons with
                    disabilities. See Minnesota Statutes section 363A.36. If CONTRACTOR has had more than 40
                    full-time employees on a single working day during the previous twelve months in the state in
                    which it has its primary place of business, then CONTRACTOR must either: (1) have a current
                    Minnesota certificate of compliance issued by the Minnesota Commissioner of Human Rights;
                    or (2) certify that it is in compliance with federal Affirmative Action requirements.

        12.2.       Affirmative Action and Non-Discrimination requirements for all Contractors:

               (a) The CONTRACTOR agrees not to discriminate against any employee or applicant for
               employment because of race, color, creed, religion, national origin, sex, marital status, status in regard
               to public assistance, membership or activity in a local commission, disability, sexual orientation, or
               age in regard to any position for which the employee or applicant for employment is qualified.
               Minnesota Statutes section 363A.02. CONTRACTOR agrees to take affirmative steps to employ,
               advance in employment, upgrade, train, and recruit minority persons, women, and persons with
               disabilities.

               (b) The Contractor must not discriminate against any employee or applicant for employment because
               of physical or mental disability in regard to any position for which the employee or applicant for
               employment is qualified. The Contractor agrees to take affirmative action to employ, advance in
Page # 43           Revised 10/2004
of CFMS #
                                         Health Care Automation RFP
             employment, and otherwise treat qualified disabled persons without discrimination based upon their
             physical or mental disability in all employment practices such as the following: employment,
             upgrading, demotion or transfer, recruitment, advertising, layoff or termination, rates of pay or other
             forms of compensation, and selection for training, including apprenticeship. Minn. Rule 5000.3550

             (c) CONTRACTOR agrees to comply with the rules and relevant orders of the Minnesota
             Department of Human Rights issued pursuant to the Minnesota Human Rights Act.

      12.3        Notification to employees and other affected parties. The CONTRACTOR agrees to post in
                  conspicuous places, available to employees and applicants for employment, notices in a form to
                  be prescribed by the commissioner of the Minnesota Department of Human Rights. Such
                  notices will state the rights of applicants and employees, and CONTRACTOR’S obligation
                  under the law to take affirmative action to employ and advance in employment qualified
                  minority persons, women, and persons with disabilities.

                  The CONTRACTOR will notify each labor union or representative of workers with which it has
                  a collective bargaining agreement or other contract understanding, that the CONTRACTOR is
                  bound by the terms of Minnesota Statutes, section 363A.36 of the Minnesota Human Rights Act
                  and is committed to take affirmative action to employ and advance in employment minority
                  persons, women, and persons with physical and mental disabilities.

      12.4        Compliance with Department of Human Rights Statutes. In the event of CONTRACTOR’S
                  noncompliance with the provisions of this clause, actions for non-compliance may be taken in
                  accordance with Minnesota Statutes 363A.36, and the rules and relevant orders issued pursuant
                  to the Minnesota Human Rights Act.

13.    Workers' Compensation and Other Insurance.

       13.1       Workers’ Compensation. The CONTRACTOR certifies that, if applicable, it is in compliance
                  with Minnesota Statute section 176.181, subdivision 2, pertaining to workers’ compensation
                  insurance coverage. If CONTRACTOR is required to comply with the above statute,
                  CONTRACTOR must provide STATE with evidence of compliance. The CONTRACTOR’S
                  employees and agents will not be considered employees of STATE. Any claims that may arise
                  under the Minnesota Workers’ Compensation Act on behalf of these employees or agents and
                  any claims made by any third party as a consequence of any act or omission on the part of these
                  employees or agents are in no way the STATE’S obligation or responsibility.

       13.2       Other Insurance. Contractor certifies that it is in compliance with any insurance requirements
                  specified in the solicitation document relevant to this Contract. If procurement was a single
                  source, CONTRACTOR acknowledges that it has liability insurance.

14.   Publicity and Endorsement.


      14.1 Publicity. Any publicity regarding the subject matter of this contract must identify the STATE as
           the sponsoring agency and must not be released without prior written approval from the STATE’S
           authorized representative. For purposes of this provision, publicity includes, notices, informational
           pamphlets, press releases, research, reports, signs, and similar public notices prepared by or for the
           CONTRACTOR or its employees individually or jointly with others or any subcontractors, with
           respect to the program, publications, or services provided resulting from this contract.

      14.2 Endorsement. The CONTRACTOR must not claim that the STATE endorses its products or
           services.

15.    Governing Law, Jurisdiction And Venue. This contract, and amendments and supplements thereto,
       will be governed by the laws of the State of Minnesota. Venue for all legal proceedings arising out of
       this contract, or breach thereof, will be in the state or federal court with competent jurisdiction in Ramsey
       County, Minnesota.
Page # 44         Revised 10/2004
of CFMS #
                                        Health Care Automation RFP
16.     Cancellation or Termination For Insufficient Funding.

       16.1 Cancellation. This contract may be canceled by the STATE, COMMISSIONER of
       ADMINISTRATION or CONTRACTOR at any time, with or without cause, upon thirty (30) days written
       notice to the other party. In the event of such a cancellation, CONTRACTOR will be entitled to payment,
       determined on a pro rata basis, for work or services satisfactorily performed.

       16.2 Insufficient Funding. Notwithstanding clause 16.1, the STATE may immediately terminate this
       contract if it does not obtain funding from the Minnesota Legislature, or other funding source; or if
       funding cannot be continued at a level sufficient to allow for the payment of the services covered here.
       Termination will be by written or fax notice to the CONTRACTOR. The STATE is not obligated to pay
       for any services that are provided after notice and effective date of termination. However, the
       CONTRACTOR will be entitled to payment, determined on a pro rata basis, for services satisfactorily
       performed to the extent that funds are available. The STATE will not be assessed any penalty if the
       contract is terminated because of the decision of the Minnesota Legislature, or other funding source, not to
       appropriate funds. The STATE must provide the CONTRACTOR notice of the lack of funding within a
       reasonable time of the STATE’S receiving that notice.

17. Voter Registration Requirement. CONTRACTOR certifies that if it is a not-for-profit business or
    governmental agency it will comply with Minnesota Statutes, section 201.162 by providing voter registration
    services for CONTRACTOR’S employees and for the public served by the CONTRACTOR.

18.    Federal Audit Requirements And Contractor Debarment Information.

       18.1 Compliance with Single Audit Act. All sub-recipients receiving $300,000
       or more of federal assistance in a fiscal year will obtain a financial and compliance audit made in
       accordance with the Single Audit Act, OMB Circular A-133. CONTRACTOR certifies it will comply
       with the Single Audit Act, OMB Circular A-133, if applicable. Effective December 31, 2003, if
       CONTRACTOR’S current fiscal year will end after December 31, 2003, it can receive up to $500,000
       during it’s respective fiscal years before having to comply with the Act. If CONTRACOR’S current fiscal
       year ends on or before December 31, 2003, it will have to wait until it’s next fiscal year begins to meet the
       new dollar requirements. Failure to comply with these requirements could result in forfeiture of federal
       funds.

       18.2 Contractor debarment, suspension and responsibility certification. Federal Regulation 45 CFR
       92.35 prohibits the STATE from purchasing goods or services with federal money from vendors who have
       been suspended or debarred by the federal government. Similarly, Minnesota Statutes 16C.03,
       subdivision 2 provides the Commissioner of Administration with the authority to debar and suspend
       vendors who seek to contract with the State.

       BY SIGNING THIS CONTRACT, CONTRACTOR CERTIFIES THAT IT AND ITS
       PRINCIPALS:

       A. Are not presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily
       excluded from transacting business by or with any federal, state or local governmental department or
       agency; and

       B. Have not within a three-year period preceding this Contract: a) been convicted of or had a civil
       judgment rendered against them for commission of fraud or a criminal offense in connection with
       obtaining, attempting to obtain or performing a public (federal, state or local) transaction or contract; b)
       violated any federal or state antitrust statutes; or c) committed embezzlement, theft, forgery, bribery,
       falsification or destruction of records, making false statements or receiving stolen property; and

       C. Are not presently indicted or otherwise criminally or civilly charged by a governmental entity for: a)
       commission of fraud or a criminal offense in connection with obtaining, attempting to obtain or
       performing a public (federal, state or local) transaction; b) violating any federal or state antitrust statutes;


Page # 45        Revised 10/2004
of CFMS #
                                       Health Care Automation RFP
      or c) committing embezzlement, theft, forgery, bribery, falsification or destruction of records, making
      false statements or receiving stolen property; and

       D. Are not aware of any information and possess no knowledge that any subcontractor(s) that will
      perform work pursuant to this contract are in violation of any of the certifications set forth above.

      E. Will immediately give written notice to the STATE should CONTRACTOR come under investigation
      for allegations of fraud or a criminal offense in connection with obtaining, attempting to obtain, or
      performing; a public (federal, state or local government) transaction; violating any federal or state antitrust
      statutes; or committing embezzlement, theft, forgery, bribery, falsification or destruction of records,
      making false statements or receiving stolen property.

19.   Data Disclosure. Under Minnesota Statutes, section 270.66, and other applicable law, the
      CONTRACTOR consents to disclosure of its social security number, federal employer tax identification
      number, and/or Minnesota tax identification number, to the STATE, to federal and state agencies and state
      personnel involved in the payment of state obligations. These identification numbers may be used in the
      enforcement of federal and state laws which could result in action requiring the CONTRACTOR to file
      state tax returns, pay delinquent state tax liabilities, if any, or pay other state liabilities.

20.   Other Provisions. (Attach additional pages as necessary):

       1. Payments to Subcontractors. (If Applicable) As required by Minn. Stat. §16A.1245, the prime
       contractor must pay all subcontractors, less any retainage, within 10 calendar days of the prime
       contractor’s receipt of payment from the State for undisputed services provided by the subcontractor(s)
       and must pay interest at the rate of one and one-half percent per month or any part of a month to the
       subcontractor(s) or any undisputed amount not paid on time to the subcontractor(s).
       2. Prohibition on Weapons.
       CONTRACTOR agrees to comply with all terms of the Department of Human Services' policy
       prohibiting carrying or possessing weapons wherever and whenever the CONTRACTOR is
       performing services within the scope of this contract. Any violations of this policy by
       CONTRACTOR or contractor's employees may be grounds for immediate suspension or
       termination of the contract.

       3. Foreign Outsourcing.
       Contractor agrees that the disclosures and certifications made in its Location of Service Disclosure and
       Certification Form submitted with its proposal are true, accurate and incorporated into this contract by
       reference.
       4. Minn. Stat. § 181.59
       The Contractor will comply with the provisions of Minn. Stat. § 181.59 which requires:

       Every contract for or on behalf of the state of Minnesota, or any county, city, town, township, school,
       school district, or any other district in the state, for materials, supplies, or construction shall contain
       provisions by which the contractor agrees: (1) That, in the hiring of common or skilled labor for the
       performance of any work under any contract, or any subcontract, no contractor, material supplier, or
       vendor, shall, by reason of race, creed, or color, discriminate against the person or persons who are
       citizens of the United States or resident aliens who are qualified and available to perform the work to
       which the employment relates; (2) That no contractor, material supplier, or vendor, shall, in any manner,
       discriminate against, or intimidate, or prevent the employment of any person or persons identified in
       clause (1) of this section, or on being hired, prevent, or conspire to prevent, the person or persons from
       the performance of work under any contract on account of race, creed, or color; (3) That a violation of
       this section is a misdemeanor; and (4) That this contract may be canceled or terminated by the state,
       county, city, town, school board, or any other person authorized to grant the contracts for employment,
       and all money due, or to become due under the contract, may be forfeited for a second or any subsequent
       violation of the terms or conditions of this contract.


Page # 46       Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX A

IN WITNESS WHEREOF, the parties have caused this contract to be duly executed intending to
be bound thereby.
APPROVED:

1. STATE ENCUMBRANCE VERIFICATION:
Individual certifies that funds have been encumbered
as required by Minn. Stat. 16A.15 and 16C.05.
                                                       3. STATE AGENCY:
By:                                                    By (with delegated authority)

Date:

CFMS Contract No.                                      Title:

                                                       Date:
2. CONTRACTOR:
Contractor certifies that the appropriate person(s)    4. STATE AGENCY:
have executed the contract on behalf of the
CONTRACTOR as required by applicable articles,         By:
 by-laws, resolutions or ordinances.
                                                       Title: Assistant Commissioner

By:                                                    Date:

Title:
                                                       5. COMMISSIONER OF ADMINISTRATION:
Date:                                                  By (authorized signature)


By:
                                                       Date
Title:

Date:
                                                       Distribution:
                                                       Agency – Original (fully executed) contract
                                                       Dept. of Administration
                                                       Contractor
                                                       State Authorized Representative




Page # 47        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX B



Appendix B: Affirmative Action Data Pages
If your response to the RFP is in excess of $100,000, please complete the information requested:
  BOX A:
  1.       Have you employed more than 40 full-time employees within Minnesota on a single working day during
           the previous 12 months?
           YES NO
           If your answer is “NO,” proceed to BOX B. If your answer is “YES,” your response will be rejected
           unless your firm or business has a Certificate of Compliance issued by the State of Minnesota,
           Commissioner of Human Rights, or has submitted an affirmative action plan to the Commissioner
           of Human Rights for approval by the time the responses are due for any solicitation in excess of
           $100,000.

 2.       Please check one of the following statements:
                   YES, we have a current Certificate of Compliance that has been issued by the State of
                   Minnesota, Commissioner of Human Rights. (Include a copy of your certificate with your
                   response.)
                   NO, we do not have a Certificate of Compliance; however, we submitted an Affirmative
                   Action plan to the Commissioner of Human Rights for approval on , 19 . The plan must be
                   approved by the Commissioner of Human Rights before any contract or agreement can be
                   executed.
                   NO, we have not submitted a plan. If your plan is not submitted by the time the responses are
                   due, your response will be rejected.

          NOTE: Minnesota contractors must have a certificate issued by the Minnesota Department of Human
          Rights. Affirmative Action plans approved by the federal    government, a county, or a municipality
          must still be reviewed and approved by     the Minnesota Department of Human Rights for a certificate
          to be issued.


 BOX B:

 1.       Have you employed more than 40 full-time employees on a single working day during the previous 12
          months in a state in which you have your primary place of business and that primary place of business
          is outside of the State of Minnesota, but inside the United States?
          YES NO

          If your answer is “NO,” proceed to BOX C. If your answer is “YES,” the State cannot execute a
          contract with your firm or business unless it is in compliance with the Minnesota Human Rights
          certification requirements. It is the sole responsibility of the contractor to apply for and obtain a
          human rights certification prior to execution as applicable. You may achieve compliance with the
          Human Rights Act by having either a current Certificate of Compliance issued by the State of
          Minnesota, Commissioner of Human Rights, or by certifying that you are in compliance with federal
          Affirmative Action requirements.

 2.       Please check one of the following statements:
                   YES, we have a current Certificate of Compliance issued by the Minnesota Department of
                   Human Rights. (Include a copy of your certificate with your response.)
                   YES, we are in compliance with federal Affirmative Action requirements.
          ______NO, we do not have a current Certificate of Compliance and we cannot certify that we are in
                   compliance with federal Affirmative Action requirements.


 BOX C:

 1.       If your answers to BOX A (Question 1) and Box B (Question 1) were “NO,” you are not subject to the
          Minnesota Human Rights Act certification requirement. Please, however, check one of the following:
                   NO, we have not employed more than 40 full-time employees within Minnesota on a single

Page # 48        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX B

                   working day during the previous 12 months and we have not employed more than 40 full-time
                   employees on a single working day during the previous 12 months in the state in which our
                   primary place of business is located.
                   We are a business with our primary place of business outside of the United States that has not
                   employed more than 40 full-time employees within Minnesota on a single working day during
                   the previous 12 months.

For further information regarding Minnesota Human Rights requirements, contact the Department of Human
Rights, Compliance Services, 190 East 5th Street, Suite 700, St. Paul, MN 55101; Voice: 651.296.5663; Toll Free:
800.657.3704; or TTY: 651.296.1283. For further information regarding federal Affirmative Action requirements,
call 800.669.4000 or visit its web site at http://www.eeoc.gov/. By signing this statement, the contractor
certifies that the information provided is accurate.
          NAME OF FIRM:
          AUTHORIZED SIGNATURE:
          TITLE:
          DATE:
                                                             (See next page)




Page # 49        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX B


             NOTICE TO CONTRACTORS
 AFFIRMATIVE ACTION CERTIFICATION OF COMPLIANCE
The Minnesota Human Rights Act (Minn. Stat. § 363.073) divides the contract compliance program into two
categories. Both categories apply to any contracts for goods or services in excess of $100,000.
The first category applies to businesses that have had more than 40 full-time employees within Minnesota on a
single working day during the previous 12 months. The businesses in this category must have submitted an
Affirmative Action plan to the Commissioner of the Department of Human Rights prior to the due date of the
response and must have received a Certificate of Compliance prior to the execution of the contract.
The second category applies to businesses that have had more than 40 full-time employees on a single working day
in the previous 12 months in the state in which they have their primary place of business. The businesses in this
category must have either a current Certificate of Compliance previously issued by the Department of Human Rights
or certify to the contracting state agency that they are in compliance with federal Affirmative Action requirements
before execution of the contract. For further information, contact the Department of Human Rights, 190 East 5th
Street, Suite 700, St. Paul, MN 55101; Voice: 651-296-5663; Toll Free: 800-657-3704; or TTY: 651-296-1283.
Minnesota contractors must have a current Certificate of Compliance or submitted an affirmative action plan
by the time proposals are due, or their proposal will be rejected.
State agencies are under no obligation to delay the execution of a contract until a contractor has completed
the Human Rights certification process. It is the sole responsibility of the contractor to apply for and obtain a
Human Rights certificate prior to execution, as applicable.




Page # 50        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX C



Appendix C: Assurances and Agreements
This section provides the assurances and agreements required by the Centers for Medicare and Medicaid Services
(CMS). It also discusses the Department's security and contingency plan to ensure confidentiality and continued
operations.

Security and Contingency Plan
To ensure that the information contained in the new Health Care Automation system will be properly safeguarded,
the Department may elect to perform annual security reviews of contractor operations using internal Department
staff, the Office of the State Comptroller, or separate contractor services. Security standards used in these reviews
will be based on industry standards set by the Secretary of Health and Human Services under the Health Insurance
Portability and Accountability Act of 1996 (HIPAA), or will contain the components required under 42 CFR 95.621,
Subpart F, whichever is in effect.
The contractor will be required to provide a contingency plan that provides measures to protect Medicaid data from
errors or disasters and will include established procedures for error and disaster recovery, including an adequate
back-up processing site. The Department will review and approve (or require changes to) the contractor's security
and contingency plan annually and request updates as necessary.

Agreements
The following agreements are provided in accordance with the requirements of 42 CFR 433.112(b)(5)-(9).
    The Department shall own any software, procedures, or publications that are designed,
    developed, and installed.
    The Department shall retain the right to sign, extend, and cancel any licenses for software
    used in operation of the system.
    The U.S. Department of Health and Human Services has a royalty-free, non-exclusive, and
    irrevocable license to reproduce, publish, or otherwise use and authorize others to use
    software, modifications to software, and documentation that is designed, developed,
    installed, or improved with 90 percent federal financial participation (FFP).
    The costs of the system will be determined in accordance with the principles of fair and open
    competition as provided by 45 CFR Part 74.171.
    All information in the system will be safeguarded in accordance with 42 CFR 431, Subpart F,
    or with such standards as established by the Secretary of Health and Human Services under
    the HIPAA provisions of 1996.




Page # 51        Revised 10/2004
of CFMS #
          Health Care Automation RFP—APPENDIX D



          Appendix D: Major Programs/Eligibility Types for Health Care Automation
Major         Elig    Population           Description                                                                                  Current   Include?
Program                                                                                                                                 System

AC            All     Disabled             Funding for home care services for people who would otherwise need nursing facility care     MMIS      No
BB            All     Adults               MCRE Non-parents, age 21 or older                                                            MMIS      Yes
EE            All     Children             Minnesota children with special needs (MCSHN)                                                MMIS      No
FF            All     Parents              MCRE citizen parents age 21 or older                                                         MMIS      Yes
GM/EGAMC      All     Adults, Parents      Enrollees who are not eligible for a federally funded program                                MAXIS     Yes
HH            All     Disabled             Insurance Extension Program                                                                  MMIS      No
IM            All     Disabled             Enrollees who would be eligible for Medicaid except for their living arrangement. This can   MAXIS     Yes
                                           include eligibility types for parents who are temporality in the IMD (AA and 1A)
JJ            All     Parents              MCRE non-citizen parents or relative caretakers, age 21 or older.                            MMIS      Yes
KK            All     Pregnant women and   MCRE non-citizen pregnant woman and children                                                 MMIS      Yes
                      kids
MA/NM/EM      CB      Child                MA/NM infant to age 2                                                                        MAXIS     Yes
MA/NM/EM      CK      Child                MA/NM children ages 2 through 18                                                             MAXIS     Yes
MA/NM/EM      CX      Child                MA/NM children ages 19 and 20                                                                MAXIS     Yes
MA/NM/EM      DC      Child                MA/NM disabled children age 18 through 20                                                    MAXIS     Yes
MA/NM/EM      DT      Child                MA/NM waiver for some disabled children who live with their families (TEFRA)                 MAXIS     Yes
MA/NM/EM      10      Child                MA/NM Minnesota Adoption Assistance                                                          MAXIS     Yes
MA/NM/EM      11      Child                MA/NM automatic newborn eligibility                                                          MAXIS     Yes
MA/NM/EM      25      Child                MA/NM IV-E Foster Care.                                                                      MAXIS     Yes
MA/NM         PX      Pregnant women       MA/NM pregnant women                                                                         MAXIS     Yes
MA/NM/EM      AA      Parent               MA/NM parent of a dependent child (this eligibility type is also valid for IM)               MAXIS     Yes
MA/NM/EM      1A      Parent               MA/NM MFIP parent (this eligibility type is also valid for IM)                               MAXIS     Yes
MA/NM/EM      13      Child, Parent        MA/NM 4 month extended medical (this eligibility type is also valid for IM)                  MAXIS     Yes
MA/NM/EM      14      Child, Parent        MA/NM 6 to 12 month extended medical (this eligibility type is also valid for IM)            MAXIS     Yes
MA/NM/EM      BX      Disabled any age     MA/NM blind person (this eligibility type is also valid for IM)                              MAXIS     No*
MA/NM/EM      DX      Disabled             MA/NM disabled person                                                                        MAXIS     No*
MA/NM/EM      EX      Elderly              MA/NM age 65 or older                                                                        MAXIS     No*
MA/NM/EM      15      Disabled             Employed disabled SSI person (MA and SSI)                                                    MAXIS     No*
MA/NM/EM      16      Disabled             Employed disabled SSI person (MA only)                                                       MAXIS     No*
MA/NM/EM      DI      Disabled             MA/EPD without a premium                                                                     MAXIS     No*



          Page # 52   Revised 10/2004
          of CFMS #
          Health Care Automation RFP—APPENDIX D

Major         Elig    Population              Description                                                                 Current      Include?
Program                                                                                                                   System

MA/NM/EM      DP      Disabled                MA/EPD with a premium                                                       MAXIS          No*
OO            All     Disabled                Consolidated Treatment Fund                                                 MMIS           No*
QM            All     Disabled, Elderly       Medicare premium payments and co-pays                                       MAXIS          No*
RM            All     Adults, Parents, Kids   Refugee Medical Assistance                                                  MAXIS          Yes
SL            All     Disabled, Elderly       SLMB – Medicare part B premium payment                                      MAXIS          No*
TT            All     Child                   Minnesota Children with special needs (MCSHN)                               MMIS           No*
UN            All     Disabled                Funding for screenings                                                      MMIS           No*
VV            All     Disabled, Elderly       Prescription Drug Program                                                   MAXIS          No*
WD            All     Disabled                Qualified working disabled (QWD)                                            MAXIS          No*
XX            All     Adults, parents         MCRE over 21 years old                                                      MMIS           Yes
New           All     All                     Family planning                                                             N/A            Yes
                                                                                              * Programs excluded from the first development phase




          Page # 53   Revised 10/2004
          of CFMS #
Health Care Automation RFP—APPENDIX E



Appendix E: Business Requirements

Data Collection
The Health Care Automation system will be required to collect all the data needed for eligibility determination. It is
anticipated that the system will utilize a questions-based, web-enabled data collection process. Based on the entry of
basic demographic data of household members, including relationship, a series of age and gender appropriate
questions will be asked for household members. Additional questions could be asked or eliminated based on the
responses to previous questions.

Data Elements
Listed below are examples of the types of data that are collected for health care eligibility.
                                     Household Data:
    Primary person’s name                                             County of residence
    Address                                                           Authorized Representative’s name
    Mailing address                                                   Authorized Representative’s address
                                     Applicant/Enrollee Data:
    Name                                                              Disability status
    Date of birth                                                     Assets
    Social Security Number                                            Asset transfers
    Relationship to the primary person                                Child support information
    Gender                                                            Income – Earned
    Ethnicity                                                         Income – Unearned
    Race                                                              Income – Seasonal
    Marital status                                                    Income – Self employment
    Citizenship                                                       Income deductions
    Pregnancy status                                                  Income allocations
    Language preference                                               Financial aid
    Residency                                                         Other health insurance
    Living arrangement                                                Vehicles
    Educational level

Application Process
The questions in the HCAPP (Minnesota Health Care Programs Application) would be used to collect the initial
health care eligibility information. The collection of this data can occur by completing:
    The online Web-based application, or
    The paper HCAPP, CAF, LTC (all different types of health care applications), or
    The E-forms HCAPP (PDF printable form available on the DHS web site), or
    A telephone call to someone (county/state/tribal worker) who would ask the HCAPP
    questions.
Page # 54         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

    A software development effort is currently underway at DHS to build a web-based, online
    application. This project will run in parallel with the Health Care Automation project and
    will be managed by the same DHS project management. The business requirements for the
    online application have been completed. Where it is feasible to use the developed online
    application in the Health Care Automation project, an effort will be made to avoid duplicate
    software development tasks and integrate the online application into the solution for HCA.

Often, the information collected by these processes does not provide sufficient information to
determine MHCP eligibility. Other information needed for determining Health Care eligibility
would be gathered in the following manner:
    Additional questions on the on-line application form
    Paper forms                                                      Telephone
    E-forms                                                          Fax

Enrollee Completed Online Application
For enrollees completing the Web-based application, the application should link to the eligibility
determination “engine”. A real-time cursory determination of potential health care eligibility
would then be performed and displayed to the enrollee. This cursory determination would
include a list of all Minnesota Health Care Programs for which there is potential eligibility,
unless the enrollee indicates that he/she is only applying for a specific type of health care
coverage (e. g. MinnesotaCare only). The cursory determination would display in the enrollee’s
language of choice. For those enrollees who are required or allowed to enroll in managed care
plans, the option for enrolling into a managed care plan will be allowed as part of the application
process.
Note:    For more information about managed care enrollment, see Managed Care/Health Plan Enrollment in the
         Other Health Care Factors section of this Appendix.
If the HCAPP were completed via the Web-based application, the information collected should not need to be
reentered. It is also anticipated that document management processing will scan paper applications and the
information relevant to health care would be system-populated and should not need to be reentered.

Registration
The registration process is defined as the process of recording the household’s application for intake processing. It is
anticipated that this function might only be used for those applications that are completed by enrollees via the Web-
based application. The registration process should:
    Support the identification and assignment of case characteristics and data elements to
    uniquely identify the application.
    Route the application to predefined locations throughout the State that process health care
    applications.
    Provide a reporting component for identifying those applications that are not processed
    timely.

Intake Process
Functions performed during the intake process provide a worker with the needed functionality to:



Page # 55         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

    Determine if the applicant is known to the system and assign any necessary identifiers to the
    applicant or other household members. If the applicant has or had previous coverage, the
    system should be able to determine if a new application is required, if the applicant is serving
    a penalty period, and when that penalty period will end.
    Review historical data for an enrollee, change data, and create new versions of data.
    Register the application for tracking.
    Collect all the application information necessary to make an eligibility determination.
    Determine which household members are requesting assistance and determine household
    composition and size.
    Determine needed verifications and if eligibility can be determined without verifications
    under delayed verification criteria. If eligibility cannot be determined under delayed
    verification criteria, a verification checklist and pending notice should be produced. Tracking
    of the pending period is also required.

Note: More details about delayed verifications and pending periods are listed under Eligibility
      Determination and Case/Enrollee Disposition.

Enrollee Clearance
After the basic household and demographic information about the enrollee(s) have been gathered, the system will
perform an enrollee clearance. This clearance should involve determining if the enrollee is known to the system
and/or if a new unique client identifier (PMI number) is needed. Currently, the establishment of the unique client
identifier (PMI number) is created in the MAXIS system. It is anticipated that this function will remain in the
MAXIS system, but interact seamlessly with the new system.
The clearance process should also include determining if the enrollee is receiving Cash Assistance (MAXIS
interface) and/or other health care benefits that are not included in this system (MAXIS or MMIS interface).

Eligibility Determination Process
The eligibility determination and re-determination function should contain all of the business processes required to
determine which health care programs an enrollee might be eligible for, conduct the automated eligibility
determination, and notify the affected parties and system or sub-systems of the results of the determination. It is
anticipated, for most situations, that the eligibility determination would include all health care programs that an
enrollee is eligible for, with a hierarchy showing those that provide the better benefit sets and federal financial
participation (FFP) funding as first choices. However, the system must also support the ability to choose a specific
health care program, and the determination process should only provide eligibility for that program.
The eligibility determination should include all the business logic needed to perform a decision-tree eligibility
determination and should interface seamlessly with other systems.

Current Eligibility Factors
Listed below are those eligibility factors/data elements that are needed to determine health care eligibility:
                                     Age
The age of the health care applicant/enrollee is considered in determining the appropriate health care benefit level,
and funding source (federal or state) for that enrollee.
                                     Assets
Assets are real property and personal property owned wholly or in part of by the applicant/enrollee. Al1 health care
programs have different asset limits and exclusions.
                                     Asset Transfers
The transfer of an asset without adequate compensation may result in a period of ineligibility for all or some
services. Several factors affect this determination.

Page # 56         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

                                     Authorized Representative
An authorized representative is a person authorized to act on the behalf of the enrollee. An authorized representative
may exercise all the rights and responsibilities of the enrollee. Data elements include:
    Name
    Address
    Phone number
                                     Child Support
Child support is a voluntary or court-ordered payment made by non-custodial parents, for the support of their
children. Child medical support is mandatory for all parents.
                                     Medical Support Referral Data
Elements include:
    Date of referral
    Good cause indicator
    Non-cooperation indicator
                                     Citizenship
U.S. citizens meet the citizenship/immigration requirements for all MHCP, which includes policy not to require
verification of U.S. citizenship. Eligibility for non-citizens depends on the immigration status granted by the
Immigration and Naturalization Service (INS) and, in some cases, the length of time the individual has been in the
United States.
                                     Disability Status
The disability status of the health care applicant/enrollee is considered in determining the health care benefit level,
and funding source (federal or state) for which they are eligible.
                                     Demographic Data
Elements include:
    Location
    County code
    Mailing address
                                     Household Composition
Household composition and size are used to determine whose income to consider when determining financial
eligibility. Household size and income are also used in determining if an enrollee has a financial obligation and if so,
the type and amount of financial obligation.
    Household data
    Relationship of each person to the primary person.
                                     Income Deductions
The household's net income is determined by subtracting deductions and disregards from gross income. Income
deductions differ between federal and state-funded health care programs and, for some health care programs, are not
allowed.
                                     Income – Deeming/allocation
Deeming: To count all or part of the income of people not in the unit as if it were income the unit has received.
Allocation: A deduction from one person’s income for the maintenance needs the unit has received.
The rules for deeming and/or allocation of income differ between health care programs and for some health care
programs, are not allowed. Data elements include:
    Type                                                              Frequency
    Source                                                            Begin and end dates
    Amount

Page # 57         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

                                    Income – Earned
Money received from employment. This includes but is not limited to salaries, wages, tips, commissions, vacation,
and sick pay.
    Type                                                                Frequency
    Source                                                              Begin and end dates
    Amount
                                    Income – Seasonal
Seasonal income is regularly received, but for only part of the year.
    Type                                                                Frequency
    Source                                                              Begin and end dates
    Amount
                                    Income – Self Employment
Self-employment is defined as a situation in which people generally work for themselves, rather than for an
employer, and are responsible for their own work schedule. Self-employed people must file specific schedules as
part of their federal tax returns. Data elements include:
    Type                                                                Frequency
    Source                                                              Begin and end dates
    Amount
                                    Income – Unearned
People receive unearned income without being required to perform any labor or service. Elements include:
    Type                                                                Frequency
    Source                                                              Begin and end dates
    Amount
                                    Financial Aid
Student financial aid includes federal and state work-study income, educational loans, grants, and scholarships.
Some programs exclude financial aid entirely. Other programs count or exclude certain types of financial aid.
    Type                                                                Frequency
    Source                                                              Begin and end dates.
    Amount
                                    Living Arrangements
The eligibility of an enrollee can depend on the enrollee’s living arrangement. Health Care eligibility looks at
enrollees who are living in the community vs. living in an institution.
                                    Other Health Insurance
Determine if any member of the household currently has health insurance. People who have or have had other
current health care coverage in the last four months may not be eligible for some heath care programs. Also, for
some heath care programs, access to employee insurance could be a barrier to health care eligibility. For all health
care programs, information about other heath insurance must be collected for claims processing.
    Source                                                              Begin and end dates
    Type                                                                Deductible amount
                                    Pregnancy
Details of pregnancy of applicant or household member necessary to determine the type of Health Care coverage.
    Conception date                                                     Date of diagnosis
    Due date                                                            Delivery date
Page # 58         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

    Tracking of the 60-day postpartum                                period.
                             State Residency
All of the Health Care programs have some requirements governing people's Minnesota residence. Residency
requirements differ between federal and state-funded Health Care programs.
                                     Student Status
Student status is used in determining if an individual qualifies under dependent sibling criteria and if the earned
income of a child under the age of 19 is counted in a household’s income.
                                     Vehicles
All Health Care programs have provisions to exclude some motor vehicles. If the motor vehicle is not excluded, it is
counted as an asset.

Federal Poverty Guidelines (FFG)
Countable income is used in establishing eligibility and benefit levels. All of the programs begin the determination
with the household’s countable income. The amount of income below which a household of a given size is
considered to be impoverished is called the Federal Poverty Guidelines (FPG). The federal government updates the
FPG annually. For MinnesotaCare and MA type programs, income standards are based on the FPG. FPG standards
currently used are:
    70 PERCENT OF FPG STANDARDS                                      175 PERCENT OF FPG STANDARDS
    75 PERCENT OF FPG STANDARDS                                      185 PERCENT OF FPG STANDARDS
    100 PERCENT OF FPG STANDARDS                                     200 PERCENT OF FPG STANDARDS
    120 PERCENT OF FPG STANDARDS                                     275 PERCENT OF FPG STANDARDS
    135 PERCENT OF FPG STANDARDS                                     280 PERCENT OF FPG STANDARDS
    150 PERCENT OF FPG STANDARDS

Major Programs and Bases of Eligibility/Eligibility Types
The legacy systems, MAXIS and MMIS, currently use a two-character major program and a two-character eligibility
type to identify benefits sets, funding streams, Federal Financial Participation (FFP), Federal and administrative
reporting, and surveillance and utilization review reporting. The new Health Care Automation system must be able
to determine the major program and eligibility type, as well as easily react to legislative changes that require
additional major programs and eligibility types. It is anticipated that the major program, eligibility type, and other
information needed to process medical claims payment would be passed to MMIS via an interface. MMIS would
then handle the medical claims payment.
Note: The Department of Human Services is willing to explore other options for determining and tracking the
          two-character major program.

Current Major Programs
    Major program AC – Alternative Care. Alternative Care (AC) provides funding for home
    care services for people who would otherwise need nursing facility care. People who are
    enrolled in or would be eligible for Medical Assistance (MA) without a spenddown or EW
    waiver obligation are not eligible for AC. Enrollees must be age 65 or older.
    Major Program BB – MinnesotaCare enrollees who are not-parents, regardless of
    citizenship, age 21 or over, whose income is at or below 175% of FPG. This major program
    category does not qualify for FFP and benefit set differs from other MinnesotaCare benefit
    sets. Enrollees qualifying for this program are required to pay a premium.
    Major Program EE – Minnesota Children with Special Health Needs (MCSHN)
    Evaluation. Children with a suspected disability or chronic illness may receive financial

Page # 59         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

  assistance for a diagnostic evaluation without regard to family income. Enrollees must be
  under the age of 21.
  Major Program EG – Emergency General Assistance Medical Care. Non-immigrant and
  undocumented people who have a medical emergency who are not eligible for ongoing MA,
  NM, or GAMC.
  Major Program EM –Emergency Medical Assistance. Non-citizens ineligible for MA due
  to immigration status who have a medical emergency. They must meet an MA basis of
  eligibility and must meet all other MA requirements except citizenship and immigration
  status.
  Major Program FF – MinnesotaCare enrollees who are citizens or qualified non-citizen
  parents, or relative caretakers, age 21 or over, not pregnant, with income at or below 275% of
  FPG. This major program category does qualify for FFP. The percentage of FFP and benefit
  set differs based on the income level. Enrollees qualifying for this program are required to
  pay a premium.
  Major Program GM – General Assistance Medical Care. Enrollees who are not eligible for
  other Federally funded programs. People on GM may be eligible for MinnesotaCare but may
  not be covered on both programs at the same time. This major program does not qualify for
  FFP. The benefit set differs from other Federally funded programs. Enrollees qualifying for
  this program may have a financial obligation called a spenddown.
  Major Program HH – Insurance Extension. Program designed to help people with HIV gain
  access to medical care.
  Major Program IM – Institution of Mental Diseases. Enrollees who are not eligible for
  Medicaid based on their living arrangement. This major program does not qualify for FFP.
  The benefit set is the same as other Medicaid programs. Enrollees qualifying for this program
  may have a financial obligation called a spenddown.
  Major Program JJ – MinnesotaCare enrollees, who are legal guardians, foster parents, non-
  qualified non-citizen parents, or relative caretakers, are 21 or over, non-pregnant and have
  income at or below 275% FPG. This major program category does not qualify for FFP. The
  benefit sets differ based on income level.
  Major Program KK – MinnesotaCare enrollees who are non-qualified non-citizen children,
  and pregnant women. This major program does not qualify for FFP. The benefit set is the
  same as major program LL. Enrollees qualifying for this program are required to pay a
  premium.
  Major Program LL – MinnesotaCare enrollees who are citizens or qualified non-citizen
  children, and pregnant women. This major program category does qualify for FFP. Enrollees
  qualifying for this program are required to pay a premium.
  Major Program MA – Federally funded Medical Assistance (Medicaid). Enrollees who are
  under the age of 21, blind, disabled, a caretaker of a minor child, or over the age of 65.
  Enrollees qualifying for this program may have a financial obligation called a spenddown or
  might be required to pay a premium. This major program category qualifies for FFP.
  Major Program NM – State funded Medical Assistance. Enrollees who are under the age of
  21, blind, disabled, a caretaker of a minor child, or over the age of 65. This program is the

Page # 60    Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

    counterpart of the MA program. Enrollees in this program are not eligible for MA due to
    citizenship/immigration requirements. Enrollees qualifying for this program may have a
    financial obligation called a spenddown. This major program category does not qualify for
    FFP.
    Major Program OO – Consolidated Treatment Fund. Enrollees who reside in chemical
    dependency (CD) residential treatment facilities licensed under Rule 35 who meet eligibility
    criteria are eligible to have treatment costs paid through the Consolidated Chemical
    Dependency Treatment Fund (CCDTF).
    Major Program QM – Qualified Medicare Beneficiary (QMB). Enrollees who are receiving
    Medicare. The QMB program pays some Medicare premiums and co-pays. This major
    program category qualifies for FFP.
    Major Program RM – Refugee Medical Assistance (RMA). Enrollees who are refugees.
    This is a time-limited program with the same benefit set as MA. This program category
    qualifies for 100% FFP.
    Major Program SL – Service Limited Medicare Beneficiary (SLMB). Enrollees who are
    receiving Medicare. The SLMB programs pays part B Medicare premiums. This program
    category qualified for FFP.
    Major Program TT – Minnesota Children with Special Health Needs (MCSHN) treatment.
    Inpatient hospitalization coverage.
    Major Program UN – Funding for screenings not paid for by Alternative Care or waivers.
    Major Program VV – Prescription Drug Program (PDP). Enrollees must be over the age of
    65, blind, or disabled. The PDP program pays for prescriptions, but all enrollees have a
    financial obligation. This program category does not qualify for FFP.
    Major Program WD – Qualified Working Disabled (QWD). Enrollees are employed people
    with disabilities who lost RSDI benefits because of excess income. The QWD program pays
    Medicare Part A premiums only. This program category does qualify for FFP.
    Major Program XX – MinnesotaCare enrollees, non-parent age 21 or over with income
    over 175% FPG and parents or relative caretakers with income over 275% FPG. This
    program category does not qualify for FFP and provides a benefit set that differs from other
    benefit sets.
    New Major Program – There is at least one new type of coverage that has not yet been
    developed on either legacy system. This new type of coverage is called Family Planning. The
    Family Planning program will provide automatic 2-year access to family planning covered
    services for enrollees no longer eligible for MA or MinnesotaCare. This new program will
    also be designed as a stand-alone program for those enrollees not eligible for other health
    care programs.

Current Basis of Eligibility/Eligibility Type
An enrollee’s basis of eligibility for the health care programs may vary depending on certain characteristics. The
relevant characteristics vary by program but may include age, disability, pregnancy, and the presence of children in
the home. For Federally funded programs, the bases of eligibility are based on Federal eligibility categories. The
two-character eligibility type is a way of identifying the basis of eligibility.
Listed below are MinnesotaCare Major Programs with valid eligibility types.

Page # 61        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E


     •        Major program BB, FF, JJ, or XX,
     M1 – Group 1 adult =                An adult who turned 21 years old, but who is in a household with
                                         income at or below 150% of FPG or children grandfathered into
                                         MinnesotaCare from the old CHP program and maintained continuous
                                         MinnesotaCare coverage. The group 1 status remains until the first
                                         renewal after the enrollee turns 21 years old.
     M2 – Group 2 adult =                Adults with children in the household or children in households with
                                         income above 150%.
     M3 – Group 3 adults =                Non-pregnant adults without children in the household.
     •        Major programs FF or JJ
     A1 – Group 1 adult =                An adult who’s income is above 175% up to 275% FPG, who turned 21
                                         years old, but who was in a household with income at or below 150%
                                         of FPG or children grandfather into MinnesotaCare from the old CHP
                                         program and maintained continuous MinnesotaCare coverage. The
                                         group 1 status remains until the first renewal after the enrollee turns 21
                                         years old.
     A2 – Group 2 adult =                Adults with children in the household who’s income is above 200%
                                         and at or below 275% FPG.
     •        Major program FF
     M4 – Adult SCHIP =                  Parent with income above 100% and at or below 175% of FPG
     A4 – Adult SCHIP =                  Parent with income above 175% and at or below 200% FPG.
     •        Major program LL and KK
     I1 – Group 1 infant =             Child, age 0 to age 2, in a household with income at or below 150% of
                                       FPG.
     I2 – Group 2 infant =             Child, age 0 to age 2, in a household with income above 150% of FPG.
     C1 – Group 1 child =              Child, age 2 to 21, in a household with income at or below 150% of
                                       FPG or grandfathered in.
     C2 – Group 2 child =              Child, age 2 to 21, in a household with income above 150% of FPG.
     P1 – Group 1 =                    A pregnant woman under the age of 21 with income at or below 150%
                                       of FPG. Or, a pregnant woman over the age of 21 who turned 21 years
                                       old, but who is or was in a household with income at or below 150% of
                                       FPG or children grandfather into MinnesotaCare from the old CHP
                                       program and maintained continuous MinnesotaCare coverage. The
                                       group 1 status remains until the first renewal after the enrollee turns 21
                                       years old.
     P2 – Group 2 =                    A pregnant woman.
     Other Major Programs with valid eligibility types:
     •        Major program AC
     AC – Alternative Care
     •        Major program GM and Emergency GM.
     GF – Enrollee has children
     GS – Enrollee does not have children
     06 – Enrollee is receiving the cash assistance program of General Assistance (GA).
     •        Major program EE
     SE – MCSHN
     •        Major program HH
     DD – Drugs/Dental Coverage                                     DE – Dental Coverage only

Page # 62    Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

      DN – Dental and Nutrition coverage                  NR – Nutrition/Drugs
      HI – Drugs/Dental/Nutrition                         NT – Nutrition only
      IN – Insurance Extension                            RX – Drugs only
      •       Major program IM, MA, NM, or Emergency MA
      AA – Parent of a Dependent Child                    14 – 6 to 12 Month Extended Medical
      BT - Blind/TEFRA                                    15 – 1619A – Employed Disabled SSI
      BX – Blind                                          Status
      DX – Disabled                                       16 – 1619B – Employed Disabled SSI Status
      1A – MFIP Participant                               25 – IV-E Foster Care
      13 – 4 Month Extended Medical
      •       Major program MA or NM, or Emergency MA
      CB – Infant to Age 2                                DI – Employed Disabled with no premium
      CK – Children Ages through 18                       DP – Employed Disabled with premium
      CM – Age 21 through 22 year old IMD                 DT – Disabled/TEFRA
      resident (was in the IMD when turned 21             EX – Age 65 and Over
      years old)                                          10 - Minnesota Adoption Assistance
      CX – Children Ages 19 and 20                        11 – Automatic Newborn Eligibility
      DC – Disabled/Child age 18 through 20               25 – IV-E Foster Care
      •       Major program MA or NM
      PX – Pregnant Women
      •       Major program OO
      SA – Consolidated Treatment Fund
      •       Major program QM
      BQ – Blind/QMB only
      DQ- Disabled/QMB only
      EQ – Over 65/QMB only
      •       Major program RM
      RM – Refugee Medical
      RU – Refugee Unaccompanied Minor
      02 – Refugee Cash
      21 – Refugee Extended Medical
      •       Major program SL
      BS – Blind/SLMB                                     1B – Blind Qualified Individual QI-1
      DS – Disabled/SLMB                                  1D – Disabled Qualified Individual QI –1
      ES – Elderly/SLMB                                   1E – Aged Qualified Individual QI–1
      •       Major program TT
      SC – MCSHN Care Plan                                SG – MCSHN General Care
      •       Major program UN
      UN - Screening payment only
      •       Major program VV
      SD – Senior Drug
  •           Major program WD
      DW – Disabled/QWD


Page # 63     Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E


Enrollee Financial Obligation
For some health care programs, the enrollee is required to share in the cost of the health care benefit. The type and
amount of financial obligation varies depending on the health care program. There are currently 3 different types of
financial obligation; premium payment, spenddown obligation, and/or co-payments.
Spenddown   =              A method available to people that do not qualify for MA, NMED or GAMC due to
                           excess income. Enrollees may become eligible by incurring medical expenses equal to or
                           greater than the excess income for a 1-month or 6-month period. Spenddowns can be
                           applied by granting mid-month coverage with the enrollee paying the bills incurred prior
                           to meeting the spenddown amount or by having the enrollee pay specific monthly amount
                           directly to the health care provider or long term care facility. The spenddown related
                           information is needed by MMIS to insure claims payment processing works correctly.
Premium payment =          A calculated amount based on income and household size. Depending on the type of
                           health care program, this amount could reflect coverage for an individual enrollee or for
                           several enrollees. For some health care programs, coverage does not begin until the
                           payment is made.
Co-Payments =              A fixed amount that an enrollee is required to pay for each episode of a particular
                           treatment, medical supply, or equipment.
Medical Bills to Meet a Spenddown:
If an enrollee has a spenddown, they must be able to demonstrate that there are unpaid Medical bills equal to or
greater then the spenddown amount that have not been used previously to meet a spenddown.

Hierarchy for Major Programs
As previously stated, the system should support a eligibility determination for all health care benefits that an
enrollee might be eligible for, but rule out some heath care programs based on a hierarchy process. Generally, heath
care programs with Federal funding (FFP) and/or those that provide better heath care coverage should be displayed
as the preferable option.

Hierarchy for Eligibility Bases/Eligibility Types
It is possible for an enrollee to have more than one basis of eligibility for MA/NMED. The system should support an
eligibility determination that reviews all the basis of eligibility and awards that one that is the most advantageous.

Major Program Overlap Rules
Health care program rules allow some heath care major programs/benefits to have concurrent coverage while others
are prohibited. The system must be designed to prohibit concurrent eligibility when appropriate and must provide an
automated approach to the closing of some health care eligibility when other health care coverage is awarded.

Other Health Care Factors
                                    Managed Care/Health Plan Enrollment
For some health care programs and/or enrollees, enrollment in a managed care plan is mandatory, while for others it
is optional or not currently allowed. For those enrollees who are mandatory or optional for enrollment, the available
managed care plans differ based on county of residence and type of health care program. The actual managed care
provider listing and enrollment process is currently in the MMIS system, and it is anticipated that this process will
remain in MMIS. In order to present a consistent look and feel for the user, the new eligibility system must support a
seamless interface for the managed care enrollment process.
                                  All or Nothing Rule, Three Generation Households, and Other
                           Specific Health Care Program Requirements
Some health care programs require that specific household members enroll, even if the member is not requesting
assistance. The system must be able to support these types of health care program rules.




Page # 64         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

                                  Verifications, Verification Checklist, Delayed Verification, and
                            Time Extended Verifications
For some eligibility factors/data, verification of the reported information is required (i.e., income, citizenship – if not
U.S. citizen, etc). For those factors that require verification, the system should be able to:
    Produce a verification checklist/notice of factors that require verification and mail this
    checklist to the enrollee.
    Allow the worker to update the system to reflect when verifications are received and
    complete an eligibility determination if appropriate.
    Track needed verification and alert/notify the worker and/or enrollee at pre-defined intervals.
    Insure that future verification checklists/notices only reflect only the remaining outstanding
    verifications.

Delayed verification is defined as – A process for granting eligibility to applicants before
verifying all mandatory eligibility factors. The system must support delayed verification in the
follow manner:
    Based on the data collected and the delayed verification rules, the system must be able to
    determine if eligibility can be granted using delayed verification criteria.
    Track the delayed verification period and systematically close or deny coverage if
    verifications are not received timely.
    Time extended verifications. There are some verifications that are not needed at the time
    eligibility is determined, but are needed for on-going coverage (e.g. pregnancy and
    immigration). The system must support the tracking of these types of verifications.
                                     Time Limits
Eligibility for some health care programs can only be granted for specific periods of time. For those health care
programs that are time limited, the system must be able to track the specific time period and notify the worker and/or
systematically close coverage or change coverage when the time limit is reached. Part of systematic change would
include enrollee notification and MMIS interface.
                                     Penalty Periods
Some health care programs impose time limited penalty periods based on failure to comply with health care program
rules. For those health care programs that have penalty periods, the system must be able to identify, track, and
systematically impose penalty periods when appropriate.

Processing Health Care Coverage
The system must be able to determine and re-determine eligibility for Health Care enrollees during the initial
application, renewals, and for interim changes. The results for some of the eligibility determination would be
displayed for the worker’s authorization, while others would be systematically processed without worker
authorization. Further definition of these processes are listed below:

Coverage Disposition
The valid dispositions are pending, deny, approve, or close.
         Pending -        All information to determine eligibility is not provided and the applicant is not eligible
                          under Delayed Verification or eligibility has been determined, but eligibility can not be
                          granted without a client obligation payment.
         Approve –        All information has been provided and coverage is granted. The appropriate information
                          would need to be passed to MMIS for claims payment.
         Deny –           At initial application, the enrollee is not eligible for any health care programs or
                          information to determine eligibility was not provided within required timeframe.
         Close -          Enrollee circumstances have changed and/or needed information is not provided.

Page # 65         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E


Notices
Notices will be system generated based on system processes. All coverage dispositions and/or changes in coverage
will require enrollee notification. The notices should be customized to include:
    Different text for different coverage types and within each coverage type produce different
    text for various actions (e. g. an enrollee can be closed for multiple reasons, the notice must
    reflect text to identify each reason),
    Be produced in different languages based on the enrollee’s language of choice,
    Allow for additional comments to be added to the notice text,
    Offer the flexibility to change standard text format without programmer intervention,
    On-line access to notices that were produced in the past,
    The ability to reproduce notices that were produced in the past and the ability to route these
    notices to the worker and/or re-mail to the enrollee,
    The ability to send multiple notices for different household member in one envelope if the
    mailing address is the same, and
    Notices sent to both enrollee and authorized representative when appropriate.
    It is anticipated that the enrollee will be able to select how he/she would prefer to be
    contacted e.g. mail, in person, e-mail. This might include the need to send notices via web e-
    mail.

Renewals
Renewal is defined as the process of re-determining eligibility for Health Care enrollees. The system must create the
renewal with preprinted information about the enrollee, mail the renewal, and track the due date of the renewal. If
renewal information is not received timely, the system must close coverage and interface the closing of the coverage
to MMIS. If the form is received, the system must support the input of new data and the re-determination of
eligibility. There are two types of renewals:
    Six -Month Renewal – This type of renewal is only required for certain types of Health Care
    coverage.
    Annual Renewals – This type of renewal is required for most Health Care coverage.

Monthly and/or Quarterly Reports
Enrollees that are eligible for MA, NMED, or GAMC with certain types of spenddowns are required to complete
monthly and/or quarterly reports. The system must support the process of mailing the form, tracking the form, and
the ability to re-determine eligibility based on information provided on the form.

Interim Changes
The system must be able to record, maintain history, and support interim changes and when appropriate, interface
these changes to the MMIS. The changes could be any or all of the health care factors/data that is used to determine
eligibility. Depending on the health care program, some data would be stored for future reference while others
would require a redetermination of health care coverage.
The system must support the ability to retroactively change factors/data and when appropriate, complete a
retroactive re-determine of eligibility. If the retroactive re-determination of eligibility is allowed, this process might
include interfacing the changes to the MMIS.




Page # 66         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E


Appeals
Changes in health care coverage, that negatively impact an enrollee’s health care coverage, can be appealed. In some
instances, enrollees can continue the health care coverage pending the outcome of the appeal. The system must have
the flexibility to continue coverage based on an appeal and also store the date, status, resolution, and type of appeal.




Automated Periodic Processes/Execution of Mass Change
There are many processes that should occur without worker intervention. Examples of those processes:
                                    Aging Criteria:
The age of an enrollee, pregnancy status, and/or disability status are factors in determining Health Care benefits.
Therefore, when an enrollee reaches certain ages, is no longer pregnant, or is no longer disabled they may not be
eligible for the same type of coverage or basis of eligibility. For some Health Care programs, the redetermination of
coverage must be automated with processes, notices, and interfaces occurring without worker or enrollee
intervention. For others, worker alerts must be developed.
                                    Automated Opening:
For those major programs that require a premium payment for heath care coverage, the system should support the
automated opening of the health care program when payment is received. This would include notice requirements
and interfaces to MMIS and other systems.
                                    Automated Denying:
Based on major program rules, enrollees only have a specific amount of time to provide required information needed
to determine heath care eligibility, or pay enrollee obligations. If verifications are not received or financial
obligations are not paid within the allotted time, the system must support the denying of eligibility.
                                    Automated Closing:
There are several situations in which an enrollee could be closed. Whenever possible, the system should support an
automated approach that would not require worker intervention. Examples of those processes that should not require
worker intervention:
    Failure to returned renewal, monthly and/or quarterly income reporting forms
    Failure to pay the required premium amount by the due date.
    Failure to cooperate with county child support office.
                                    Automated Re-Opening:
If an enrollee is closed for failure to pay a premium and that premium is received by the health care program
deadline date, the system should reopen the eligibility without worker intervention.
                                    Annual FPG Changes:
Annually the Federal Poverty Guidelines (FPG) standards change. The system should be designed to account for this
annual change without worker intervention and with minimal technical support.




General Workflow Functions
Examples of general workflow management functions:

Case/Person Notes
   The ability for the worker to complete and store notes at the case and person level. For those
   notes stored at the person level, the notes would be transferred as appropriate when an
   individual moves from one household to another.



Page # 67         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

    The ability for the system to create case/person notes based on automated periodic
    processing.

Worker Alerts
  System generated alerts to notify the worker of actions required.
    Worker set alerts that allow the worker to set reminders to themselves to aid in case and time
    management.
    System generated alerts to identify inconsistencies in data within the system and/or within
    our systems (e. g. the MMIS).
    System generated alerts based on MMIS claims payments and/or interfaces from other
    systems to MMIS.

Case/Workload Management
   The ability to assign and reassign enrollees/cases to workers
    The ability to reassign workers to caseloads
    The ability to view, online, notices that have previously been generated.
    The ability to complete a system-wide searches to determine if an enrollee has or had
    coverage.

Worker Online Reports
  The ability to view a listing of all cases/enrollees that are assigned to specific workers. This
  would include a breakdown of those cases/enrollees that are active, pending, denied, or
  closed.
    The ability to view the current status of a case and/or enrollee.
    A listing of all cases/enrollees, by worker, that are closing for the end of the month and the
    reason for the closing.
    A listing of cases/enrollees that have a renewal due.
    Supervisory reports.

Online and Field Level Screen Help
On-line and field level screen help should include a list of valid values as well as a link to the health care manual
and user manual were appropriate.


SYSTEM NAVIGATION:                                                   Similar screen format that is attractive
    Screen to screen                                                 and uniform
    Menus                                                            Elimination of re-keying of data.
    Icons
    Pick lists
    Copy fields


Page # 68         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E


BUILT-IN-EDITS:                                                      Edits related to data in other systems
    Online                                                           (e. g. the MMIS).
    Cross-screen

Reports
In addition to the worker online reports, it is anticipated that a variety of other online and printed reports will be
needed. Some of the reporting criteria might include information from the MMIS system. An example of the types
of reports needed:
    Federal reports
    State reports
    Department reports
    Management reports including caseload, financial, and statistical reports

Accounts Receivable
Several health care benefits require or allow the enrollee to pay premium as the financial obligation for the health
care benefit. Currently, the process of billing and collecting premiums is in the MMIS system, but it is anticipated
that this process will be on the new system. Some of the components of the accounts receivable system are:
    The accounts receivable system should follow basic accounting practices and should be easy
    to read and understand.
    It should be designed to accommodate adding new health care premium-based programs,
    with their specific rule, with minimal technical resources.
    It should interact seamlessly with the eligibility system and systematically open and close
    heath care enrollee eligibility for those health care programs that are dependent upon
    premium payment.
    It will provide daily and monthly billing processes that will calculate the premium payment
    and send a billing notice. The billing notice will include and OCR line that can be used by
    Financial Management’s WAUSAU check scanner.
    It should have the ability to send a duplicate of the premium notice to several individuals
    (e.g. the enrollee, authorized representative, and the individual managing the enrollee’s
    funds).
    When the premium payment is received, it will interact seamlessly with the WAUSAU check
    scanner to receive the payment information.
    It will interface seamlessly with State-Wide Accounting
    It will include the ability to make payments via automatic withdrawal, credit cards, EBT, and
    tax refunds.
    It will include the ability to track and refund credits.
    It should have the ability to deal with payments returned for non-sufficient funds.
    It should interactive seamlessly with the IVR to provide voice response about billing and
    payments.
    Create worker alerts when appropriate.


Page # 69         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

                                Current Health Care Benefits That Allow or Require Premium
                          Payments:
Listed below are those health care benefits that either require or allow for premium payment and an overview of
some of the requirements of those programs.
MinnesotaCare (MCRE):
    Regular MinnesotaCare: One premium amount is calculated for members of the household.
    Coverage cannot begin until the premium is paid. If unpaid premiums exist from previous
    coverage, this amount also must be paid prior to coverage beginning. If household size and/or
    income change prior to the receipt of the payment, a rebilling process occurs. The enrollees
    have 4 months to pay the initial premium, if not paid within 4 months, coverage is denied and
    no enrollee obligation would exist for the initial premium month. If the premium is paid and
    coverage begins, the household is billed monthly. Once approved for on-going coverage, if
    income and/or household size changes, and these change results in a decreased premium, the
    premium amount is recalculated for all future months and any money already applied to those
    months is reallocated. If ongoing coverage premiums are not paid by the due date, health care
    coverage must be closed. If premium payment is received by the 20th day of the month after
    coverage is closed, coverage is reinstated back to the date of closing.
    Retroactive MinnesotaCare: For enrollees who apply for MinnesotaCare within 30 days of
    the closing of Medicaid, the enrollee can choose to have retroactive MinnesotaCare that will
    eliminate any gaps in coverage. This option is only allowed if all verifications of health care
    eligibility are received within 30 days and the MinnesotaCare premium is also received
    within 30 days. The premium billing for the retroactive month(s) would include a 30 day due
    date and if the payment is not received within that timeframe, the enrollee would be denied
    retroactive coverage and no enrollee obligation would exist for the retroactive month(s). The
    regular MCRE coverage is not affected by retroactive MCRE.
Medical Assistance (MA):
    Client Option Spenddown (COS): Enrollees have the option of paying the monthly
    spenddown amount directly to the State. If this option were selected, a monthly billing
    process would occur. Whether the enrollee pays this premium or does not pay this premium
    does not impact the opening or closing of health care coverage. If paid, the data related to the
    amount paid must interface to the MMIS to insure claims payment process occurs correctly.
    For those enrollees that do not pay the premium, no obligation exists because the enrollee
    would then be required to make this payment directly to the health care provider.
    Client Option Spenddown requires that 18 months after the enrollee paid the premium, the
    premium amount is reconciled with the total amount of claims payment that occurred for that
    month. If the premium amount paid is greater than the claims amount paid, a refund is
    required.
    Employed Persons with Disabilities (EPD). The MA-EPD rule requires that each enrollee
    eligible for this program pay a premium before coverage begins. Once coverage begins,
    monthly billing would occur and if payment is not made by the due date, health care
    coverage must be closed. If payment is received by the last day of the month in which the
    payment was due, then coverage must to reinstated back to the date of closing.

Security
The overall storage of data must comply with HIPAA regulations. In addition, security should include:

Page # 70        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX E

User Level Security
   Cases will be assigned based on the service location of the enrollee and type of case.
    Unless case information is “masked”, allow all workers to view enrollee/case information but
    do not allow updates unless the worker resides in the same service location.
    Allow user helpdesk staff and other State staff to access and update all data.
    The ability to limit eligibility determination and access by user profile.

Masking of Data
The system must include the ability to “Mask” (not display information) at the person and case level. This would
include the ability to:
    Mask all enrollee data and only allow a limited number of users to access the data.
    Mask all enrollee data from all users except the worker and supervisor assigned to the case.
    Mask all enrollee data from all workers except those workers that have the same service
    location.

Enrollee Access to Eligibility Information
Enrollees should have the ability to access some health care eligibility information via the web. This access should
include the ability to view the information in his/her language of choice.




Page # 71         Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX F



Appendix F: DHS Technology and Systems

Overview
DHS uses technology to manage health and human services programs in Minnesota, and to enable counties and
regional facilities to deliver benefits and services directly to citizens. DHS needs accurate, timely and complete
information about who our clients are, what their needs are, and how to determine which programs can help meet
those needs. DHS invests in technology to:
    Better enable our clients to manage their own affairs
    Control growth in costs of service-intensive health and human services areas
    Improve quality and consistency of decisions, and
    Automate routine, time-consuming tasks that detract from service levels.

DHS Core Systems
DHS operates four major information systems to provide the majority of the agency’s benefits and services to
Minnesota’s counties and citizens:
1. MAXIS is used to determine eligibility and issue cash assistance and food benefits, and
   determine eligibility for medical benefits. MAXIS issues notices to clients on changes in
   eligibility and benefits, supports monitoring for fraud and overpayment collections, and
   provides data for state and federal reporting. (The Electronic Benefits Transfer system, or
   EBT, operates within the MAXIS environment.) The system is a mainframe application, IBM
   3090 platform located at InterTech, NATURAL and COBOL programming languages,
   ADABAS database platform. Communication is through the State's leased-line private
   network, MNET via 3270 terminal emulation using TCP/IP protocol.
2. The Medicaid Management Information System (MMIS) pays medical bills and managed
   care capitation payments for health care program enrollees, helps assure that quality care is
   being provided, assists investigators in detecting medical fraud and maintains critical data
   claims for Medicaid recipients and other State medical insurance programs. The system is a
   mainframe application, IBM 3090 platform located at InterTech, COBOL programming
   language and uses a VSAM file structure. Communication is through the State's leased-line
   private network, MNET via 3270 terminal emulation using TCP/IP protocol.
3. PRISM supports Minnesota’s child enforcement program to locate missing non-custodial
   parents, implements automatic withholding from employers, and enforces child support
   orders. PRISM supports centralized reporting and disbursing of child support payments as
   required by federal law. PRISM is a mainframe-based system, running on InterTech’s IBM
   3090. It uses an ADABAS database management system, NATURAL programming
   language, and CONSTRUCT code generator. Communications are provided via MNET.
   County workstations are primarily Windows 95 Pentium PC, running the application through
   IBM 3270 terminal emulation using TCP/IP.
4. The Social Services Information System (SSIS) tracks reports and investigations of child
   maltreatment and assists county social workers with all aspects of child protection, out-of-
   home placement, child welfare, children’s mental health and other social services case
   management. SSIS also tracks child welfare performance indicators and collects data for
   required federal and state reporting. SSIS is a distributed, 3-tier county-based client-server

Page # 72        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX F

    application developed in Delphi and using an Oracle database. It uses Windows NT server
    with TCP/IP communications to clients in counties. Clients within the county are configured
    with Windows 95, a PC of at least 133-166 MHz processing speed, 16-32 MB RAM, and 1-2
    GB hard drive. Secure data communications to DHS are provided via Mnet, using TCP/IP for
    county data exchange to the central DHS data repository.

DHS manages a major investment in technology to maintain these four core information systems
which automate key elements of human services business operations and program policy. These
systems operate in partnership with counties to coordinate efforts for program operations, and
have proven capable of responding to constant program changes. DHS also maintains a data
warehouse which, though not in and of itself a computer system, enables both DHS and county
staff to analyze and understand data gathered from these systems and identify trends in human
services delivery.
              5.6.3            Health Care Operations In-House system
A major in-house, server based Health Care Operations system is currently being implemented at DHS. This is the
preferred environment if the business case study supports an in-house solution.
The E-Commerce development environment consists of six programmers developing applications in Java (J2EE ver
1.3), Powerbuilder, and Cold Fusion. Utilizing standard life cycle methodology, we develop within a unit, systems,
and acceptance testing environment. Although we do maintain approximately 20 NT servers, our main platform is
Sun as described below.
    The technical components of this system include a JAVA based front end in a Sun Solaris
    server environment using J2E Websphere application code (JAVA scripting, Servelets and
    EJB’s), Cold Fusion MX, Cisco routers, Pix firewalls, Mercator X12 translator, CICS
    Transaction Gateway middleware product set, MZ Series Data Transport, secure HTPS and
    FTPS, F5-Big IP and 3DNS, integration with the FileNet Document Management systems
    (Solaris or Microsoft operating environments), and probable authentication/certification
    using Netegrity.
    Visual SourceSafe is used for change control and DHS adheres to a prescribed approach to
    development. The toolset consists of Websphere Studio and Application Server IE 4.1, MQ
    Series, CICS Transaction Gateway, Mercator X12 Translator, centered around Oracle 9i.

Networks, Communications, and Workstations
The DHS technology model includes a wide area network (WAN) and local area networks (LAN) on MNet (DHS
Internal LAN/WAN) and DHS/County workstations. MNet is the State of Minnesota’s private, leased-line network,
used by DHS to connect to its county business partners. The network offers access to the backbone through 13 nodes
located throughout the State. The network is monitored and administered centrally through the InterTechnologies
Group of the Department of Administration. A secure, closed T-1 connection to every county seat supports DHS’
major system applications at the county level. Connection to users beyond the county seat (i.e., satellite offices)
varies among counties and is dependent upon local service provision.
The DHS LAN/WAN links together workstations and servers in a number of locations. The Department uses a
combination of 56kb, T-1, 10MBPS LAN, T-1 Copper and Gigabit Fiber connections to link locations in the Twin
Cities, Rochester, Duluth, and Saint Cloud. The major system applications are supported via TN3270 connections.
DHS provides workstations to its county workers who support the MAXIS and PRISM/Child Support mainframe
applications. The workstations specification currently in DHS is an IBM 6285-0AN PC 300 GL Mini Tower, 64 MB
RAM, 3.5 GB hard drive, 32X CD-ROM, IBM E-communication version 4.21, IBM Ethernet or IBM Token Ring
cards, running Windows NT.




Page # 73        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX G



Appendix G: Legacy System Interface Requirements
Legacy         Situation                                                                  Programs                           Interface Requirements
System




                                                                                                            MNCare
                                                                                                     GAMC




                                                                                                                     Other
                                                                                  Freq.
                                                                           Type




                                                                                                MA
                                                                                          All
MMIS           Enrollee data – New or update                               4      1, 2    X                                  Initial enrollee data and updates of enrollee data.
MAXIS/MMIS     Reconciliation                                              5              X                                  Reconciles demographic data and eligibility status
                                                                                                                             between systems. Will become obsolete with full
                                                                                                                             automation of all health care programs.
County                                                                     4      7                                          Current enrollee data. Mainly FTP. Maybe some tape.
Systems
Health Plans                                                                      5                                          New enrollee data. Demographic data changes – living
(MDOH)                                                                                                                       arrangements – might lose eligibility.
MMIS                                                                              5                                          Data needed by MMIS for Claims Payment and
                                                                                                                             associated tasks.
DHS Cashier    Payments are received by DHS                                2      2                         X        1       Receipts need to be processed by the A/R sub system.
(Wausaw)
Elect Funds    Automatic payment of premiums.                              4      7                                          Sends request for payment to a central point that
Xfer                                                                                                                         requests money from accounts at banks.
DCFL           (Express Lane Eligibility) School districts will identify   2      6                                          Date of birth, SSN, Sex, Portion of Name
               students eligible for reduced lunches.
DCFL           Same as previous                                            4                                                 Return of “match” or “no match” status.
EIS            Data transfer to data warehouse                             4      7       X
DES            Unemployment                                                3      7       X                                  Must display the date and amount of last unemployment
               (We will send DATA to DES, and will update and store                                                          benefits issued during the period, and the amount of
               the information we receive back)                                                                              unemployment benefits paid to date on this
                                                                                                                             (unemployment benefit) claim.
DES            Earnings/wages                                              3      7       X                                  Must display employer reported wage information,
               (We will send DATA to DES, and will update and store                                                          including amount of wages reported for the specified
               the information we receive back)                                                                              quarter and year, and name and address of employer
                                                                                                                             reporting the information.
IRS            Unearned Income                                             3      7       X                                  Must display unearned income information reported on
               (We will send DATA to IRS, and will update and store                                                          federal tax return forms by the PAYER of the income.
               the information we receive back)                                                                              Examples of income include dividends, interest, pension
                                                                                                                             distributions, and gross winnings.
MAXIS          New client. Not in system.                                  1      1       X                                  Must obtain PMI number.

Page # 74      Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX G

                                                                                    Programs
MAXIS           Enrollee receiving MFIP or RCA cash assistance         3     1      X                      Must display what type of cash assistance enrollee is
                                                                                                           receiving
PRISM           Child support referral information, disbursement       3/4   7           X                 Must display Absent Parent name, SSN, DOB, sex,
                information                                                                                address, and phone, and references a particular child or
                                                                                                           children and his/her m/paternity.
PRISM           Absent Parent cooperation, court order status,         3/4   7           X                 Must display Absent Parent name, SSN, DOB, sex,
                disbursement information                                                                   address, and phone, and references a particular child or
                                                                                                           children and his/her m/paternity. Cooperation,
                                                                                                           disbursement, and court order information
SSA             SSI program status and income data                     3     2      X                      Must display application and eligibility effective dates, a      Comment:
                (We will send DATA to SSA, and will update and store                                       summary of asset (resource) information per SSA
                the information we receive back)                                                           records, and a summary of income information that                Comment: All SSA quires can be
                                                                                                           shows the amount of SSI for which the person is eligible         worker initiated to run in an over night
                                                                                                           and the amount of SSI paid.                                      batch job.
SSA             Work quarters for non-citizens                         3     ??     X                      Must display the number of work quarters that the Social
                (We will send DATA to SSA, and will update and store                                       Security Administration record states enrollee has
                the information we receive back)                                                           earned from 01/97.
SSA             RSDI status and income data                            3     7      X                      Must display according to Social Security Number (SSN)
                (We will send DATA to SSA, and will update and store                                       and benefit month, and includes matched person's claim
                the information we receive back)                                                           number, amount of Social Security benefits, date of
                                                                                                           entitlement, status of Supplemental Security Income
                                                                                                           (SSI) eligibility, Medicare information, status of eligibility
                                                                                                           for Railroad Retirement benefits and date of disability (if
                                                                                                           applicable).
SSA             SSN enumeration                                        3     7      X                      Name, DOB, SSN
                (We will send DATA to SSA, and will update and store
                the information we receive back)
Questionable:
MMIS            Establishing and updating Case data                    4     1, 2        X?    ?   ?   2   New or updated Case Data.
?               Duplicate accounts exist. Need to merge into one.      5
                (MAXIS tells MMIS now)
PRISM           Passes absent parent data                              2     2,7    X                      ?
MMIS            Eligibility closes (MAXIS sends now to MMIS)           4     7      X                      Will new system need to do the same?
CMS             CMS sends a file to DHS of people that are eligible                                        Does Medicare eligibility as identified by CMS affect Re-
                Medicare and Medicaid                                                                      determination of medical eligibility?
Health Plans    Might only be HIPPA                                    4     7                             Eligibility Begin and End Dates. (?occurrences?)
Like BC/BS
CMS             Passing Medicare data back and forth                   5     7                             Will the new system need this data?



Page # 75       Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX G

                                                                                     Programs
Recipient       Archiving of transaction data                           4      2     X                                 Will new system merge in or be separate.
History


                                   Legacy Systems:
EIS, MAXIS, MMIS, SSIS, PRISM, Dept of Children and Families Learning IS, Dept of Economic Security IS, Dept of Rev.
                            Interface Types:
    New System requesting data from Legacy System (PMI Number from MAXIS).
    New System receiving unsolicited data from Legacy System.
    New System requesting validation/verification from Legacy System.
    New System passing data to Legacy System.
    Data needed by more than one of the following: New System, MAXIS, MMIS. Data strategy from design of New System will determine location
    or replication.
                                   Frequency:
1. Immediate. 2. Daily/nightly. 3. Weekly. 4. Every two weeks. 5. Twice a month. 6. Three times a month. 7. Monthly.
                                   Programs – Other:
1. Client Option. 2. HIV, CD, Alternate Care




Page # 76        Revised 10/2004
of CFMS #
Health Care Automation RFP—APPENDIX H



Appendix H: Health Care Automation Work Group
   Descriptions
Workgroup                          Purpose
Communications –                   Develop and implement communication strategies for various
                                   groups affected by HCA, including messages for DHS
                                   mgmt./staff, counties, Legislators and general (nonrecipient)
                                   public.
Financial Controls—                Analyze impacts of new system technology on MMIS accounting
                                   functions; make recommendations for new system functionality
                                   and legacy system changes.
Health Care Policy (Programs for   Integrate existing and new E/DA policy into the HCA technical
Elderly/Disabled Adults)—          product.
Health Care Policy (Programs for   Integrate existing and new FWC policy into the HCA technical
Families with Children)—           product.
Human Resources—                   Work with HR-related issues around HCA, including
                                   development of new positions, transitioning of staff, union issues,
                                   etc.
Interfaces/Data Exchange—          Determine interface issues existing between HCA and DHS
                                   systems, and plan changes for data exchanges.
MMIS Technical—                    Ensure the integration between new system and existing MMIS
                                   functionality.
Performance Management Quality     Ensure the new system has processes in place for performance
Initiatives—                       measurement.
Privacy/Data Security—             Ensure that HCA meets the requirements of HIPAA, Minnesota
                                   Data Privacy Act, and other similar federal/state initiatives.
Reports and Forecasts—             Incorporate financial management and reporting needs and
                                   principles into HCA development and implementation.
Training—                          Identify training needs, develop curriculum and provide new
                                   system training to users (county workers, state staff, MNCare
                                   enrolment reps, etc.).
User Groups—                       Identify user groups, and provide opportunities for input to
                                   ensure that new system meets user needs.
Web Technology—                    Ensure the best use of web products and technology for HCA,
                                   and integrate DHS and State web standards and requirements into
                                   HCA project.
See www.dhs.state.mn.us/aboutdhs/pdf/DHS-ORG.pdf for DHS Organization Chart
information.




Page # 77       Revised 10/2004
of CFMS #
Appendix I: Capability Maturity Model for Software
The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of
the software processes of an organization and for identifying the key practices that are required to increase
the maturity of these processes.
The SW-CMM has been developed by the software community with stewardship by the Software
Engineering Institute (SEI) at Carnegie Mellon University. The Software CMM has become a de facto
standard for assessing and improving software processes. Through the SW-CMM, the SEI and community
have put in place an effective means for modeling, defining, and measuring the maturity of the processes
used by software professionals.
The Capability Maturity Model for Software describes the principles and practices underlying software
process maturity and is intended to help software organizations improve the maturity of their software
processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software
processes. The CMM is organized into five maturity levels:




                                                                    (from www.sei.cmu.edu/cmm)
1.   Initial. The software process is characterized as ad hoc, and occasionally even chaotic. Few processes
     are defined, and success depends on individual effort and heroics.
2.   Repeatable. Basic project management processes are established to track cost, schedule, and
     functionality. The necessary process discipline is in place to repeat earlier successes on projects with
     similar applications.
3.   Defined. The software process for both management and engineering activities is documented,
     standardized, and integrated into a standard software process for the organization. All projects use an
     approved, tailored version of the organization's standard software process for developing and
     maintaining software.
4.   Managed. Detailed measures of the software process and product quality are collected. Both the
     software process and products are quantitatively understood and controlled.
5.   Optimizing. Continuous process improvement is enabled by quantitative feedback from the process
     and from piloting innovative ideas and technologies.

Predictability, effectiveness, and control of an organization's software processes are believed to improve as
the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this
belief.
Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas
an organization should focus on to improve its software process.


Page # 78         Revised 10/2004
of CFMS #
The key process areas at Level 2 focus on the software project's concerns related to establishing basic
project management controls. They are Requirements Management, Software Project Planning, Software
Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and
Software Configuration Management.
The key process areas at Level 3 address both project and organizational issues, as the organization
establishes an infrastructure that institutionalizes effective software engineering and management processes
across all projects. They are Organization Process Focus, Organization Process Definition, Training
Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and
Peer Reviews.
The key process areas at Level 4 focus on establishing a quantitative understanding of both the software
process and the software work products being built. They are Quantitative Process Management and
Software Quality Management.
The key process areas at Level 5 cover the issues that both the organization and the projects must address to
implement continual, measurable software process improvement. They are Defect Prevention, Technology
Change Management, and Process Change Management.
Each key process area is described in terms of the key practices that contribute to satisfying its goals. The
key practices describe the infrastructure and activities that contribute most to the effective implementation
and institutionalization of the key process area.
For a more detailed overview of the CMM, see Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles
V. Weber, "Capability Maturity Model, Version 1.1," IEEE Software, Vol. 10, No. 4, July 1993, pp. 18-27.




Page # 79        Revised 10/2004
of CFMS #
Appendix J: DHS Online Reference Document Library
An Online Reference Document Library for this project has been established, containing project-related information
and documents not included in this RFP. Some of these documents are listed below and will be placed in PDF
format in this library. The State may place additional documents in the online library after the publication of this
RFP. It is the intent of DHS to make this information available to all proposers.
1. KPMG assessment documents of the automation of MinnesotaCare processes
    (See Section 1.2: Background)
    —Health Care Business Model
    —Current Technology Model
    —Business Strategy and Objectives
    —MinnesotaCare Focus Areas
    —MinnesotaCare Process Model
    —MinnesotaCare Alternatives Analysis
    —MinnesotaCare Final Recommendations

    Please note that KPMG Consulting’s analysis only studied MinnesotaCare processes. Their subsequent
    recommendation to DHS was to automate all other Minnesota Health Care Programs in addition to
    MinnesotaCare. DHS has chosen to phase the project implementation differently than the KPMG
    recommendation.

2. KPMG—MinnesotaCare Business Process Redesign project (final report)
3. HCO Project Life Cycle document
4. MAXIS Rewrite information
5. DHS Fact Sheet on Minnesota Health Care Programs
6. DHS Web Design Standards—Appearance and Navigation sections

Online access to this library has been secured and will require access approval from DHS. (Refer to Section 3.5.14,
Proposal Submission Requirements, for instructions on how to access the Online Reference Document Library.)




Page # 80        Revised 10/2004
of CFMS #
       SOW Attachment C – Minnesota Department of
       Human Services Strategic Plan for Information
                      Technology
        http://dhsinfo.dhsintra.net/main/groups/public/documents/pub/infolink_id_009123.hcsp




     The Minnesota Department of Human Services



                             Strategic Plan

            for Information Technology

                                     May 13, 2004




Page # 81   Revised 10/2004
of CFMS #
             The Minnesota Department of Human Services

                            Strategic Plan
                     for Information Technology
                                      May 13, 2004



This Strategic Plan for Information Technology derives from the Department’s
Vision for Human Services delivery and management.

The Department’s Vision is made up of its Mission, its Guiding Principles, its
Priorities, and the Strategies and Goals of the individual business units that are
responsible for implementing the agency’s Priorities.

Agency Mission
The Minnesota Department of Human
Services, working with many others,
helps people meet their basic needs so
they can live in dignity and achieve
their highest potential.

Guiding Principles
Commitment to mission
Focus on clients
Simplify services
Manage for results
Improvement by innovation
Equity in access and outcomes




Page # 82    Revised 10/2004
of CFMS #
Additional information on DHS Priorities can be found on the department’s internal
InfoLink web site. Strategies and Goals are available through each business area.


The Vision for DHS Information Technology

The fundamental goal of Information Technology (IT) is to create value for the
enterprise. IT is an essential component of the modern infrastructure of government;
the improved and strategic application of people, processes, information and
technology can enable better government.

DHS requires a coordinated IT function that includes a coherent combination of
centralized and decentralized functions, combining the responsiveness inherent in
decentralized functions with the efficiencies inherent in centralized structures.


The vision to guide the department’s IT priorities over the next 3 years focuses on the
following outcomes:

• Alignment - An improved alignment between IT and business as well as
  horizontally, across DHS IT. Evolve to a culture whereby investments and
  information sharing are maximized, through coordinated, standardized processes.

• Maturity - A more mature DHS IT organization with a strategic planning process,
  clear governance, an enterprise IT architecture, and improved IT investment
  management.

• Performance Management -- An applied focus on supporting client access and
  outcomes through technology-based solutions.

• Workforce Management – A skilled technology workforce available and
  efficiently utilized to achieve DHS and statewide objectives.


Current Challenges

• Inconsistent visions across the department about who we serve and how we serve
  them (clientele, providers, end users, taxpayers).

• Inconsistent visions of future service delivery needs, structures and interactions
  across programs.
                                          83
• Difficulty in establishing agency-wide priorities for technology within
  decentralized structure driven by funding streams and individual business area
  goals.

• Few incentives and structural supports exist for collaboration and innovation.

• Limited and shrinking resources available to accomplish the DHS Mission and
  vision.




                                         84
The Strategic Plan for Information Technology

This Plan offers action steps to address short-term, immediate needs of the
department. It also offers actions steps to help DHS set a direction for the future and
drive toward more integrated planning.

Action Steps for 2004-2005

o Develop a DHS-wide IT governance structure led by a Board of Directors.
  Members of this Board would be the Deputy Commissioner, the Assistant
  Commissioners, and the Chief Information Officer.
o Help implement the department’s Mission by targeting technology to the Goals
  and Strategies that business units have defined for the 2004-2005 period.
o Coordinate IT requirements among business units.
o Improve strategic management of IT resources by increasing horizontal alignment,
  improving perceived and actual value of IT services, and promoting projects that
  cross technology and organizational boundaries.

Action Steps for 2006-2011

o Collaborate with business units to incorporate IT resources into the design of
  service delivery structures for 2014.
o Determine how to internally align the enterprise’s programs, organization and
  technology to form a dynamic and effective service delivery environment.
o Explore opportunities, benefits and costs of aligning with other organizations for
  shared outcomes and IT services.
o Build insights and capacity to move toward the agency Mission and its Vision for
  Information Technology.

Adapting to Change

Changes in the environments of human services and technology will require that
DHS adapt its Priorities, Strategies and Goals to those changes. To enable that
adaptation, this Strategic Plan for Information Technology will be reviewed and
revised annually, under the oversight of the IT Board of Directors and with the active
involvement of business and IT managers of major systems, business systems, and
central infrastructure and application support.


This Plan is respectfully submitted for approval of the IT Board of Directors by:


                                           85
The IT Strategic Plan Strategizing Core Team:

Name                    Perspective
Johanna Berg            CIO
Peg Booth               Continuing Care policy
Krista Boston           Continuing Care policy
Barry Caplin            Central IT, technical
Jim Chase               Health Care business
Anna Lattu              Senior Systems/SOS
Kathleen Henry          Health Care policy
Denise Moreland         Major Systems
Roger Root              Emerging technologies
Ann Sessoms             HS business, performance
                        management, county perspective
Nina Terhaar            Use of data, small systems, technical
Larry Woods             Senior Systems/HCO
Barb Yates              Children’s Services policy




                          The IT Strategic Plan Strategizing Review Team:

                          Name            Perspective
                          Neil Beltt               Central IT
                          Linda Nelson             Agency-wide, facility management
                          Sharon Radman            Technical/PRISM
                          Linda Randolph           HSTG, county perspective
                          Lynne Singelmann         DHS business
                          Jack Thueson             Technical/HCO
                          Martha Watson            Agency-wide, HR issues
                          Gwen Wildermuth          Senior Systems/SSIS




                                              86

								
To top