Integrating with payer portals: logins, MFA, sessions and change
Your eligibility check comes back clean through the 270/271 transaction, and the claim still denies. The reason sits in a letter in the payer portal. The portal has a login, a second factor, a session that expires and a layout that changes without notice. This post covers what you find inside the main portals, which data lives only there, and how to build a connector that survives a redesign.
The portals you will meet
Availity Essentials hosts the provider portal for several payers. Aetna lists its provider portal as "Aetna provider portal on Availity" and names the functions there. The list includes claim and encounter submission, remittance advice, eligibility and claim status inquiry. It also includes precertification, referrals, member ID cards, a patient cost estimator, attachments, electronic disputes and appeals, and capitation reports.
UnitedHealthcare runs its own portal behind One Healthcare ID. The access page lists eligibility and benefits, claims, prior authorizations, referrals and a Document Library. Each user needs their own One Healthcare ID connected to the practice tax ID numbers. Portal accounts are deactivated after 90 consecutive days of inactivity.
State Medicaid portals differ by state. Utah publishes an Eligibility Lookup Tool that needs the member name, Medicaid ID, date of birth and a provider NPI known to Medicaid. North Dakota's MMIS portal allows one valid session at a time. A second login asks the user to invalidate the old session.
Logins and second factors
Treat the login as a state machine. Each portal shows a different sequence of pages, and the sequence changes over time.
Availity stopped new SMS and voice enrollments for multi-factor authentication on June 14, 2025. Users now register an authenticator app or a hard token. Availity asks for the code in selected situations, such as a login from a new device. Too many wrong codes lock the account for a period.
Alabama Medicaid added a time-based one-time password requirement to its Interactive Web Portal in December 2024. The rollout notice phased the requirement by account type from December 2024 to April 2025. Setup shows a QR code and a 24-character secret, and each login then needs a 6-digit code.
A TOTP secret is the easiest second factor to automate with the customer's consent. The practice administrator enrolls a device that your system controls, and your system generates the 6-digit code. SMS codes need a phone your system can read, and push approvals need a person. Record which factor each portal account uses, because the portal can retire a factor, as Availity did.
Session lifetimes
Few portals publish their session length. Utah states a 20-minute inactivity timeout on its eligibility tool. For the others, measure it. Log the time of the last successful request and the time of the first redirect to the login page, and keep the median per portal. Then refresh the session before that point or accept a new login with a new second factor.
Because North Dakota permits one session per account, a person who logs in at the front desk ends your connector's session. Schedule portal work outside office hours where the portal permits, and show the practice when your connector is logged in.
What the portal has that the transactions do not
The HIPAA transaction standards cover a fixed set of exchanges. CMS lists the adopted standards: 270/271 for eligibility, 276/277 for claim status, 278 for prior authorization and referrals, 835 for remittance and 837 for claims. X12 publishes a 275 Patient Information set for attachments, but the CMS table does not list an adopted attachment standard.
Compare that list with the Aetna portal functions above. Attachments, disputes and appeals, member ID card images, the cost estimator and capitation rosters have no transaction. UnitedHealthcare's Document Library holds letters that explain a denial in prose. If your product needs any of these, you need the portal.
The transactions do have timing rules the portal lacks. The CAQH CORE Eligibility and Benefits Infrastructure Rule requires a 271 response within 20 seconds in real-time mode, met for 90 percent of responses in a calendar month. It also requires system availability of at least 90 percent per week. No portal gives you that commitment. Use the transaction for anything it covers and reserve the portal for the rest.
Designing for a portal that changes
Keep the portal-specific parts in one place. A connector has a login state machine, a set of page recognizers, a set of extractors and a schema for each extracted record. Put the selectors and URL patterns in a versioned config, separate from the code that drives the browser.
Recognize pages by content. A recognizer looks at the page and returns one of a small set of states: login form, second factor prompt, dashboard, eligibility result, error, unknown. When the result is unknown, stop, store the page HTML without patient data, and alert. Never guess at an unknown page.
Validate every extracted record against a schema before you store it. A redesign that moves the member ID column produces a record that fails validation, not a record with the wrong member ID.
Give each portal account a canary task that runs on a schedule with a test member when the payer offers one, or with a read-only page such as the dashboard. A failed canary tells you the portal changed before a customer does.
Finally, keep a transaction fallback. When the portal is down or changed, an eligibility request still goes out as a 270. Mark the portal-only fields as unavailable in the response, and let the customer see which fields came from which source. TheFhirStorm returns eligibility and claim status in one schema whether the source was a transaction or a portal, so the fallback does not change the shape of the data.