TECHNOLOGY GUIDANCE
for horizontal integration of health and human services
Prepared for APHSA
By Rick Friedman, Health and Human Services Consultant
Alexandria, VA
In association with the APHSA National Workgroup on Integration
©2012 American Public Human Services Association. All rights reserved.
APHSA National Workgroup on Integration Technology Guidance/May 2012
CONTENTS
Page
Questions This Guidance Will Answer
A. Who Should Read This Guidance?
B. What Are the Challenges This Paper Addresses?
I. Putting Technology in Perspective
A. Vision: The Pathways Initiative
B. How IT Supports the Vision—Bridging the Divide: Leveraging New Opportunities to
Integrate Health and Human Services
II. Technology’s Contribution: A Service-Oriented Architecture Approach to Enterprise
Architecture
A. What is Service-Oriented Architecture?
III. Today’s IT Challenges
A. The Stove Pipe Phenomenon
B. Putting the Cart Before the Horse: Technology First, Business Second?
C. The Medicaid Funding Tsunami
D. Legacy Integrated Eligibility Systems: Renovate or Start Over?
E. How Compatible is the New Medicaid Operating Paradigm with Human Services?
IV. Addressing the Challenges
A. Overcoming the Stove Pipe Phenomenon
1. White House and OMB Perspective
2. Seven Conditions and Standards
B. Putting Business First, Technology Second
1. The Business of SOA
2. CMS IT Guidance 2.0
C. Responding to the Medicaid Funding Tsunami
1. The A-87 Cost-Allocation Exception
2. The Tri-Agency Letters
D. Legacy Integrated Eligibility Systems: Renovate or Start Over?
1. Using Legacy Integrated Eligibility Systems as a Starting Place
2. Is it Practical for Human Service Agencies to Wait until 2014 to Participate
in a New System?
E. Where to Go for Additional Help
©2012 American Public Human Services Association. All rights reserved.
2
2
2
3
3
3
4
4
5
5
6
6
7
7
8
8
8
8
9
9
10
11
11
14
14
14
15
16
1
APHSA National Workgroup on Integration Technology Guidance/May 2012
Questions This Guidance Will Answer
In the Governance section guidance was provided to state and county leaders on how to establish an
oversight body that sets the vision, strategic direction, desired outcomes, and policies to govern and
support the planning, design, and implementation of an integrated health and human service system
that meets the needs of the state and consumers.
This Technology section offers guidance on how information technology (IT) can support health and
human services stakeholders at all levels—from agency heads and chief information officers (CIOs) to
program managers and front-line intake staff—achieve that vision. It provides an overview of
technology’s supporting role, identifies the challenges faced by health and human service leaders to
build horizontally integrated and interoperable eligibility determination systems, as well as enterprisewide Service Oriented Architectures capable of linking disparate databases from various agencies that
serve the same clients, and discusses recent federal policy opportunities that can be used to effectively
leverage technology to ensure that the desired outcomes are achieved.
What is the vision of the health and human service business model that IT should support?
How does IT fit within the larger context of the health and human service enterprise?
What is service-oriented architecture (SOA)?
What are the challenges facing IT adoption today?
How should these challenges be addressed, and what policy tools are currently available to do
that?
Relative to OMB’s A-87 Cost Allocation Exception components, which ones should human
service agencies be sure to make maximum use of?
What action steps should states take now in terms of IT and supporting IT policies to ensure
they achieve their vision?
A. Who Should Read this Guidance?
While the subject of this guidance is “technology,” it is not intended solely for IT leaders or staff. All too
often, “IT issues” are labeled as something not for general consumption by governors’ budget and policy
staffs, commissioners/secretaries of departments or agency heads. The purpose of this paper is not to
discuss the “boxes and wires” that typically constitute the grist of an IT discussion. Rather, this paper is
intended primarily for those decision-makers and their advisors just mentioned who influence key policy
and operational choices during today’s atmosphere of having to make difficult choices based on budget
realities. It provides background information on unique opportunities to leverage important, but timelimited, funding opportunities to build enterprise-wide solutions that transcend the organizational silos
of the past that have prevented all of us from having the most complete picture possible of clients
served by both health and human service programs. It is vitally important that the outcomes that are
critical to integrated program service delivery and processes to ensure delivery should drive all
technology modernization efforts.
B. What Are the Challenges This Paper Addresses?
Most people understand intuitively that for any IT initiative to be successful, it must be driven by the
mission, vision, goals, and objectives of the program or business it is designed to support. Unfortunately,
that is easier said than done, particularly in today’s Affordable Care Act (ACA) environment of shortdeadlines, constantly evolving rules, and general atmosphere of uncertainty.
©2012 American Public Human Services Association. All rights reserved.
2
APHSA National Workgroup on Integration Technology Guidance/May 2012
Historically, the development of integrated eligibility determination systems has taken 4–5 years from
start to finish in the best of circumstances. Under the ACA’s statutorily imposed deadlines, Medicaid
agencies today have fewer than 18 months to build and thoroughly test new, or enhance existing legacy,
eligibility and enrollment systems. While the federal agencies have promised to shorten review times for
Advance Planning Documents (APDs), Requests for Proposals (RFPs), and contracts, and promote the
transfer of IT components from “early adopter” states, only a limited amount of time can be saved in the
procurement process. Steering funding requests through state procurement offices; engaging reliable
contractors after seemingly endless rounds of public notice and vendor protests; overseeing the
project’s development; stress-testing the system at every stage using unit, integration, system and user
acceptance protocols, etc., cannot be easily collapsed without sacrificing quality products and results.
Given the time constraints they are under, is it any wonder that states are flooding the market with new
Medicaid procurement requests to squeeze out as much time to build or enhance their systems as
possible? From a human service agency’s perspective, this “urge to procure” has left a number of them
sitting on the sidelines. While a handful of states have recognized the need to include human services in
at least preliminary discussions about a horizontally integrated IT architecture, most are either silent
partners or being told to wait until after the ACA deadline of January 1, 2014.
I. Putting Technology in Perspective
It is important to understand that any discussion about technology must be placed in the broader
perspective of an organization’s vision, mission, goals and objectives; i.e., its business model.
A. Vision: The Pathways Initiative
Pathways (http://www.aphsa.org/policy/pathways.asp) is an initiative of the American Public Human
Services Association (APHSA) and its members to transform how health and human services are
provided in this country. Public human services must move in new directions—down new pathways—if
we are to meet increased demand for assistance at a time of tight budgets and heightened public
expectations for effective outcomes in the work we do.
At the centerpiece of Pathways are four major outcomes:
Achieving gainful employment and independence
Stronger families, adults, and communities
Healthier families, adults, and communities
Sustained well-being of children and youth
The transformed human service system APHSA envisions can be achieved by focusing policy and practice
on impacting these four outcome areas, each of them undergirded by key foundational supports and
policy frameworks. Included among these is the technology infrastructure that supports enterprise
solutions across programs, departments, and levels of government; that supports integrated systems
through flexible funding; and that is funded based on demonstrated need and effectiveness, not the
rules of current program silos.
B. How IT Supports the Vision—Bridging the Divide: Leveraging New Opportunities to
Integrate Health and Human Services
The National Workgroup on Integration’s foundational document, Bridging the Divide, was developed
through consensus with leaders across the country and is grounded in the research on the social
determinants of health and the health determinants of an individual’s social condition. It described a
©2012 American Public Human Services Association. All rights reserved.
3
APHSA National Workgroup on Integration Technology Guidance/May 2012
vision for 21st Century health and human service programs of a fully integrated service system operating
as a seamless, streamlined information exchange, shared services, and coordinated care delivery. Such
horizontally integrated systems are customer focused and result in a modern marketplace experience
designed to improve consumer outcomes as well as improve population health over time. Ultimately,
they are designed to bend the health and human service cost curve by 2025.
II. Technology’s Contribution: A Service-Oriented Architecture Approach to
Enterprise Architecture
The National Association of State Chief Information Officers (NASCIO), recognizing the need for states,
counties, and local jurisdictions to view their programs more holistically, created an Enterprise
Architecture and Governance Committee (EA&G) comprised of state CIOs of cabinet rank from a number
of states across the country. In their mission statement, the EA&G Committee echoed the sentiments of
APHSA’s Pathways:
NASCIO STATEMENT ON ENTERPRISE ARCHITECTURE
Government must continually reinvent itself to remain relevant…The path to this
continual transformation must embrace leadership, management, coordination,
communication, and technology throughout government. Enterprise architecture is the
discipline to appropriately define and leverage these capabilities within the complexities
of government. Enterprise Architecture defines an enterprise-wide integrated set of
components that incorporates strategic business thinking, information assets, and the
technical infrastructure of an enterprise to promote information sharing across agency
and organizational boundaries.
http://www.nascio.org/committees/ea/
A. What Is Service-Oriented Architecture?
Service-Oriented Architecture (SOA) is a software engineering approach to Enterprise Architecture
based on principles and methodologies for designing and developing software in the form of
interoperable services. The services described within an SOA Framework are well-defined business
functions, specific to a particular industry, e.g., eligibility determination, case management, etc., that are
built as software components (discrete pieces of code and/or data structures) that can be reused for
different purposes.
SOA is used by many organizations in both the public and private sectors to support Enterprise
Architecture. Industries as diverse as banking and transportation are able to have their customers use
ATMs at different banks around the world, and passengers reserve flights on multiple airlines from the
convenience of their home, office or hotel, because SOA serves as the backbone architecture for their
very diverse operating systems. Similarly, government agencies are beginning to recognize the value of
an SOA approach to sharing information across their organizational boundaries. The Centers for
Medicare and Medicaid Services (CMS) has developed their version of an SOA called the “Medicaid
Information Technology Architecture” (MITA). The Administration for Children and Families (ACF) has
engaged Johns Hopkins University and Stewards of Change to assist them in developing a corollary SOA
specifically designed for human service agencies, the “National Human Services Information Services
Architecture.”
©2012 American Public Human Services Association. All rights reserved.
4
APHSA National Workgroup on Integration Technology Guidance/May 2012
In both cases, MITA and NHSIA provide a technological approach that allows states to move from their
“As-Is” world of today to the “To-Be” world of tomorrow. While each state and county may be in a
different place relative to their IT systems, SOA enables them to move along a continuum of
technological advancement, based upon a common approach and the use of standards, regardless of
where they are starting from or plan to go in the future.
III. Today’s IT Challenges
Rising caseloads and tight budgets have compelled states to assess very carefully how to do more with
less. Most have concluded they cannot continue to provide services in the same ways they did in the
past. Today’s shifting health and human service paradigm that is focused on lowering costs through
prevention, case management, and improved outcomes requires a more holistic understanding of the
cost drivers.
Health and human service IT systems that are slow to adapt to the “new normal” will need to be
renovated or replaced. Business processes that worked in the past require in-depth analysis if we are to
make maximum use of better ways to serve clients’ needs. Staff at all levels will need to sharpen existing
skills, and learn new ones, just to keep pace with the changing requirements of their clients, programs,
and public expectations.
What are some of the key IT challenges health and human service leaders face in the years ahead?
A. The Stove Pipe Phenomenon
States and counties are not alone in facing these challenges. The private sector and the federal
government are faced with similar demands. Vivek Kundra, the former U.S. Chief Information Officer at
the White House, highlighted similar challenges facing the federal information technology infrastructure
in his “25 Point Implementation Plan to Reform Federal Information Technology Management.”
Although he was directing his comments toward federal agencies, many of his concerns resonate loudly
with state, county and local CIOs across the country:
25 POINT IMPLEMENTATION PLAN TO REFORM
FEDERAL INFORMATION TECHNOLOGY MANAGEMENT
“…As part of a broader IT transformation, the Federal Government needs
to fundamentally shift its mindset from building custom systems to
adopting light technologies and shared solutions. Too often, agencies
build large standalone systems from scratch, segregated from other
systems. These systems often duplicate others already within the Federal
Government, wasting taxpayer dollars…A pervasive issue in government
programs is that individual stakeholders focus primarily on performance
metrics within their functions and not on the holistic outcomes of the
program… We need to replace these “stove-piped” efforts, which too
often push in inconsistent directions, with an approach that brings
together the stakeholders and integrates their efforts.”
Vivek Kundra, US CIO
December 9, 2010
©2012 American Public Human Services Association. All rights reserved.
5
APHSA National Workgroup on Integration Technology Guidance/May 2012
B. Putting the Cart before the Horse: Technology First, Business Second?
All too often, IT is perceived as existing in a parallel universe from the rest of an organization’s day-today business. This is partly due to technology being viewed as “too complex” for mere mortals,
consisting of its own language, logic, and even symbols that only those schooled in the esoteric
mysteries of building laptops in their garages or translating linear programming over their lunch breaks
are fully capable of appreciating. Many organizations frequently place IT in its own separate, freestanding department which only further adds to the mystique and, more importantly, to the separation
of business and IT. The result has been that the IT shop has often been asked to design, lease, or
purchase a “magic bullet” that will solve the latest federal, state, or local mandate before the
organization has had the time to think through the implications of the new requirements. The
consequences of this “Ready-Fire-Aim” approach to IT procurement has led to unfortunate situations in
which the solutions do not always fit the problems because the ramifications of the trigger events were
not analyzed sufficiently at the outset. Technology can be a tremendous enabler of a business solution.
But the key is always to put the organization’s business first to define the desired outcomes and ensure
that the results match expectations.
C. The Medicaid Funding Tsunami
While the current availability of federal funds for health IT appears to be plentiful, similar funding for
human services is in short supply. The very presence of such funding in the health area, coupled with the
statutorily imposed short deadlines of the Affordable Care Act, has set off a tidal wave of Medicaid IT
procurement requests and an industry feeding frenzy that have major consequences for human service
programs.
1. Impact on Federal Review Teams. Faced with a flood of funding requests for Medicaid
systems, federal reviewers of Advance Planning Documents (APDs) are challenged to provide
technical assistance and rigorous oversight, in spite of serious efforts to coordinate and expedite
the handling of these reviews. APD formats have been streamlined, efforts have been made to
reduce duplicating requests for additional information, “gate reviews” have been created to
analyze state work products on a flow basis, and federal agency heads are holding their APD
review teams to turnaround times of 30 days or less. But the challenge of providing appropriate
levels of oversight remains daunting.
2. Impact on States and the IT Industry. State procurement officers are faced with the same
workloads as their federal counterparts, in addition to trying to balance competing interests
from different agencies, not the least of which are from human service programs. Given the
much lower state contribution of 10 percent for the Medicaid-related projects, it is not
surprising why Medicaid-related procurements are taking precedence over all others.
As wonderful as this flow of IT federal funding may appear to the industry, it is not without its own set of
problems for contractors. The number of talented, experienced IT people is not limitless and their staffs
are being pushed to deliver goods and services for a world that is still evolving. Contractors are being
forced to marshal their resources to go after the projects with the highest likelihood of success and the
widest profit margins. Both states and industry leaders are increasingly risk-averse, resulting in fewer
bids and fewer innovated solutions. The mantra has become “just get me across the finish line and we
will worry about everything else later.”
And yet the basic challenge remains: How can human service leaders have their IT requests acted upon
timely by state and federal procurement officials who are consumed with today’s health IT priorities?
©2012 American Public Human Services Association. All rights reserved.
6
APHSA National Workgroup on Integration Technology Guidance/May 2012
D. Legacy Integrated Eligibility Systems: Renovate or Start Over?
For more than 30 years, states developed and relied upon large, expensive, sometimes slow-moving,
“integrated” eligibility determination systems. By “integrated,” it was meant that human service
programs shared the same core system for eligibility determinations with Medicaid, albeit with different
criteria and sometimes highly specialized caseworkers. As the eligibility rules for each of the partners
evolved in different directions, increasing amounts of time were spent on making patches to the legacy
systems and creating workarounds. While this problem had been around for a long time, the ACA raised
the stakes because of its short deadlines and national focus. How feasible would it be to attempt to
modernize only the Medicaid portion of a legacy integrated eligibility system (IES) built using technology
from 5, 10, or even 30 years ago? Would it not be easier, faster, and cheaper to simply pull Medicaid out
of the legacy IES and create the Medicaid-only eligibility and enrollment system from scratch? And if
that happened, would human service agencies be left behind with the same issues to work through but
with one less funding partner to share the fixed costs?
E. How Compatible Is the New Medicaid Operating Paradigm with Human Services?
The ACA radically streamlined Medicaid’s eligibility criteria but not for human services. As a result, the
operating paradigm for Medicaid has been radically overhauled.
CMS’ EXPECTATIONS FOR ACA-COMPLIANT MEDICAID ELIGIBILITY SYSTEMS
We envision a streamlined, secure, and interactive customer experience that will maximize
automation and real-time adjudication while protecting privacy and personally identifiable
information.
Individuals will answer a defined and limited set of questions to begin the process,
supported by navigation tools and windows that open to provide or seek additional
information based on individual preferences or answers.
The required verifications that will be necessary to validate the accuracy of information
supplied by applicants will be managed in a standardized fashion, supported by a
common, federally managed data services hub that will supply information regarding
citizenship, immigration status, and federal tax information.
Business rules will be supplied that will allow for resolution of most discrepancies through
automation, including explanations of discrepancies for the consumer, opportunities to
correct information or explain discrepancies, and hierarchies to deal with conflicts based
on source of information and extent and impact of conflicts on eligibility.
Source: IT Guidance 2.0, p.5
http://cciio.cms.gov/resources/files/exchange_medicaid_it_guidance_05312011.pdf)
The question arises as to whether it is feasible any longer for Medicaid and human service eligibility
determinations to be made in parallel, given the underlying tectonic plate shifts of the business model
that appear to be driving the programs farther apart, rather than closer together.
©2012 American Public Human Services Association. All rights reserved.
7
APHSA National Workgroup on Integration Technology Guidance/May 2012
IV. Addressing the Challenges
While the litany of IT challenges is long, it is not without hope. A number of federal policies have been
put in place recently to help states hold on to, and capitalize upon, the progress and investments they
have previously made in client-driven enterprise systems. The White House and OMB have both taken
steps to support these efforts, as have the three federal agencies—ACF, CMS and USDA/FNS—most
closely aligned with providing federal financial support for health and human service IT systems.
The key to unlocking the opportunities created by these federal policies is to: (a) understand them in
depth, (b) apply them to the world of human services, and (c) develop a shared vision with medical
assistance leaders to more effectively serve many of the same clients.
A. Overcoming the Stove Pipe Phenomenon
The first challenge described earlier was one of organizational stove pipes. While IT alone cannot solve
this problem, it can do much to overcome the infrastructure barriers that have prevented health and
human service programs from communicating effectively across boundaries in the past.
1. White House and OMB Perspective. In the same strategy piece quoted earlier, “25 Point
Implementation Plan to Reform Federal Information Technology Management,” Federal CIO
Kundra spoke of ways to address this common, but not insurmountable, challenge. Though a
technologist himself, he believes that the root cause of “siloed” organizations is people, not
technology.
His prescription for overcoming this challenge rests upon the use of multi-disciplinary teams
consisting of the following functions: (a) business process owners who have a clear vision of the
problem they are solving; (b) IT professionals who understand the full range of technical
solutions; (c) acquisition professionals who plan and procure needed labor and materials; and
(d) finance staff to secure required funding. For each large IT project, Kundra believes critical
members of the “Integrated Program Team,” as he calls it, should serve as full-time resources
dedicated to the program, including having a 100 percent dedicated IT program manager and
other key members of the IPT co-located during the most critical junctures of the program.
Being co-located is especially important during the requirements-writing phase, when business,
IT, and acquisition must define and modify requirements in short iterative cycles, and when
“translation issues” have historically caused problems.
It is also important to note that the federal “25 Point Plan” is communicating a clear message
from the White House and OMB directly to the people who will be reviewing state APDs, RFPs,
and contracts that cross-cutting, interdisciplinary teams are the preferred approach to IT
development going forward. State health and human service leaders should emphasize this
approach in their communication with the ACF/CMS/FNS staff early and often via all of their
written and verbal communications relative to requests for funding and technical assistance.
Calling attention to the collaborative approach recommended by the federal CIO and followed
by state IT and business leaders underscores the rationale for why key human service decisionmakers must be involved from Day One of any eligibility or other cross-boundary integration
project.
2. Seven Conditions and Standards. In 2011 when the Medicaid federal match was increased
from 50 percent to 90 percent for eligibility and enrollment systems, new requirements were
attached to the funding known collectively as the “Seven Conditions and Standards.” See
©2012 American Public Human Services Association. All rights reserved.
8
APHSA National Workgroup on Integration Technology Guidance/May 2012
Federal Register/Vol. 76, No. 75/Tuesday, April 19, 2011/Rules and Regulations, p. 29174. Of
particular relevance to this discussion is that Medicaid systems that are supported through the
higher match must allow interoperability with a number of organizations including, but not
limited to, human service programs.
CMS clarified what it meant by “allow interoperability” in its guidance document, “Enhanced Funding
Requirements: Seven Conditions and Standards Medicaid IT Supplement (MITS-11-01-v1.0):
EXCERPT FROM CMS’ GUIDANCE DOCUMENT:
“ENHANCED FUNDING REQUIREMENTS; SEVEN CONDITIONS AND
STANDARDS MEDICAID IT SUPPLEMENT “
“…CMS expects that a key outcome of the government’s technology investments
will be a much higher degree of interaction and interoperability in order to
maximize value and minimize burden and costs on providers, beneficiaries, and
other stakeholders…
…States should consult with and discuss how the proposed system’s development
path will support interoperability with health information exchanges, public
health agencies, and human services programs to promote effective customer
service and better clinical management and health services to beneficiaries.”
(emphasis added)
http://hss.lnwlabs.org/sites/default/files/Enhanced-Funding-Requirement-SevenConditions-and-Standards.pdf.
While CMS is not mandating that state Medicaid agencies must build interoperable systems with all
trading partners on Day One, failure to include human service representatives substantively at the
outset may result in increased costs, delays, and cost overruns when the states attempt to make their
Medicaid eligibility systems interoperable to meet the aforementioned conditions and standards.
B. Putting Business First, Technology Second
1. The Business of SOA. As mentioned earlier, both ACF and CMS are working to develop and support
the use of Service-Oriented Architecture (SOA) to coordinate state enterprise-wide IT projects. SOA
technology is broken down into discrete, free-standing components, much like a Tinker Toy set, that can
be used to build many different things, and still fit together, because the interchangeable components
are based upon a common set of industry standards.
While the particular “flavor” of an SOA framework may differ slightly from one field to the next, they
share a number of common features, the most significant being that all SOAs start with a business
architecture that supports the organization’s vision, mission, and goals. The technology then follows.
©2012 American Public Human Services Association. All rights reserved.
9
APHSA National Workgroup on Integration Technology Guidance/May 2012
FOUR COMPONENTS OF A TYPICAL SOA’s BUSINESS ARCHITECTURE
1. Concept of Operation
(COO)
The COO describes current operations, a vision of
transformation, transformations to stakeholder roles and
information exchanges, and the influence of new
legislation, policy, technology and enablers.
2. Maturity Model
(MM)
Typically divided into 5 levels of progressive maturity, the
Maturity Model illustrates how to transform goals,
objectives and business capabilities.
3. Business Process Model
(BPM)
This is a collection of common business processes for the
operation of the specific program using the SOA. It includes
a model of major business areas and subareas together with
definitions of common business processes using a common
vocabulary.
4. Business Capability Matrix
(BCM)
Subdivided into the levels of maturity found in the MM, the
BCM applies the MMM to the BPM to derive capabilities for
each business process at each maturity level. By so doing,
the BCM describes how to transform and improve a
business process.
This “business first, technology second” SOA approach is the underpinning of two important
federal IT initiatives: ACF’s “National Human Services Interoperability Architecture” (NHSIA),
and CMS’ “Medicaid IT Architecture” (MITA). Both are based on core SOA fundamentals, share
many of the same approaches, and will be of major help to states and counties eager to build
HHS systems that are integrated and interoperable.
For more information on NHSIA see http://www.acf.hhs.gov/interop/toolkit.pdf. For additional
background on MITA, see http://www.cms.gov/Research-Statistics-Data-andSystems/Computer-Data-and-Systems/MedicaidInfoTechArch/MITAWhitePapers.html.
2. CMS IT Guidance 2.0. In May, 2011, the Centers for Medicare and Medicaid Services
published “Guidance for Exchange and Medicaid Information Technology (IT) Systems.” CMS and
the Center for Consumer Information and Insurance Oversight (CCIIO) jointly developed,
“Guidance for Exchange and Medicaid Information Technology (IT) Systems, Version 2.0,” a
document that articulated a shared vision of the consumer experience relative to clients that
will be served through the Medicaid, CHIP, and the Health Insurance Exchange systems. The
vision expressed in that document resonates to a high degree with the vision expressed in
APHSA’s Pathways and shared by human service leaders for their clients, many of whom also
receive Medicaid services.
©2012 American Public Human Services Association. All rights reserved.
10
APHSA National Workgroup on Integration Technology Guidance/May 2012
CMS’ IT GUIDANCE 2.0 VISION STATEMENT
1. A high-quality client experience should be facilitated by seamless coordination between
key stakeholders at every level—from the clients themselves and caseworkers, through the
service agencies, navigators, brokers, and community-based organizations.
2. Data should be generated that support program evaluation efforts and ongoing
improvements in program delivery and outcomes.
3. Clients should experience a high level of service, support, and ease of use, similar to that
experienced by customers of leading service and retail companies.
4. The same customer experience should be provided to all individuals seeking services,
regardless of source or amount of financial assistance needed regardless of which access
point they used initially to enter the system.
5. This same high-level client experience should be experienced with other stakeholders and
business partners throughout the enterprise.
6. Individuals and families should find it easy to explore information on their benefit options,
and be enrolled quickly and accurately for those benefits for which they qualify.
While its primary purpose is to foster greater collaboration between state Medicaid systems and
Health Insurance Exchanges, the IT principles described therein are as applicable to human
services as they are to health. Many of the guidelines speak to enhanced interoperability and
systems integration across organizational boundaries that transcend the Medicaid/HIX interface.
And while the CMS guidance does not impose a single IT solution on states, it does underscore
CMS’ commitment to important principles that must be in place if meaningful data exchanges
are to occur—regardless of what organizations are involved in the transfer of information on
behalf of a common client.
C. Responding to the Medicaid Funding Tsunami
1. The A-87 Cost-Allocation Exception. On August 10, 2011, CMS announced a time-limited,
specific exception to the cost-allocation requirements set forth in OMB Circular A-87 (Section
C.3). Prior to this, A-87 required that all public programs share in the cost of IT projects in direct
proportion to the number of users of the system. The Exception, however, allows federally
funded human service programs to benefit from investments in the design and development of
State eligibility-determination systems for State-operated Exchanges, Medicaid, and the
Children’s Health Insurance Program (CHIP) at no additional cost to them beyond their own
unique requirements provided that those costs would have been incurred to develop systems
for the Exchanges, Medicaid, and CHIP. It applies only to development costs for eligibility
determination systems, and terminates on December 31, 2015.
Two aspects of the A-87 Exception are particularly worth noting: (a) the specific building blocks
needed for client-centric, enterprise-wide systems serving the same clients across multiple
programs and (b) the effective deadline of December 31, 2015, after which the traditional
benefitting program basis for cost sharing comes back into play.
©2012 American Public Human Services Association. All rights reserved.
11
APHSA National Workgroup on Integration Technology Guidance/May 2012
A-87 EXCEPTION ALLOWABLE IT COMPONENTS AND SERVICES
Client Portals
User Interfaces
Master Client Index
Business Rules Engine and
Operating Systems
Interfaces to:
 Federal and State Verification
Sources
 Community Assisters
 Outreach Organizations
 Exchange Infrastructure
Enterprise Service Bus
Data Warehouse
Privacy and Security Controls
Workflow Management Tools
Business Intelligence
Notices
Customer Services
Technical Support
Automated Account Creation and Case
Notes
Identity Management
Document Imaging and Digitization of
Case Records
Analytic Tools, including Decision Support
and Program Integrity
Telecommunications
Information Security and Privacy Controls
Infrastructure and Data Center Hosting
The Exception provides an incredibly rich opportunity for states to build enterprise-wide, highly
interoperable systems that serve their health and human services clients, many of whom are the
same people, more efficiently and effectively, at little or no cost to the human service agencies.
More to the point, if state and local decision-makers do not act aggressively and immediately to
submit Advance Planning Documents to all three federal funding agencies (CMS, FNS, and ACF)
that include both health AND human services, they will lose out on the 90 percent, the 75 percent
in perpetuity M&O, and fail the inter-operability requirement putting their initial effort at risk.
Based on in-depth discussions with the National Workgroup Initiatives industry partners—AT&T,
Accenture, CGI, Deloitte, Policy Studies, Inc., PCG Health & Human Services, and Xerox—and state
agency leads, several of these components and services are considered to be particularly useful for
purposes of horizontal integration in human services.
At the client/caseworker level: Imaging and Digitization of Case Records
Client Portals—An electronic gateway to a collection of digital files, services, and
information, accessible over the Internet through a web browser. It allows clients and others
to make use of an online system to log into an agency’s web site to provide information
about themselves in a secure environment as well as to access information pertaining to the
program, benefits available, the history of their account, etc.
Document Imaging and Digitization of Case Records—Sometimes called a document
management system, this is a computer system or set of programs used to track and store
electronic documents and/or images of paper documents. Typically, it is capable of keeping
track of the different versions modified by different users (history tracking), and sometimes
©2012 American Public Human Services Association. All rights reserved.
12
APHSA National Workgroup on Integration Technology Guidance/May 2012
has the capability to “read” data from one form and populate other reports or databases for
subsequent use or analysis. It is often viewed as a component of enterprise content
management (ECM) systems and related to digital asset management, document imaging,
workflow systems, and records management systems.
Automated Account Creation and Case Notes—A collection of tools that free up staff to
concentrate on substantive follow-up issues while reducing the administrative burden on
them as well as their clients. Facilitates sharing of information in a consistent way among
multiple stakeholders with a need-to-know and access rights while protecting the client’s
privacy.
Workflow Management Tools— In Service-Oriented Architectures, an application can be
represented through an executable workflow, where different, possibly geographically
distributed service components interact to provide the corresponding functionality, under
the control of a Workflow Management System.
At the enterprise level:
Master Client Index—The Master Client Index (MCI) is an enterprise information store of
demographic information that presents a common view of clients served based on feeds
from contributing systems. Typically, an MCI provides a proactive approach to services, as
well as a holistic view of the client using a single integrated data system with a common ID.
Such systems are capable of identifying family relationships, and can be key in helping
reduce fraud or abuse.
Business Rules Engine and Operating Systems—In most information technology applications,
business rules change more frequently than any other part of the system. Rules engines are
the pluggable software components that execute business rules. By being separated from
application code, business users have the flexibility to modify the rules frequently without
the need of having to undertake major programming overhauls, thereby making the system
as a whole much more flexible, responsive, and easier in which to make mid-course changes
as state policies change over time.
Enterprise Service Bus—An Enterprise Service Bus (ESB) is a software architecture model
used to coordinate the interaction and communication between mutually interacting
software applications in Service Oriented Architecture. The ESB is the “orchestra leader” of a
diverse set of program applications used by different programs that need to communicate
across human and system barriers in order to share information about common clients,
diverse policies, and/or multi-faceted issues.
Data Warehouse—A data warehouse (DW) is a database used for reporting and analysis.
The data stored in the warehouse are uploaded from the operational systems. The data may
pass through an operational data store for additional operations before they are used in the
DW for reporting. The typical data warehouse uses staging, integration, and access layers to
house its key functions. The staging layer stores raw data, the integration layer integrates
the data and moves it into hierarchal groups, and the access layer helps users retrieve data.
Data warehouses can be subdivided into data marts that store subsets of data from a
warehouse. Typically, the means to retrieve and analyze data, to extract, transform and load
data, and to manage the data dictionary are considered essential components of a data
warehousing system. Many references to data warehousing use this broader context. Thus,
©2012 American Public Human Services Association. All rights reserved.
13
APHSA National Workgroup on Integration Technology Guidance/May 2012
an expanded definition for data warehousing includes business intelligence tools, tools to
extract, transform and load data into the repository, and tools to manage and retrieve
metadata.
2. The Tri-Agency Letters. To clarify the federal intent of the A-87 Exception, senior leaders at
CMS, ACF, and FNS signed and circulated two letters in the summer of 2011 and winter of 2012
to their state counterparts.
Several key points in those letters are worth noting relative to human services benefitting from
the A-87 Exception.
First, while states are encouraged to take into account the needs and requirements of human
service programs in developing these systems, any human services system requirement that
would delay meeting the January 1, 2014 ACA deadline will not be permitted. Second, the
letters say that any state interested in an integrated eligibility system strategy should consider
staging the human service IT development in phases such that the additional functionality
needed to determine eligibility for human service programs can be added after the health
components are operational.
On the other hand, the Tri-Agency Letters make very clear there are major benefits to be gained
from cross-agency cooperation, as indicated below:
TRI-AGENCY LETTERS: SUPPORT FOR HEALTH AND HUMAN SERVICE INTEGRATED
ELIGIBILITY DETERMINATION SYSTEMS
1. To the extent that human service programs can make use of core eligibility
determination business processes and technical services that will be used in the
integrated eligibility systems, their ability to link to the system more easily and costefficiently in the future without requiring extensive changes to the common
components is a cost-effective approach to systems engineering.
2. Regardless of the approach, should a state elect to implement a multi-program
enterprise system, the project team must engage all programs that may be included
in the eventual enterprise system in a cross-program collaborative planning and
design process. The cross program collaboration should start as soon as possible and
continue throughout the development life cycle of the planned enterprise system.
Source: http://www.cms.gov/smdl/downloads/tri-agency.pdf - 8/10/2011 and
http://www.fns.usda.gov/snap/rules/Memo/2012/SMD-1-23-12.pdf
D. Legacy Integrated Eligibility Systems: Renovate or Start Over?
As discussed in the APHSA Governance Guidance document, “…how each state approaches and achieves
systems integration will be as different as the unique characteristics and needs of each state. Population
characteristics, government agency structure, political will, and system readiness all factor into
development and pursuit of an Integration Vision specific to each state …Developing, articulating and
shepherding the vision are, perhaps, the most essential functions of Governance.”
1. Using Legacy Integrated Eligibility Systems as a Starting Place. Regardless of which route a
state chooses there is real value in carefully teasing out the pros and cons of the current, and in
most instances, existing, integrated eligibility legacy system. Depending upon its age and
©2012 American Public Human Services Association. All rights reserved.
14
APHSA National Workgroup on Integration Technology Guidance/May 2012
technological sophistication, it may be much less costly and faster to modify that system,
perhaps staging the Medicaid enhancement first with the clear commitment to upgrade the
human service components as needed, and taking full advantage of the A-87 Exception in the
process. Old or new, the legacy integrated system can serve as an invaluable resource about
what works and what doesn’t in terms of horizontally integrated systems.
One of the issues that states need to consider in evaluating the pros and cons of leveraging their
existing systems as a platform for the future is the allocation of costs among the different
federal funding authorities. CMS has made it clear that it will not pay twice for the same service
in two parallel systems.
If the Medicaid component is pulled out, the share of the legacy system’s common costs that
were previously allocated to Medicaid will now need to be re-allocated between the remaining
SNAP and other human service agencies with the non-Medicaid programs all having to make up
the difference with no appreciable value added in return.
2. Is it Practical for Human Service Agencies to Wait until 2014 to Participate in a New System?
The simple answer is “no.” The key word here is “wait.” Human service agencies may have little
choice in some states to be “phased in” beginning in 2014. But there is much they can and
should do now to be prepared to be included in the new system. Moreover, the federal agencies
are very supportive of human service involvement early in the process as evidenced by the
range of policy options discussed in this paper. Clearly, none of them want to lose the
momentum and opportunities stimulated by, but not dependent upon, the Affordable Care Act
relative to horizontal integration and holistic, client-centric views of people receiving services
from multiple programs across organizational platforms. One must not wait to be “invited” to
the table to undertake the necessary planning and analysis upon which future systems will be
built. Talking with other human service agency leads in other states about what they have been
able to accomplish, sharing “lessons learned,” and making use of the pragmatic tools of
procurement developed by others requires little effort and will pay off handsomely over the
next 18 months.
Walking in the shoes of the medical assistance leadership enables those involved with improving
human services to be better positioned to contribute to the critically important discussions
currently underway. Effective, far-reaching strategies are dependent upon everyone’s input to
avoid making short-term IT decisions that inadvertently limit future options for the health and
human service enterprise as a whole.
In the end, the issue is not why human services should be deeply embedded in all health-related
IT discussions, but understanding and communicating to governors’ budget and policy leads,
state and departmental Chief Information Officers (CIOs), HHS secretaries, and their Medicaid
colleagues, about the financial and public policy consequences if they are not.
*
*
*
©2012 American Public Human Services Association. All rights reserved.
15
APHSA National Workgroup on Integration Technology Guidance/May 2012
WHERE TO GO FOR ADDITIONAL HELP
APHSA’s National Workgroup on Integration (NWI) web site (http://nwi.aphsa.org) contains a
wealth of information of use to states and counties interested in learning more. The site contains
white papers and guidance documents, links to states and federal agencies, a listing of Industry
Partners, and in-depth discussions on topics ranging from governance and technology to
business models and latest breaking news likely to impact decisions related to integration.
In addition, we highly recommend that readers consult the following sites:
ACF’s “Your Essential Interoperability Toolkit” (http://www.acf.hhs.gov/interop/toolkit.pdf)
provides valuable information on a wide range of interoperability topics from cost allocation to
the National Human Services Interoperability Architecture (NHSIA) and the Human Services
Domain of the National Information Exchange Model (NIEM).
CMS’ Collaborative Application Lifecycle Management Tool (CALT) is a tool that creates a
centralized repository for storing, collaborating on and sharing deliverables and artifacts from IT
projects in support of Medicaid administration and establishment of Exchanges. Within the
CALT, CMS has created the Medicaid State Collaborative Community to allow states the
opportunity to leverage, share, and collaborate on Medicaid information technology (IT)
systems development projects and to submit artifacts to the CALT for review and approval as
required by the systems development lifecycle (SDLC) process. Initial users can view the CALT
“Introduction and Guided Tour” at http://www.medicaid.gov/Medicaid-CHIP-ProgramInformation/By-Topics/Data-and-Systems/Downloads/CALT_factsheet.pdf
For additional support or to schedule a CALT demonstration, states can access the CALT Support
team at [email protected].
©2012 American Public Human Services Association. All rights reserved.
16