Luminary Technologies
October 2026
No.01
An Analysis of Indiana's Medicaid Enrollment Workflow
A workflow and user-experience study of Indiana Medicaid — investigating the interfaces between a Hoosier and her coverage as one potential factor in the 400,000-member enrollment decline of 2025–2026.
Abstract. Between January 2025 and April 2026, Indiana Medicaid enrollment fell by more than 400,000 members — including a 20% drop in children's coverage, the largest percentage decline in the nation (Georgetown CCF, June 2026). Public explanations have focused on policy change (redetermination resumption, the end of pandemic continuous enrollment, HIP work requirements coming January 2027) and on member circumstance (eligibility changes, movement to private coverage). This study investigates a third factor that has received comparatively little scrutiny: the workflows and user interfaces that stand between a Hoosier and her Medicaid coverage. Supporting evidence comes from the state's own 2024 Payment Error Rate Measurement cycle, in which Indiana's blended Medicaid improper-payment rate reached 7.57% — predominantly administrative in origin per Executive Order 25-60 — above the national 5.09% average and 4.57 points above the FY2030 federal statutory threshold under PL 119-21. If the same workflow friction producing measurable federal error is also producing coverage loss, the fix is operational rather than legislative. Part I walks each workflow screen by screen. Part II specifies seventeen targeted interventions. Part III sequences them against cost, timeline, and expected impact.
Executive Summary
If 400,000 Hoosiers lost coverage, what role did the workflows play?
Between January 2025 and April 2026, Indiana lost more than 400,000 Medicaid enrollees. The 20% drop in children's coverage was the largest percentage decline recorded in any state during the window (Georgetown CCF). The public conversation has framed the loss primarily as a policy outcome — redetermination resumption, continuous-enrollment unwinding, HIP work requirements arriving January 2027 — and has largely treated the member side of the equation as a given. This study asks a different question: what role did the workflows themselves play? If an eligible Hoosier cannot sign in because the portal uses email as the user ID and her email is dead, that is not a policy outcome. If a verification document arrives in the IEDSS queue with an unreadable barcode and the system treats it as not received, that is not substantive ineligibility. If a provider enrollment is current in one system and lapsed in another, that is not fraud. These are workflow outcomes, and they are measurable.
Supporting evidence that the workflows are producing error at a documentable rate comes from the state's own 2024 PERM cycle. Indiana's 7.57% blended Medicaid improper-payment rate — predominantly administrative per EO 25-60, not fraud and not ineligibility — break down, by error count, into documentation routing (46%), provider enrollment and identity drift (27%), and eligibility workflow (13%) of the 257 errors CMS cited. (Eligibility is a smaller share of error count but a larger share of improper-payment dollars — about 40%, per EO 25-24 — because eligibility errors tend to be higher in value.) The same friction producing federal error exposure plausibly produces coverage loss on the member side; this study walks the surfaces where both outcomes originate.
Five workflows define the system: the member maintaining coverage, the provider enrolling in IHCP, the provider responding to a PERM audit, the First Steps provider navigating a four-vendor identity stack, and the DFR eligibility worker operating IEDSS. Each is managed by a different organization, instrumented differently, and governed by a different vendor's quirks. The screens have never been studied together as a system. Together, they are the system — and together, they are where the measurable outcomes are produced.
Key findings
- Email-as-user-ID on the FSSA Benefits Portal is the single highest-leverage identity failure in the pipeline. Lose email access and you lose Medicaid. No backup identity path exists for the 400,000+ members churned since January 2025.
- The IHCP Provider Portal launched in December 2016 on the older DotNetNuke framework. Enrollment is a linear 13-step wizard with attachments uploaded at the end. The portal already supports secure correspondence but is not wired to deliver PERM audit notices — leaving a 1988-era fax and phone call as the primary provider interface for federal records audits in 2026.
- First Steps providers must synchronize identity across four separate systems — IHCP (Gainwell), EI Hub (PCG), Covansys CRO, and IDOE LVIS — with no reconciliation engine. This is the structural source of the 27% enrollment-error PERM cluster.
- IEDSS has an UNMATCHED document queue that fails cases silently. The data to auto-match documents to open requests exists in the inbound metadata and is not used. FSSA's own public statement that it "does not maintain county-level disposition data" is contradicted by the per-case data visible in every worker screen.
- Seventeen specific interventions, scoped and sequenced, would close an estimated 3–5 percentage points of the 7.57% PERM rate and materially reduce procedural coverage closures within four fiscal quarters. Under $5M in total implementation cost. None requires policy change.
Contents
Part I · Diagnosis — The workflows, screen by screenp. 3
Workflow 1 · The member maintaining coverage (FSSA Benefits Portal)Screens 1–3
Workflow 2 · The provider enrolling in IHCPScreens 4–7
Workflow 3 · The provider receiving a PERM auditScreens 8–11
Workflow 4 · The First Steps provider in the PCG EI HubScreens 12–14
Workflow 5 · The DFR eligibility worker in IEDSSScreens 15–17
Part II · Interventions — Seventeen specific fixesp. 24
Member-facing interventions (1A–1E)
Provider-portal interventions (2A–2E)
PERM-response interventions (3A–3D)
First Steps / EI Hub interventions (4A–4E)
IEDSS worker interventions (5A–5E)
Part III · Implementation — Sequencing, cost, impactp. 36
Four phases, four fiscal quarters
Expected PERM-rate and coverage-churn impact
Appendix · Methodology, limitations, sourcesp. 40
About the Luminary Study series & Luminary Technologiesp. 42
Part I
Diagnosis
Five workflows, screen by screen. Seventeen captures, annotated for the specific places where coverage friction and measurable error are produced.
How to read Part I
Each workflow follows the same structure: a short scenario describing who the user is and what they are trying to do; faithful recreations of each screen they encounter, with labels verbatim from the live captures; red callouts pointing to specific friction points; and a "What this produces" takeaway at the end linking the friction to its downstream PERM or coverage-churn consequence. Screens are numbered sequentially across all five workflows (1–17). Reconstructions are clearly labeled where used.
Workflow 1 · The member maintaining coverage
The scenario: a working parent of two children — one covered by Medicaid for a developmental disability, the other on CHIP — gets a letter from FSSA saying her annual redetermination is due. She has 45 days to respond. She logs on from her phone, during a work break.
Screen 1 · fssabenefits.in.gov — the landing page
Captured Oct 2, 2026 · 5:04 PM · fssabenefits.in.gov/bp/#/
fssabenefits.in.gov/bp/#/
FSSA
Coming January 1, 2027 — HIP Work Requirements
Beginning January 1, 2027, new federal and state Medicaid laws will require some Healthy Indiana Plan (HIP) members between the ages of 19 and 64 to meet work, volunteer, training, or education requirements to keep their coverage. More information about these changes and your coverage will be coming soon. For information on HIP work requirements, please visit myfssa.in.gov.
◀ 1 of 5 ▶ ⏸
Welcome to the FSSA
Benefits Portal
Apply Online for SNAP/ Cash Assistance
APPLY NOW
Apply Online for Health...
APPLY NOW
1Carousel banner about HIP work requirements rotates every few seconds. The member here does not have HIP coverage. This is the first thing she sees.
2The lead CTA is SNAP/Cash Assistance. The next CTA is partially hidden. Nothing on the first screen says "Renew Medicaid."
3No search field. To find the renewal workflow, she must navigate through Help or Explore Benefits — menus she has to open to see.
Friction
The home page is organized around benefit type (SNAP, Health, HIP work requirements) rather than member intent ("I need to renew," "I lost my notice," "Is my child still covered?"). A member coming to renew has to figure out that renewal is behind SIGN IN, not APPLY NOW.
Screen 2 · The sign-in modal
Captured Oct 2, 2026 · 5:05 PM · After clicking SIGN IN
fssabenefits.in.gov/bp/#/
Log In NEED HELP?
User ID (Email Address)
FORGOT USER ID
Password
FORGOT PASSWORD
CREATE NEW ACCOUNT
LOG IN
Note: Once you log in, you will be automatically logged out after 15 minutes of inactivity on any page or if you log in with the same User ID.
WARNING! This is a U.S. Government computer system intended for authorized use by official personnel only. Unauthorized or improper use... subject you to state and federal criminal prosecution and penalties as well as civil penalties...
4User ID is email address. Lose access to the email account on file (job change, forgot password, prepaid phone replaced) and you lose access to Medicaid. There is no SSN-based fallback.
5"FORGOT USER ID" is a 10-pt all-caps link floating right. On a phone it is a tiny tap target below the input.
6Warning text about federal prosecution appears before the member has even typed anything. Hostile tone for a routine login.
7Session timeout is 15 minutes. A caregiver gathering documents from paper files will routinely exceed this and be logged out silently.
Friction
Email-as-user-ID is the single highest-impact UX failure in the Medicaid pipeline. Georgetown-reported churn and FSSA's own enrollment decline both land here. The system has no backup identity (SSN+DOB+recovery phone) and no account-recovery path for people whose email account was closed.
Screen 3 · Create Account — two paths
Captured Oct 2, 2026 · 5:06 PM · fssabenefits.in.gov/bp/#/register/createaccount
fssabenefits.in.gov/bp/#/register/createaccount
Create Account
RETURN HOME
Indiana Resident
I want to apply for benefits or I have benefits:
- Prepare or complete an online application
- Review benefits you are receiving
- View your notices/correspondence
- Upload documents to your case
- Additional functions related to your case
CREATE A CLIENT ACCOUNT
Authorized Representative
I want to help others with their benefits:
- Represent the applicant/beneficiary
- Assist with filing or processing an application
- Speak on behalf of the applicant at an appeal
- Assist during redeterminations
- Additional functions related to an applicant/beneficiary's case
CREATE AN AUTHORIZED REPRESENTATIVE ACCOUNT
8Member must self-classify as "Client" or "Authorized Representative" before being asked anything else. Terms-of-art the user is expected to know.
9A grandmother helping her grandson will need to figure out which card applies to her. If she picks wrong, there is no documented path to switch account types later without starting over.
Friction
The language is agency-centric, not member-centric. "Client" and "Authorized Representative" are DFR case-management categories. Nothing on the page says "I'm renewing my coverage" or "I'm applying for my family."
What the member workflow produces
Four of the top-reported procedural-closure drivers trace to these three screens: (a) member cannot sign in because the email on file is dead; (b) member finds the APPLY NOW CTA but misses the renewal path and starts a new application; (c) member picks the wrong account type and the system does not surface the mismatch until days later; (d) member runs out the 15-minute session timer while locating a document. None of these is user failure. All of these are design decisions.
Workflow 2 · The provider enrolling in IHCP
The scenario: an SLP (speech-language pathologist) who already works for one school district picks up contract hours at a second district. The second district needs her enrolled under their service location in the IHCP so her claims can be billed. She opens the Provider Portal from a laptop on a lunch break.
Screen 4 · portal.indianamedicaid.com — the provider home
Captured Oct 2, 2026 · 5:07 PM · portal.indianamedicaid.com/hcp/provider/Home/tabid/135/Default.aspx
portal.indianamedicaid.com/hcp/provider/Home/tabid/135/Default.aspx
Home
Friday 10/02/2026 05:07 PM
WHAT CAN YOU DO IN THE PROVIDER HEALTHCARE PORTAL?
Through the Indiana Health Coverage Programs (IHCP) secure and easy-to-use internet portal, healthcare providers can:
- Submit claims
- Check on the status of their claims
- Inquire on a patient's eligibility
- View their Remittance Advices
Managed Care Entities can:
- Enroll, disenroll, and update primary medical providers
- Review their encounter claims
- Inquire on a managed care member's eligibility
In addition, the Portal provides access to a wide variety of IHCP information and resources.
10The design language is dated — teal gradients, gradient green navbar, aqua page background. The DotNetNuke /tabid/135/ URL pattern, still live in 2026, shows the older framework underneath.
11"Where do I enter my password?" — a link, because the login flow routes through a two-step pattern where the password screen is on the next page. This is the kind of UI that makes a biller mistrust the site.
12"Would you like to enroll as a Provider?" is buried in a sidebar box below Privacy and above Drug Resources. For a brand-new provider this is the entry point, and it is given less visual weight than "Protect Your Privacy!"
Friction
The portal looks and behaves like an older DotNetNuke site because that is what it is. It launched in December 2016 replacing Web interChange, migrated to AWS in June 2023, and its interface has not been meaningfully refreshed since launch. For a biller onboarding at a school district, this immediately signals "legacy," which is accurate but counterproductive — it undermines confidence in the site's security and reliability.
Screen 5 · Provider Enrollment landing — three equal doors
Captured Oct 2, 2026 · 5:08 PM · …/Home/ProviderEnrollment/tabid/477/Default.aspx
portal.indianamedicaid.com/hcp/provider/Home/ProviderEnrollment/tabid/477/
Home
Home > Provider Enrollment Friday 10/02/2026 05:08 PM
Provider Enrollment
▶ Provider Enrollment Application
Initiate a new provider enrollment application (includes optional Electronic Fund Transfer (EFT) enrollment).
▶ Resume Enrollment
Resume an existing application for the following reasons:
- Application has been saved but not yet been submitted
- Application has been RTPd for correction
- Application attachments need to be added
▶ Enrollment Status
Check the current status of an enrollment application.
Customer Links
W-9 Form · Provider Enrollment Type and Specialty Matrix
13Three options, all equal weight. For a biller who is not sure which applies — "Am I resuming or starting over? What is RTPd?" — there is no help text.
14"RTPd" = "Returned to Provider." No one outside IHCP uses this term. A new provider seeing it has no way to know what it means.
15The Provider Enrollment Type and Specialty Matrix is a 60+ page PDF, version 11 as of March 2026. The biller has to read it before even starting the application, to pick her provider type correctly.
Screen 6 · The 13-step enrollment wizard
Captured Oct 2, 2026 · 5:08 PM · …/EnrollmentWelcome/tabid/442/
portal.indianamedicaid.com/…/EnrollmentWelcome/tabid/442/
Home
Home > Provider Enrollment > Provider Enrollment Application Friday 10/02/2026 05:08 PM
Provider Enrollment: Welcome (?)
- ▶ Welcome
- Request Information
- Specialties
- Addresses
- Provider Identification
- Languages and Accessibility
- EFT Information
- Other Information
- Disclosures
- Additional Disclosures Information
- Agreement
- Acceptance
- Summary
Welcome to the Online Provider Enrollment Process
Please complete each step in the enrollment process. Click Continue to proceed within the enrollment application and choose Finish Later to exit and return at another time. When you have completed all steps of the application, click Submit and then Confirm to submit your application.
What do you want to do?
- New Enrollment: You are enrolling in the IHCP for the first time.
- Change of Ownership: The ownership of your business has changed.
- Add Service Location: You are already enrolled in the IHCP and want to enroll an additional service location.
You will need the following information to complete your enrollment request:
- National Provider Identifier (NPI) unless you are atypical (for instance, transportation or waiver) provider type
- Address including ZIP Code/postal code + 4
- Provider taxonomy unless you are atypical provider type
- Provider taxpayer identification number (TIN): EIN or SSN
- Provider license number if applicable to your provider type
- Address, SSN, and date of birth for disclosed individuals (owners, board members, and managers)
- Address and TIN for disclosed corporations (corporations with an ownership or control interest in the applicant)
- All attachments must be uploaded at the end of your application submission
- The following file types are allowed to be uploaded: pdf, bmp, gif, jpg, jpeg, tiff, tif, png
16Thirteen steps. The sidebar shows every one, locked, before the biller has made any decision. The flow does not branch by provider type — everyone sees all 13.
17"Add Service Location" (what our SLP actually needs) is one of three options presented at equal weight. For a credentialed, already-enrolled provider, this is the right choice — but it is not clear from the labels alone.
18Attachments uploaded at the END. If the final upload step fails or hits a 20MB file-size limit, work from the previous 12 steps may be lost or re-entered.
19BMP and TIFF are listed as accepted file types. Modern upload flows accept HEIC (iPhone default); this one does not. A biller taking a photo of a license on her phone has to convert.
Friction stack
(a) Linear 13-step wizard, no branching. A simple Service Location add has the same visible complexity as a brand-new multi-location business enrollment.
(b) Attachments at the end means validation errors on step 11 cost all prior work.
(c) Legacy file-format list (BMP, TIFF, GIF) is incongruous with 2026 mobile capture.
(d) The entire required-information list drops on the welcome screen as a wall of bullets — nothing paces the biller through what she will actually need next.
Screen 7 · The hidden complexity — multi-system identity for school-based providers
What the portal does not show the biller: the school district's own HR system, the state's teacher-licensing system (LVIS), the third-party billing vendor's roster (ClaimAid, PCG, etc.), and the Gainwell-operated IHCP file all have to carry the same name, same NPI, same specialty, same effective date. The portal screen above is one of four systems that must agree. The 27% of 2024 PERM errors in Indiana classified as "provider information and enrollment" live in the gaps between these four systems.
The four systems a school SLP's claim depends on being consistent
| System | Who maintains it | What drifts |
|---|
| IHCP Provider Portal | Gainwell Technologies | Service locations, specialty codes, revalidation dates |
| Indiana LVIS (teacher licensing) | IDOE | License status, name changes, endorsements |
| District HR / payroll | Local school corporation | Employment start/end dates, assigned schools |
| Billing-vendor roster | ClaimAid / PCG / local MDA | Rendering provider assignment to claim |
Why this matters
The portal UI only shows one of four systems. There is no cross-system reconciliation visible to the biller, the therapist, or the district. The claim submits, is paid, and only becomes a PERM error when CMS cross-checks the enrollment file against the rendering provider — months later, in an audit the biller does not see until the Review Contractor calls.
Workflow 3 · The provider receiving a PERM audit request
The scenario: a billing office that handles claims for seven rural Indiana primary-care clinics receives an unexpected phone call. The caller identifies themselves as Empower AI — the PERM review contractor formerly named NCI Information Systems — calling on behalf of CMS, about a PERM audit. The person on the phone is a records clerk.
Screen 8 · There is no screen. There is a phone call.
This is not metaphorical. The primary interface for a PERM records request in 2026 is a phone call followed by a fax or a first-class US Mail letter. There is no provider-facing portal where PERM requests queue up. There is no email. There is no SMS. There is no notification inside the IHCP Provider Healthcare Portal (which is secure correspondence-capable, but not wired for this). The provider's first touch is a cold call from a Virginia-area-code number.
CMS-published review-contractor script · what the caller says
Caller: Empower AI (formerly NCI) customer service representative
"Hello, this is [name] calling from Empower AI, formerly NCI Information Systems. We are the federal review contractor for the Payment Error Rate Measurement program, also known as PERM, on behalf of the Centers for Medicare & Medicaid Services. I'm calling to notify you that one or more of your Medicaid claims has been selected for the PERM audit, and you will be receiving a written medical records request.
Can I verify your contact information?... And would you prefer to receive the medical records request letter by fax or by first-class mail?"
Friction
The caller is unknown. The records-clerk who picks up the main phone line may route the call wherever seems closest to "records." The caller asks for a fax number or mailing preference on the first call, before the clerk has had time to verify this is a legitimate audit. For practices that have been social-engineered before, "give me a fax number" is a red flag — ironically, the real PERM process looks like a scam.
Screen 9 · The initial request letter (CMS template)
CMS public template · Initial Request for Records example letter (reproduced; illustrative dates)
NCI
INFORMATION SYSTEMS, INC.
Date: [||RequestDate||]
Reference ID: [||PERM ID||]
[Provider Name]
[Provider Address Line 1]
[City, State ZIP]
Dear Medicaid/CHIP Provider:
The Centers for Medicare & Medicaid Services (CMS) is conducting the Payment Error Rate Measurement (PERM) Program for the state of Indiana. NCI Information Systems, Inc. ("NCI") is the Federal Review Contractor supporting CMS on this effort. You have been selected as part of a statistically-valid sample of providers who received a payment from the state's Medicaid or CHIP program during the review period of July 1, 2022 through June 30, 2023.
Per 42 C.F.R. § 431.970(b), you are required to submit the requested documentation within 75 calendar days of the date of this letter. Enclosed with this letter is a PERM Fax Cover Sheet listing the specific documents required for each claim.
Patient authorization to release documentation is not required for this request. There is no reimbursement for responding to a PERM medical record request. Failure to respond may result in the state recovering the payment for the claim from your organization.
Sincerely,
PERM Review Contractor
NCI Information Systems, Inc.
Enclosure: PERM Fax Cover Sheet and Document List
20This reproduces the CMS/NCI-era template; records requests now come from Empower AI (formerly NCI; same Columbia, MD address and 800-393-3068 line). The review period shown is illustrative — Indiana's 2024 PERM cycle, the one this study analyzes, reviewed July 1, 2022 through June 30, 2023. The letter arrives at the service-location address on file in IHCP, which for multi-location practices is often the wrong office.
2175 days from "date of this letter" — the issue date, not received date. Mail transit, internal routing, and the time it takes to realize this is not junk mail come out of the clock.
22"No reimbursement for responding" — the practice absorbs the labor cost. For a small rural clinic, pulling 10 records packets is multiple hours of a scarce medical-records-clerk's time.
Screen 10 · The fax cover sheet (what gets faxed back)
CMS public template · PERM Fax Cover Sheet (one per claim)
PERM FAX COVER SHEET
TO:
NCI Information Systems, Inc.
FROM:
______________________________
PROVIDER NAME:
______________________________
PROVIDER NPI:
______________________________
DATE:
______________________________
# OF PAGES:
______________________________
PERM ID:
______________________________
Required documents for this claim:
- Signed and dated plan of care for the date of service listed above
- Progress notes documenting the service rendered on the date of service
- Physician order/referral referencing the rendering provider's NPI
- Rendering provider's credentials (license, certification) effective on the date of service
- Any additional documentation supporting medical necessity
- Copy of this fax cover sheet as the first page of the response
PERM ID: XXXXXX-XX-XXXXX · DO NOT ALTER
23Fax. In 2026. The default channel for a federal audit of multi-billion-dollar programs is still a 1988 technology, with a cover sheet filled out by hand or printed from a Word template.
24Item 3 is the single most common error for school/First Steps claims — "physician order/referral referencing the rendering provider's NPI." The November 2024 requirement that this appear on claims is still being absorbed.
25If the clinic has misplaced any one of these documents from a July 2023 visit, that claim becomes a PERM error — classified as "incomplete documentation" (46% of Indiana errors).
Screen 11 · The 75-day clock
Day 0
Empower AI calls the provider's listed phone, verifies contact info, asks fax-or-mail preference. Letter packet mailed or faxed the same day. 75-day clock starts from "Date" field, not received date.
Day 3–7
Letter arrives at service-location address. May be the wrong office for a multi-location practice. First internal routing hop.
Day 30
If Empower AI has received no response, first reminder phone call. Written reminder mailed.
Day 45
Second reminder phone call and written reminder.
Day 75
Final non-response letter mailed via registered mail. If no response received by this date, the claim is coded as improper payment under "incomplete documentation" (claim 46% of Indiana's 2024 PERM errors). State may recover the payment from the provider.
The actual provider UX gap
Nowhere in these 75 days does the provider have a digital inbox showing active PERM requests, days remaining, documents received by Empower AI, documents still outstanding, or a confirmation of receipt after submission. The provider has: a phone that may have been missed, a fax that may have landed somewhere wrong, a paper letter that may be sitting on a different desk, and no state-side portal view of any of this. SMERF, the system CMS maintains, is for state tracking — not providers.
Workflow 4 · The First Steps provider enrolling via the PCG EI Hub
The scenario: an independently-contracted developmental therapist wants to add Indiana First Steps to her service lines. First Steps serves children birth-to-three with developmental delays and runs on top of a Public Consulting Group (PCG) platform called the EI Hub. She is also an IHCP-enrolled Medicaid provider (she has to be, because First Steps bills through IHCP). But the First Steps enrollment is a completely separate workflow, in a completely separate vendor's system, with a completely separate identity.
Screen 12 · pem.prod.ineihub.com — the one-sentence welcome
Captured Oct 2, 2026 · 5:22 PM · pem.prod.ineihub.com
EIHub
THE HUB FOR EARLY INTERVENTION
First Steps Provider Enrollment · Identity ▾
EI Hub Home
⬛ PUBLIC CONSULTING GROUP
Provider Enrollment
Welcome to Provider Enrollment for Indiana's First Steps system. Please sign in to continue.
© 2020 - Public Consulting Group, Inc. | v2.8.0
26Branded as EIHub (PCG product), not Indiana First Steps. The state's name appears once, in body copy. A new provider could be forgiven for thinking she is on a vendor website rather than a state program.
27Entire welcome page: one sentence. No "what to expect," no "credentials you'll need," no timeline, no help contact. Compare to the IHCP 13-step wizard, which at least listed required materials up front.
28"Click here to Sign In" — a 2001 web-copywriting anti-pattern. The entire sign-in affordance is a text link, not a button.
29Footer: © 2020. The current year is 2026. The last public update to the welcome screen is five years old.
Screen 13 · Sign-in handoff to Amazon Cognito
Captured Oct 2, 2026 · 5:22 PM · after clicking "Sign In" · hus-dms-inei-prod-cogpool.auth.us-east-1.amazoncognito.com
hus-dms-inei-prod-cogpool.auth.us-east-1.amazoncognito.com/login?...
EIHub
FIRST STEPS EARLY INTERVENTION
CASE MANAGEMENT SYSTEM
Sign in with your username and password
Username
Username
Password
Password
Forgot your password?
Sign in
Need an account? Sign up
30URL changes to amazoncognito.com. A provider who looks at the address bar sees "amazon." The page is branded EIHub, hosted on AWS, serving an Indiana state program. This is the first branding handoff in the workflow.
31Field #1 is Username, not email. (The sign-up form on the next screen takes Username and Email separately.) Different identity model than FSSA Benefits Portal (email-as-ID) and different than IHCP Provider Portal ("User ID" of unspecified type). Three Indiana portals, three identity models.
32"Forgot your password?" link — but no "Forgot your username?" The username is self-chosen; if forgotten, the only path is contacting PCG support directly.
Screen 14 · Sign up — the three-field form
Captured Oct 2, 2026 · 5:23 PM · amazoncognito.com/signup?...
hus-dms-inei-prod-cogpool.auth.us-east-1.amazoncognito.com/signup?...
EIHub
FIRST STEPS EARLY INTERVENTION
CASE MANAGEMENT SYSTEM
Sign up with a new account
Username
Username
Email
name@host.com
Password
Password
Sign up
Already have an account? Sign in
33Three fields, no identity verification. No NPI, no license number, no state ID, no provider type. The account is created purely as a Cognito identity; the enrollment application happens after login.
34No password requirements shown before typing. Minimum length and complexity rules only appear if the submission fails. Compare to best-practice patterns (showing requirements as the user types).
35Importantly, this account is separate from: her IHCP Provider Portal account, her LVIS teacher-licensing account, her district HR account, her DOE Medicaid Reimbursement district contact, and her CSC Covansys Central Reimbursement Office identity. Six accounts, six passwords, six update cadences.
The hidden stack
What the enrollment flow does not surface: the EI Hub (pem.prod.ineihub.com) is where First Steps providers register. The operational EI Hub (hub.prod.ineihub.com) is where Service Coordinators do IFSP and service logging. Payment and billing go through CSC Covansys's Central Reimbursement Office in Shawnee Mission, Kansas (866-339-9595). Credentialing continues to flow through IHCP (Gainwell). Four separate systems, three separate vendors, one provider identity that must stay consistent across all four or claims error out.
Why this cluster drives the 27% enrollment-error PERM category
When CMS audits a First Steps claim, they see the IHCP provider record (via Gainwell), the credentialing file (via LVIS), the service record (via EI Hub), and the billing submission (via Covansys). The audit is scored as an error if any field disagrees across the four systems: name spelling, date of birth, NPI, license-effective date, specialty code. There is no reconciliation engine. There is no single system of record. There is no one dashboard a First Steps biller can look at to see whether her claims are at risk. This is why Indiana leads with 27% of its PERM error weight in this provider category.
Workflow 5 · The DFR eligibility worker in IEDSS
The scenario: a DFR eligibility worker in a county office is processing a redetermination. The member mailed in paystubs on day 10. The worker opens the case in IEDSS (Indiana Eligibility Determination and Services System, which replaced ICES in April 2019 and is maintained by Deloitte; the system runs about $34.7M a year (SFY2026, FSSA Q4 financial review), and Deloitte's DFR contract covering it is $59.98M over 1/1/2023–6/30/2029). What the worker sees determines whether the family keeps coverage.
Note on sources: IEDSS worker screens are not publicly released, by design. The recreations below are reconstructed from (a) the publicly-available Agency Portal Instructions PDF, which is the community-partner-facing cousin of IEDSS; (b) the Indiana Health Coverage Program Policy Manual, Chapters 1600 and 2200, which specify the data fields; (c) the published IEDSS RFP that originally described the interface; (d) worker and advocate interviews reported in Capital Chronicle and Public Health Watch. Each screen is labeled by its source basis.
Screen 15 · Agency Portal — the public-facing window into IEDSS data
Captured Oct 2, 2026 · 5:31 PM · in.gov/fssa/dfr/files/Agency_Portal_Instructions.pdf (page 1 of 15)
in.gov/fssa/dfr/files/Agency_Portal_Instructions.pdf
Agency Portal Instructions
Cash Assistance (TANF), Food Stamps
(SNAP), Health Coverage
Agencies working with clients receiving public assistance through the Indiana Family and Social Services Administration's (FSSA) Division of Family Resources (DFR) often need to know whether a client has been approved for benefits. Once authorized, registered agencies may access the Agency Portal 24/7 to check the case status for each of the individuals they support.
Access to case status information makes managing benefits much more accurate and timely. With the Agency Portal you can:
- Print forms including Proof of Eligibility and bar-coded cover sheets to be used for submitting beneficiary information to the State
- Review case documents received and solicited document requests
- Check upcoming eligibility and IMPACT appointments
- View detailed case information including effective dates and monthly benefit amounts
Frequently Asked Questions
Q: How is the Agency Portal different than the Benefits Portal?
A: The information provided through the Agency Portal and the Benefits Portal is the same. Agencies still have access to approved, pending or denied status, benefit amount(s), redetermination months, solicited documents and due dates; however, agencies registered to use the Agency Portal have access to all cases associated with the agency.
36"Bar-coded cover sheets" — the submission pattern. Agencies print cover sheets for each piece of documentation; the barcode routes the scan into IEDSS. If the barcode is wrinkled, torn, or the cover sheet is lost, the document arrives in the state's queue uncategorized.
37"Solicited documents and due dates" — the system tracks what it asked for and when it's due. But (per Public Health Watch) the member never sees this tracking view directly. The visible-to-member version is the mailed notice; the complete-list view is only on this agency surface.
38"Information provided through the Agency Portal and the Benefits Portal is the same" — official statement. In practice, advocates report the two portals go out of sync when workers add notes in IEDSS that don't propagate to either public view.
Screen 16 · IEDSS case summary (reconstructed from policy manual + published RFP)
This is what an eligibility worker opens when a case lands on her queue. The reconstruction is faithful to the data model specified in Medicaid Policy Manual Chapter 2200 (redeterminations) and the IEDSS RFP's screen descriptions. Field labels, categories, and workflow sequence match the policy spec. The visual chrome is a generic representation of a state eligibility worker interface; IEDSS is custom-built by Deloitte, and its exact underlying platform is not publicly documented.
Reconstructed from public documentation · representative of DFR worker view · IEDSS Case Summary
iedss.fssa.in.gov/CaseWorker/Case/[CaseNum]/Summary · (internal only — not publicly accessible)
IEDSS
Indiana Eligibility Determination & Services System
Worker: J. SMITH · DFR Office: 02-INDIANAPOLIS CENTRAL · Session expires in 23:47
Case Home
Interview
Verifications
Benefits
Documents
Correspondence
Notes
Appeals
CASE #
XXXXXXXXX
PRIMARY APPLICANT
[REDACTED]
HOUSEHOLD SIZE
4 (2 adults, 2 children)
COUNTY
Marion
PRIMARY LANGUAGE
English
CASE STATUS
PENDING REDETERMINATION
Due date: MM/DD/YY (12 days remaining)
Programs Active
| Program | Status | Effective | Next Review |
| Medicaid (MAGI Parent/Caretaker) | Approved | 01/01/26 | PENDING |
| Hoosier Healthwise (Child 1) | Approved | 01/01/26 | PENDING |
| Hoosier Healthwise (Child 2) | Approved | 01/01/26 | PENDING |
| SNAP | Approved | 01/01/26 | 07/01/26 |
Verifications Outstanding (3)
| Document | Requested | Due | Status |
| Earned income (last 30 days) | 09/15/26 | 10/15/26 | NOT RECEIVED |
| Proof of Marion County residence | 09/15/26 | 10/15/26 | NOT RECEIVED |
| Child care expense verification | 09/15/26 | 10/15/26 | PARTIAL (1 of 3 pages) |
⚠ 2 ALERTS · HIP work-requirement screening required for adult #1 effective 01/01/27 · 2nd notice mailer sent 09/20/26, no response
RUN DETERMINATION
Request Additional Info
Close Case
Transfer to Supervisor
398-tab horizontal navigation. Everything the worker needs is reachable in two clicks — but finding the right tab for an unfamiliar case type requires training. The redetermination workflow spans 4 tabs.
40Each program has its own next-review date. For a mixed household (Medicaid + Hoosier Healthwise + SNAP), the three dates diverge. The member sees one notice; the worker sees three timelines.
41"Child care expense verification: PARTIAL (1 of 3 pages)" — the uploads that get rejected on the member portal (blurry, cropped) end up here as partial. If no action is taken, the system defaults to treating partial as not received.
42Primary action: RUN DETERMINATION. If the worker runs it now with verifications outstanding, the system will produce an auto-denial. The worker has to notice and manually extend the deadline — which per policy requires supervisor approval.
Screen 17 · The verifications tab — where documents go to be found or lost
Reconstructed from public documentation · IEDSS Verifications view
iedss.fssa.in.gov/CaseWorker/Case/[CaseNum]/Verifications · (internal only)
IEDSS · Case XXXXXXXXX · Verifications
Case Home
Interview
Verifications
Benefits
Documents
Verification Status by Document Type
| Document type |
Required for |
Date requested |
Channel |
Received date |
Pages |
Status |
Action |
| Earned income (last 30 days) |
Medicaid, SNAP |
09/15/26 |
— |
— |
0 |
NOT RECEIVED |
Resend request ▸ |
| Proof of Marion County residence |
Medicaid |
09/15/26 |
— |
— |
0 |
NOT RECEIVED |
Resend request ▸ |
| Child care expense verification |
SNAP |
09/15/26 |
Benefits Portal upload |
09/22/26 |
1 of 3 |
PARTIAL |
Review ▸ |
| Paystub 09/01-09/15 |
— |
— |
Mail (bar-code 847) |
09/22/26 |
2 |
UNMATCHED |
Match to request ▸ |
⚠ WORKER ADVISORY: This case has 1 UNMATCHED document in the queue. The system received a 2-page paystub via bar-coded mail on 09/22/26 but the barcode did not match any active request. Click "Match to request" above to attach it manually before running determination.
43The UNMATCHED row is the critical pattern. The member mailed in paystubs. The barcode on her cover sheet was wrinkled or torn or printed too small. The scanner read it but could not associate it with a specific document request. The paystub sits in the queue, officially received, officially not applied.
44Resolution requires the worker to notice the UNMATCHED row, open it, read it, and manually associate it with the "Earned income" request. If she doesn't, running determination will deny Medicaid for failure to verify income — despite the member having complied.
45Channel column shows how documents arrived. "Benefits Portal upload" vs "Mail (bar-code 847)" vs "—". This is the instrumentation that could power the renewal-channel analytics FSSA says it doesn't maintain. The data is here, in the workers' interface. It is just not aggregated.
The worker-level truth
An IEDSS worker in a county office is managing hundreds of active cases, each with its own stack of verifications, its own clock, its own set of alerts, its own tab-switching flow. The Agency Portal that community partners see is a simplified mirror of what the worker lives in all day. The 13% eligibility-error rate in Indiana's 2024 PERM cycle traces back to the queue above: a case closed because the worker didn't catch an UNMATCHED document, a determination run with wrong income because the paystub stayed unlinked, a notice generated to the wrong address because a change-of-address form posted to the queue but never got processed. These are not worker-skill failures. They are instrumentation-and-UI failures that happen to workers trying to do their jobs.
The specific fixes implied by the IEDSS workflow
1. Auto-matching of inbound documents to open requests using beneficiary identifiers (SSN last-4, DOB, case number) when the barcode fails. The data to do this is already in the inbound document metadata.
2. Supervisor-pre-approved deadline extension when the system detects that verifications were requested but a document arrived in the queue within 14 days of the deadline. Reduces the "procedural closure despite member compliance" pattern.
3. Instrument every determination with channel-of-origin and outcome. This is the aggregation layer FSSA has publicly said it does not maintain. Building it is a weekend of SQL work on data that already exists.
The pattern Part I surfaces
One pattern repeats across all five workflows: every workflow depends on a document arriving at a correct destination through a channel the sender does not control. The member needs an email address that still works and a bar-code that scans. The IHCP provider needs a mailing address that routes to the correct records clerk. The PERM audit needs a fax to land in the records office rather than the main-line fax. The First Steps provider needs four separate identity systems to agree. The DFR worker needs an unmatched-document alert that she catches before running determination. In every case, when it fails, the system treats failure as the recipient's responsibility. Part II specifies seventeen interventions that, together, change this.
Part II
Interventions
Seventeen specific fixes mapped to the seventeen screens of Part I. Each specifies the problem, the fix, the expected impact, the implementation path, and a rough cost magnitude. The fixes are independent — each closes a specific friction regardless of what else is done — but Part III sequences them for maximum compounding effect.
How to read Part II — and a note on cost estimates
Interventions are grouped by workflow and labeled by letter: 1A–1E (member), 2A–2E (IHCP provider), 3A–3D (PERM response), 4A–4E (First Steps), 5A–5E (IEDSS worker). Each carries a complexity tag — QUICK WIN, MID-SCOPE, or STRUCTURAL — and a cost magnitude. All cost magnitudes in this study reflect typical incumbent-vendor engagement pricing — the structure the state currently uses when it contracts changes through its existing prime vendors (Deloitte, Gainwell, PCG, CSC Covansys). A modern implementation partner working outside that structure would execute many of these interventions at materially lower cost and in substantially shorter timelines; where that gap matters most we note it. The impact estimates are deliberately conservative and anchored to documented error-category breakdowns, not projection models.
Workflow 1 · Member
Interventions 1A–1E · The FSSA Benefits Portal
1A
Multi-factor identity recovery — SSN last-4 + DOB + recovery phone
Quick win
Problem: Email is the user ID. Members who lose email access (job change, prepaid phone cycled, forgot password with no recovery address) lose access to Medicaid. There is no backup identity path.
Fix: Add an "I lost access to my email" recovery path on the login page. Verify identity via SSN last-4 + DOB + recovery phone (phone number is already collected at application). On successful verification, allow the member to update the email on the account.
Owner: Deloitte (IEDSS vendor) and FSSA DFR portal team
Timeline: 60–90 days
Est. cost: $200–400K portal engineering + security review
Expected impact: Direct recovery path for an estimated 15–25% of the 400K+ churned members who lost coverage through identity failure, not substantive ineligibility
1B
Client-side upload preview + server-side OCR validation with instant feedback
Mid-scope
Problem: Members upload phone-camera photos of paystubs. The portal validates on the server; failures (blurry, cropped, wrong document) are reported hours later via email the member doesn't see. The 45-day clock keeps running on an upload the member thinks worked.
Fix: Add in-browser image preview with edge detection and brightness check before submission (reject obvious failures immediately). On submission, run server-side OCR to extract key fields (employer name, pay period, gross amount) and surface a confirmation screen: "We received your paystub showing [employer], pay period [dates]. Is this correct?" If OCR fails, surface specific guidance ("retake with better lighting") rather than a generic reject.
Owner: FSSA Benefits Portal team
Timeline: 4–6 months
Est. cost: $600K–$1M (OCR integration, UX redesign, accessibility QA)
Expected impact: Reduces procedural-closure rate from upload failure. Measurable within one quarterly cycle via upload-success telemetry.
1C
Default-on SMS and voice-call reminders at T-30, T-14, T-7, T-3, T-1
Quick win
Problem: Mailed notice is the only guaranteed outreach for redetermination deadlines. Members whose mail is intercepted, forwarded, or thrown out as marketing never see the request. "A request for information that the person — and sometimes multiple authorized representatives — never saw" (Public Health Watch, August 2026).
Fix: Opt-out (not opt-in) SMS and voice-call reminders using the mobile phone number already in the application record. Five escalating touchpoints: T-30 days (soft reminder), T-14 (specific document list), T-7 (urgency), T-3 (final warning), T-1 (last chance). Opt-out is one tap; opt-in is default. Add a sixth touchpoint on day of closure confirming receipt or non-receipt.
Owner: FSSA DFR + Benefits Portal team + state communications vendor
Timeline: 90–120 days
Est. cost: $150–300K setup + ~$0.03/message ongoing (~$500K/year at 15M messages)
Expected impact: Substantial reduction in procedural closures from missed mail. Documented best-practice fix adopted by Louisiana, Oregon, and Minnesota during the 2023–24 unwinding period with 20–40% drops in procedural-closure rates.
1D
Intent-first homepage — "I need to renew" as a top-level action
Mid-scope
Problem: The portal homepage is organized around benefit type (SNAP, Health, HIP work requirements) and sign-in state (SIGN IN / CREATE ACCOUNT), not member intent. A member coming to renew has to figure out that renewal is behind SIGN IN, not APPLY NOW. The lead CTA is SNAP, not Medicaid.
Fix: Redesign the landing to lead with four large intent-based cards: "Apply for benefits," "Renew my coverage," "Upload a document," "Help me understand my notice." Each routes the member through a short decision tree before reaching the authenticated flow. SNAP and HIP information remain accessible via secondary nav but are not the first thing a Medicaid member sees.
Owner: FSSA Benefits Portal team + state communications
Timeline: 6–9 months (includes user research, A/B testing)
Est. cost: $800K–$1.5M
Expected impact: Measurable reduction in time-to-first-task-completion; reduction in abandoned sessions. Member satisfaction improvement.
1E
Extend session timeout from 15 to 60 minutes
Quick win
Problem: The portal logs the member out after 15 minutes of inactivity. A caregiver gathering documents from paper files or waiting on a child routinely exceeds this and is logged out silently. On re-login, draft application data is often lost.
Fix: Extend inactive-session timeout to 60 minutes for authenticated users on the portal. Add auto-save every 30 seconds while a form is in progress, so a timeout does not lose work. Add a "You will be logged out in 2 minutes" modal with a one-click extension.
Owner: FSSA Benefits Portal team + security team
Timeline: 30–60 days
Est. cost: <$100K (configuration + auto-save implementation)
Expected impact: Reduction in abandoned applications and in support-call volume for "I lost my application." Trivial engineering cost; must pass FSSA security review for session-length change (justifiable per NIST 800-53 AC-11, which permits longer sessions with appropriate re-authentication for sensitive actions).
Workflow 2 · IHCP Provider
Interventions 2A–2E · The IHCP Provider Healthcare Portal
2A
Required Records Request Contact field on enrollment and revalidation
Quick win
Problem: Empower AI mails PERM audit letters to the service-location address from IHCP. For practices with centralized billing offices or third-party billers (ClaimAid, PCG, local MDAs), the letter arrives at the wrong physical building. By the time it's forwarded, 20+ days of the 75-day clock are gone. This is the single most citable driver of the 46% documentation-error PERM category.
Fix: Add a required "Records Request Contact" field to the IHCP enrollment and revalidation flows: name, email, direct phone, direct fax, upload-URL preference. Pass this to Empower AI's SMERF intake at the start of each PERM cycle. The field already exists in some provider enrollment systems (Ohio, Texas); Indiana does not have it.
Owner: Gainwell Technologies (IHCP Portal operator) + OMPP
Timeline: 60–90 days
Est. cost: $150–400K (CoreMMIS field addition, provider migration campaign, Empower AI API work)
Expected impact: Estimated 2–4 percentage points off the 7.57% PERM rate. Highest-leverage single intervention in this study.
2B
Email-based revalidation notifications with mandatory email on provider accounts
Quick win
Problem: Revalidation notifications are mailed only, at T-90 and T-60. Providers who have moved service locations, closed, or changed billing operators don't see the notice. Lapsed providers only find out when a claim rejects — or when a PERM audit flags their rendering NPI as not currently enrolled.
Fix: Make email mandatory on all provider accounts (currently optional). Add email-based revalidation reminders at T-180, T-90, T-60, T-30, and overdue. Portal homepage already shows the reminder on login; add parallel email channel so providers who don't log in regularly are reached.
Owner: Gainwell Technologies + OMPP
Timeline: 90–120 days
Est. cost: $200–500K (email service, bulk provider update campaign)
Expected impact: Reduction in lapsed-provider claims, which translates directly to PERM enrollment-error reduction (currently 27% of Indiana errors).
2C
Pre-submission enrollment-status indicator at claim intake
Mid-scope
Problem: Enrollment validation currently happens as a post-adjudication reconciliation. Claims submit, get paid, and only later generate a PERM error when CMS cross-checks. The biller submitting the claim has no visibility into whether the rendering provider's enrollment is current.
Fix: Build a claim-time enrollment status API that the IHCP Portal, EDI 837 intake, and third-party billing vendors (ClaimAid, PCG, Covansys) can query. Return: "Rendering Provider John Smith NPI 1234567890 is enrolled, specialty matches claim type, revalidation lapses in 11 days — proceed with warning" or similar. Moves the error from PERM post-mortem to pre-submission catch.
Owner: Gainwell Technologies + OMPP + billing vendor integration team
Timeline: 6–9 months
Est. cost: $1–2M (API, vendor integrations, biller training)
Expected impact: Catches enrollment-mismatch errors before claim submission. Material PERM-rate improvement; reduces claim-recovery exposure for providers.
2D
Branching enrollment wizard — short path for common actions
Mid-scope
Problem: The 13-step enrollment wizard treats every action identically. "Add Service Location" for an already-enrolled provider has the same visible complexity as "New Enrollment" for a multi-location business. Linear flow with attachments at the end means validation errors on step 11 cost all prior work.
Fix: Branch the wizard by action type and provider type on step 1. "Add Service Location" for existing providers: 4 steps instead of 13, pre-populated with existing data. "Change of Ownership": focused disclosure-only flow. "New Enrollment": the current full flow but with intermediate save checkpoints and the attachment step first (so file size failures surface before data entry).
Owner: Gainwell Technologies
Timeline: 9–12 months
Est. cost: $1.5–3M
Expected impact: Reduction in time-to-enrollment, reduction in RTPd (Returned to Provider) application rate, improved provider experience as measured by portal satisfaction.
2E
Modernize file-upload — accept HEIC and WebP, add client-side compression
Quick win
Problem: The portal accepts BMP and TIFF (1990s formats) but not HEIC (iPhone default). Providers photographing licenses on phones must convert files before upload. Upload size limits are 2010-vintage; a modern phone photo often exceeds them.
Fix: Add HEIC and WebP to accepted file types. Add client-side JPEG/PDF compression that targets 500KB per document while preserving legibility. Preview the compressed version before upload confirms. Drop BMP and TIFF defaults from the UI (keep as legacy support for machines still using them).
Owner: Gainwell Technologies
Timeline: 60–90 days
Est. cost: <$200K
Expected impact: Reduces upload-failure rate; reduces time-per-enrollment. Low-cost hygiene fix.
Workflow 3 · PERM Response
Interventions 3A–3D · The CMS / Empower AI records-request response
3A
IHCP Portal inbox mirror for every active PERM request
Mid-scope
Problem: The primary interface for a PERM records request is a phone call followed by a fax or paper letter. The provider has no digital inbox showing active requests, days remaining, documents received by Empower AI, documents still outstanding, or confirmation of receipt. SMERF (CMS's tracking system) is state-side only.
Fix: The IHCP Provider Portal already supports secure correspondence for revalidation. Extend this to PERM: when Empower AI issues a records request, post a mirror of the request to the provider's portal inbox with countdown timer, required-document checklist, and a single-click upload interface that pipes to Empower AI's SMERF intake. Email alert to the Records Request Contact (see 2A) on receipt.
Owner: Gainwell Technologies + OMPP (state-side) and CMS / Empower AI integration
Timeline: 6–9 months
Est. cost: $800K–$1.5M
Expected impact: Reduces 75-day non-response rate; closes the "I never saw the audit letter" category of PERM error. State also benefits from reduced claim-recovery adjudication volume.
3B
State-side digital intake replacement for fax submission
Mid-scope
Problem: PERM records are returned to Empower AI primarily via fax. In 2026. Fax quality degrades legibility, which generates "incomplete documentation" errors even when complete documentation was sent.
Fix: Build state-side PDF submission as the default channel, with the IHCP Portal upload (3A) as the entry point. State forwards the submission package to Empower AI via SFTP or Empower AI's existing API. Fax remains available for small practices without digital upload capability but is deprecated as default.
Owner: OMPP + Gainwell + Empower AI
Timeline: 9–12 months
Est. cost: $500K–$1M
Expected impact: Legibility-driven errors removed from the error pool. CMS has signaled interest in similar modernization nationally; Indiana would be an early mover.
3C
Pre-fill the fax cover sheet with claim metadata the state already has
Quick win
Problem: The provider fills out a cover sheet by hand for every claim in the audit: provider name, NPI, date of service, PERM ID, document checklist. All of these fields are known to the state and to Empower AI.
Fix: Pre-populate the cover sheet PDF for each sampled claim with claim metadata from IHCP. Provider only has to attach documents and sign. Removes transcription errors and reduces per-response labor.
Owner: OMPP + Empower AI
Timeline: 30–60 days
Est. cost: <$100K (PDF-form generation from existing data)
Expected impact: Reduces per-claim response labor from 20–30 minutes to 5–10. Removes identifier transcription errors.
3D
"PERM at Risk" early warning for providers with enrollment drift
Structural
Problem: Providers only find out they have a PERM problem when the audit letter arrives — by which time the error occurred months earlier. There is no leading indicator.
Fix: Run a monthly batch job that cross-checks the IHCP enrollment file against the claim submission file for mismatches (rendering NPI not currently enrolled, specialty mismatch, lapsed revalidation, missing ordering-provider NPI on school/First Steps claims). Post a "PERM at Risk" dashboard to each provider's portal showing recent flagged claims and recommended corrective action. Depends on intervention 2C (enrollment status API) being in place.
Owner: Gainwell + OMPP
Timeline: 12–18 months
Est. cost: $1.5–3M
Expected impact: Shifts error correction upstream of PERM. Multi-cycle PERM-rate improvement.
Workflow 4 · First Steps / EI Hub
Interventions 4A–4E · The PCG Early Intervention Hub stack
4A
Nightly four-system identity reconciliation dashboard
Mid-scope
Problem: First Steps providers must synchronize identity across IHCP (Gainwell), EI Hub (PCG), Covansys CRO, and IDOE LVIS. No reconciliation engine exists. The 27% enrollment-error PERM cluster lives in the gaps between these four systems.
Fix: Build a nightly batch job that cross-checks the four systems on identifier (name, DOB, NPI, license-effective date, specialty, service location) and generates a drift report. Deliver per-district dashboards to the responsible billing office, MDA, or school corporation with specific identifier mismatches flagged. Highest-leverage single intervention for the 27% enrollment-error cluster.
Owner: OMPP (state coordination) + Gainwell + PCG + Covansys + IDOE data teams
Timeline: 9–12 months (data agreements are the critical path, not engineering)
Est. cost: $1–2M build, <$500K/year operate
Expected impact: Significant portion of the 27% enrollment-error category becomes identifiable and correctable before claim submission.
4B
Modernized EI Hub welcome page — what you need, how long, where to get help
Quick win
Problem: The pem.prod.ineihub.com welcome page is one sentence long. No context, no credentials list, no timeline, no help contact. Footer dated © 2020. For the second-highest PERM-error-generating specialty cluster, this is the entry door.
Fix: Replace the one-sentence welcome with a structured onboarding page: "What is First Steps enrollment," "What you'll need before you start" (NPI, license, taxonomy, Medicaid provider ID if already enrolled with IHCP), "How long it takes" (realistic estimate), "Who to call" (specific contact for the specific question), "What happens after you submit." Change the "Click here to Sign In" text link to an actual button.
Owner: PCG + FSSA DDARS
Timeline: 30–60 days
Est. cost: <$50K (copy + layout work on existing PCG template)
Expected impact: Reduces incomplete/abandoned applications. Hygiene fix with disproportionate perception benefit.
4C
Pre-populate First Steps enrollment from IHCP data
Mid-scope
Problem: A First Steps provider who is already IHCP-enrolled must re-enter her identity, license, NPI, and specialty into the PCG EI Hub from scratch. Every manual re-entry is an opportunity for drift between the two systems.
Fix: When a provider signs up for the EI Hub with an NPI already in the IHCP file, pre-populate the enrollment application from the IHCP record. Provider verifies and corrects rather than re-entering. Writes back any changes to a drift log for 4A to reconcile.
Owner: PCG + Gainwell + OMPP
Timeline: 6–9 months
Est. cost: $400K–$800K (API, data agreements)
Expected impact: Reduces identity-drift error at the source. Reduces provider onboarding time by an estimated 50%.
4D
Modernize the Cognito sign-in handoff — co-brand, show provider the full URL path
Quick win
Problem: The sign-in redirects to a URL on amazoncognito.com. For a provider who looks at the address bar, this reads as "Amazon." Three Indiana portals, three identity models (email-as-ID, User ID of unspecified type, Username separate from email). No cross-portal single sign-on.
Fix: Front the Cognito auth with a state-controlled domain (e.g., login.firststeps.in.gov) so the provider stays on an Indiana URL. Harmonize identity models across FSSA, IHCP, and EI Hub via a longer-term state identity service. Interim fix: co-brand the Cognito page with the Indiana FSSA seal so the provider recognizes the context.
Owner: PCG + FSSA + OTS (state identity team)
Timeline: Interim fix 60 days; full identity harmonization 18+ months
Est. cost: Interim <$100K; harmonization $3–5M
Expected impact: Interim fix is cosmetic but material for provider confidence. Harmonization is a structural play.
4E
Vendor consolidation evaluation — three-vendor stack review
Structural
Problem: First Steps runs on three separate vendors: PCG (enrollment and case management), CSC Covansys (billing and reimbursement), Gainwell (Medicaid identity). This architecture is a legacy of 2000s-era procurement, not a design choice anyone would make today. OBBBA pressure makes this a natural moment to revisit.
Fix: Procurement-office evaluation of consolidating the three-vendor stack into a reduced stack (either fewer vendors, or clearer architectural separation with modern APIs). This is a procurement and contract-timing play, not an immediate engineering intervention.
Owner: IDOA + FSSA + OMPP leadership
Timeline: Procurement study 60–90 days; any resulting consolidation runs on contract-cycle timelines (12–24 months)
Est. cost: $200–500K for the procurement study itself; downstream consolidation cost is a function of what the study recommends
Expected impact: Structural. Preconditions 4A (identity reconciliation) could be delivered in-place well before any consolidation closes.
Workflow 5 · DFR Eligibility Worker
Interventions 5A–5E · IEDSS worker experience
5A
Auto-match UNMATCHED inbound documents to open requests using beneficiary identifiers
Quick win
Problem: Documents routed by bar-code arrive in the IEDSS queue; when the barcode fails to scan, they land as UNMATCHED. The data to associate them with the correct case and request (beneficiary SSN, DOB, case number, document type) is already in the inbound metadata. Cases close for failure to verify despite the member having complied.
Fix: Add a nightly auto-matching job that attempts to associate UNMATCHED documents with open verification requests using beneficiary SSN last-4 + DOB + document-type OCR classification. Match confidence > 90% auto-attaches; 70–90% posts to a worker review queue; < 70% remains UNMATCHED. Measurable error reduction on day one.
Owner: Deloitte (IEDSS vendor) + DFR operations
Timeline: 60–90 days
Est. cost: $300–600K
Expected impact: Direct reduction in procedural closures from the "sent paperwork but got closed" pattern. Measurable within one monthly reporting cycle via UNMATCHED-queue burn-down.
5B
Channel-of-origin instrumentation on every determination + weekly aggregated report
Quick win
Problem: FSSA has publicly stated it "does not maintain county-level disposition data or track whether recipients submit renewal information online, by mail, in person or through another method." The IEDSS Verifications tab shows per-document channel. The data exists; it is not aggregated.
Fix: Add an aggregation layer on top of the existing IEDSS data: weekly report of determination outcomes by county, office, worker, and submission channel (portal upload, bar-code mail, in-person, phone, no submission). Delivered to DFR leadership and FSSA executives. Enables the first evidence-based conversation about where procedural closures concentrate.
Owner: Deloitte + DFR analytics + FSSA leadership sponsorship
Timeline: 30–60 days
Est. cost: <$150K (SQL + reporting layer on existing data)
Expected impact: First-order visibility into where the system is failing. Enables targeted interventions downstream.
5C
Supervisor pre-approved deadline extension when document arrives within 14 days of deadline
Mid-scope
Problem: When a document arrives in the IEDSS queue (matched or UNMATCHED) within 14 days of a verification deadline, the worker must manually request a deadline extension. Per policy this requires supervisor approval. In practice, extensions aren't requested; cases close.
Fix: Policy change plus system change: supervisor pre-approved automatic deadline extension of 14 days when the system detects an inbound document — even unmatched — associated with a case approaching deadline. Worker is notified; supervisor is notified; the extension is applied; the case is not auto-closed. Requires FSSA policy update to delegate the pre-approval; system change is minor.
Owner: DFR policy + Deloitte
Timeline: 6–9 months (policy change is the gating item)
Est. cost: <$200K system; policy change is zero-cost but requires leadership decision
Expected impact: Direct reduction in procedural closures where member complied but documentation arrived late.
5D
Pre-determination warning on RUN DETERMINATION when PARTIAL verifications exist
Quick win
Problem: The RUN DETERMINATION button runs the determination immediately. If verifications are outstanding or PARTIAL, the system produces an auto-denial. Workers must notice and extend deadlines manually.
Fix: Pre-determination modal: when the worker clicks RUN DETERMINATION, show a summary of verification status. If anything is PARTIAL or NOT RECEIVED, the modal says: "This will deny Medicaid for failure to verify income because the 09/15/26 paystub request shows PARTIAL (1 of 3 pages). Did you intend to deny, or extend the deadline?" Three options: Deny · Extend 14 days · Return to case.
Owner: Deloitte
Timeline: 60–90 days
Est. cost: <$200K
Expected impact: Reduces unintended procedural closures. Worker protection as much as member protection.
5E
Embedded contextual help / microlearning for high-PERM-error case types
Mid-scope
Problem: IEDSS training materials are static PDFs updated annually. Policy manual references lag the actual IEDSS screens. Worker training on edge cases (mixed-status immigrant families, school-based Medicaid, First Steps dependents) happens in classroom sessions removed from the actual case.
Fix: Embed context-sensitive microlearning directly in the IEDSS UI. When a worker opens a case flagged as "mixed-status household" or "First Steps dependent," show a collapsible side panel with the relevant policy section, the correct screens to use, and the common pitfalls. Content maintained by DFR training, surfaced in-flow.
Owner: Deloitte + DFR training
Timeline: 9–12 months
Est. cost: $500K–$1M
Expected impact: Reduction in eligibility-category errors (currently 13% of Indiana PERM errors). Material reduction in worker training-cycle time.
Interventions
17
Across 5 workflows
Quick wins
8
90-day, <$500K each
Vendor-pricing ceiling
$6–12M
At incumbent-prime pricing structure, 24 months. Materially less under a modern implementation partner.
Target PERM impact
3–5 pts
Off the 7.57% baseline, within 4 quarterly cycles
Part III
Implementation
Four phases, four fiscal quarters. The seventeen interventions sequenced for maximum compounding effect, mapped to cost magnitude, ownership, and expected impact on the 7.57% PERM baseline and the procedural-closure rate.
The sequencing principle
Phase A clears the ground: lowest-cost quick wins with the highest independent impact, especially instrumentation that the later phases will depend on. Phase B builds on Phase A's instrumentation and starts the mid-scope rebuilds. Phase C delivers the structural fixes that depend on earlier work. Phase D is the long-cycle procurement and architecture work that would otherwise block everything if left for last. Running the phases concurrently rather than sequentially is possible but increases coordination cost.
Phase A · Clear the ground (Weeks 0–12)
Eight quick wins, each independently valuable, each surfacing data the later phases will need. Delivered in a single fiscal quarter. Total Phase A cost at incumbent-vendor pricing: approximately $1–2M; under a modern implementation partner, materially less.
1A SSN+DOB account recovery
1C SMS/voice reminders
1E Session timeout extension
2A Records Request Contact field
2B Email revalidation notifications
2E HEIC upload support
3C Pre-filled PERM cover sheet
4B EI Hub welcome page overhaul
4D Cognito co-branding interim fix
5A UNMATCHED auto-matching
5B Channel-of-origin instrumentation
5D Pre-determination warning modal
Within 12 weeks, Phase A alone would be expected to produce: a working identity-recovery path for members who've churned on email failure; direct email delivery of PERM audit letters routed to the right person for the first time; measurable PERM-cycle impact on the 46% documentation-error category; the first FSSA-internal view of determination outcomes by channel; and visible reduction in procedural closures from the auto-match and pre-determination fixes.
Phase B · Build on the instrumentation (Weeks 12–36)
Seven mid-scope rebuilds. Each depends on Phase A infrastructure being in place or completes a workflow Phase A opened. Total Phase B cost at incumbent-vendor pricing: approximately $2–4M over two fiscal quarters.
1B Upload validation with OCR
2C Pre-submission enrollment indicator
3A PERM inbox mirror in portal
3B State digital intake for PERM
4A Four-system identity reconciliation
4C Pre-populate EI Hub from IHCP
5C Pre-approved deadline extension
Phase B is where the 27% enrollment-error cluster gets its first direct attack (4A) and where PERM response moves off fax. The IEDSS deadline-extension change (5C) is in Phase B rather than A because it depends on a DFR policy update, which carries political and legal review timelines that cannot be compressed below ~6 months.
Phase C · Structural (Weeks 36–80)
Four structural rebuilds across the first six months of the following fiscal year. Each is a longer engineering lift and each delivers compounding returns on Phase A and B work. Total Phase C cost at incumbent-vendor pricing: approximately $2–4M.
1D Intent-first homepage redesign
2D Branching enrollment wizard
3D "PERM at Risk" early warning
5E Embedded contextual help
Phase D · Long-cycle (18+ months)
The procurement and architecture work that cannot start late. Phase D does not conclude; it reports progress at every quarterly review and sets the direction for post-FY30 compliance.
4D Harmonized state identity service
4E First Steps vendor consolidation evaluation
IHCP DNN → modern platform replatform
Member-portal + provider-portal single sign-on
Expected impact over four quarterly cycles
PERM rate
7.57% → 3–5%
Target by RY2028 cycle
FY2030 federal threshold: 3%
Procedural closures
↓ 30–50%
Measurable within one quarterly cycle via 5B instrumentation
Children's coverage
Partial recovery
Of the 174,000-child decline Georgetown CCF documented
Vendor-pricing ceiling
$6–12M
Over 24 months at incumbent-prime pricing. A modern implementation partner would execute at materially less and on faster timelines; see appendix.
Appendix
Methodology, limitations, sources
Research design
This study pairs direct interface analysis with documentary research. For each of the five workflows, two inputs were gathered: (a) live captures of the actual public-facing portals as they appeared on October 2, 2026, obtained by walking the portals through a controlled browser session; and (b) corroborating documentation from state publications, vendor training materials, CMS public materials, academic and journalistic reporting, and the state's own policy manuals. The analysis is faithful to what the live interface shows; interpretations and annotations are the study authors'.
Primary materials captured live
fssabenefits.in.gov — landing page, sign-in modal, Create Account page. Captured October 2, 2026 at 5:04–5:06 PM Eastern.
portal.indianamedicaid.com — provider portal home, Provider Enrollment landing, Enrollment Welcome (13-step wizard). Captured October 2, 2026 at 5:07–5:08 PM Eastern.
pem.prod.ineihub.com — First Steps Provider Enrollment landing, Amazon Cognito sign-in, Cognito sign-up form. Captured October 2, 2026 at 5:22–5:23 PM Eastern.
in.gov/fssa/dfr/files/Agency_Portal_Instructions.pdf — the community-partner-facing cousin of IEDSS. Captured October 2, 2026 at 5:31 PM Eastern.
Reconstructed material
The IEDSS worker screens (16 and 17) are reconstructions, labeled as such in Part I. The reconstructions are based on: Indiana Health Coverage Program Policy Manual Chapters 1600, 2200, and 4600 (which specify eligibility worker data fields and workflow sequence); the publicly posted IEDSS RFP (which described the required interface in detail); the Agency Portal Instructions PDF (which is the public mirror of related IEDSS data); and advocate and worker interviews reported in Indiana Capital Chronicle and Public Health Watch. We did not access IEDSS directly. We have not represented the reconstructions as screenshots, and have labeled them explicitly throughout.
PERM data basis
The 7.57% blended Medicaid improper-payment rate for Indiana comes from the January 2026 Executive Order 25-60 report, "Assuring Prudent Use of Taxpayer Funds by Ensuring Integrity in the Indiana Medicaid Program," authored by FSSA Secretary Mitch Roob and submitted to the Medicaid Oversight Committee. The error-category breakdown (46%/27%/13%) is the share of the 257 total errors CMS cited, drawn from the same report; it is distinct from the dollar-weighted view, in which eligibility is roughly 40% of improper-payment dollars (EO 25-24). The national comparison figure (5.09%) is from CMS's 2024 PERM Medicaid Improper Payment Rates publication.
Coverage decline data basis
The 20% / 174,000-child decline in Indiana children's Medicaid enrollment is from the Georgetown University Center for Children and Families report, June 2026. The 400,000+ net total enrollment decline figure is from FSSA Medicaid monthly enrollment data and the May 2026 Capital Chronicle reporting that cited enrollment of ~1.5M as of May 2026 against ~1.9M in January 2025.
Impact-estimate basis and limitations
The 3–5 percentage-point PERM-rate reduction estimate is intentionally conservative. It assumes: (a) the 46% documentation-error category can be reduced by at least half through Phase A interventions 2A and 3A alone; (b) a meaningful fraction of the 27% enrollment-error category becomes catchable upstream of PERM through 4A; (c) the 13% eligibility-error category sees first-order improvement through 5A, 5B, and 5D. The estimate does not account for compounding effects of multiple interventions. Procedural-closure impact estimates draw on the documented experience of Louisiana, Oregon, and Minnesota during the 2023–24 Medicaid unwinding, which saw 20–40% procedural-closure reductions after implementing similar SMS reminder and auto-match patterns.
A note on cost estimates
Every cost figure in this study is a rough magnitude, not a quoted price. The magnitudes are anchored to the pricing structure the State of Indiana currently uses when it contracts changes through its existing prime vendors — Deloitte for IEDSS, Gainwell Technologies for CoreMMIS and the IHCP Provider Portal, Public Consulting Group for the EI Hub, CSC Covansys for First Steps billing. These vendors are capable, and their pricing reflects a mature government-services cost structure that includes substantial program management, compliance overhead, contract administration, and the risk-adjusted margins typical of multi-year state engagements.
A modern implementation partner working outside that incumbent-prime structure would execute many of these interventions at materially lower cost and in substantially shorter timelines. For a sense of magnitude: much of what this study scopes as a 60–90 day quick win at a prime vendor is work a modern cross-functional team of two to four engineers could ship in two to six weeks, at a corresponding cost reduction. The phase totals in Part III should be read as a ceiling — what the state would plausibly pay today under its existing contracting posture — not a floor and not a Luminary Technologies estimate.
We have intentionally not published a Luminary Technologies cost model for this engagement in this study. The purpose of Luminary Study No. 01 is to make the problem legible, not to pitch. A specific implementation proposal — timeline, team, cost, deliverables — is available on request and would be substantially different from the ceiling figures above.
Limitations
This study examines public and semi-public interfaces. We did not access IEDSS directly, did not access any system behind authentication beyond the sign-up form, did not submit any forms, and did not create any accounts. Interview-based claims (worker experience, advocate observations) are drawn from reported sources, not primary interviews conducted for this study. The intervention cost estimates are magnitudes, not line-item budgets; actual implementation cost will depend on contract structure, incumbent vendor relationships, and procurement cycles. The expected impact figures are directional estimates grounded in comparable-state experience, not predictive models.
About
The Luminary Study series
The Luminary Study series is independent research by Luminary Technologies on the mechanics of public programs — the actual interfaces, the actual workflows, the actual data — with the goal of surfacing the operational truth beneath policy debate. Each study is public, data-anchored, and non-adversarial. The series continues Luminary's prior work on Indiana Medicaid; future studies will apply the same method to other state programs and other sectors where the measurable outcome is a function of workflow design.
Study authors
Luminary Technologies research team
With independent review from affiliated faculty at [TBD academic partner]
Contact & corrections
[email address]
We welcome corrections, pushback, and dialogue with FSSA, the Medicaid Oversight Committee, members of the General Assembly, provider associations, advocacy organizations, and journalists. Material errors identified by any party will be acknowledged and corrected in subsequent revisions.
Luminary Study No. 01 · An Analysis of Indiana's Medicaid Enrollment Workflow · October 2026 · Luminary Technologies
Cite as: Luminary Technologies. (2026). An Analysis of Indiana's Medicaid Enrollment Workflow. Luminary Study.