Enrollment and eligibility
Members, subscribers, dependents and coverage spans.
- 834 enrollment files from employers, exchanges and states
- 270/271 eligibility inquiry and response
- ID cards and effective-dated coverage
Healthcare / Payer Core Administration
Payer core administration software development
A core administration system holds every member, benefit, provider and claim a health plan runs on, and most of them are older than the APIs now required around them. Agnotic Technologies builds payer core modules, puts APIs around a legacy core and replaces modules one at a time, working in X12 and FHIR.
834 · 820
Enrollment and premium payment transactions
270/271
Eligibility inquiry and response
FHIR R4
APIs around the core for CMS-0057-F
Trusted by global innovators
Industry Overview
What is a payer core administration system?
A payer core administration system is the software a health plan runs on: enrollment and eligibility, benefits configuration, provider data and contracts, premium billing and claims. Agnotic Technologies builds payer core modules for health plans and TPAs, and modernizes legacy core admin systems by putting APIs around them and replacing modules one at a time.
Core modules
Which modules make up a payer core?
The functions a core administration system covers. Each one can be built, extended or replaced on its own.
Benefits configuration
Products, plan designs and cost sharing.
- Covered services, limits and exclusions
- Accumulators and cost sharing by tier
- Effective-dated plan versions
Provider data and contracts
The network and what each provider is paid.
- Provider records, NPIs and locations
- Contract terms and fee schedules
- Directory feeds and credentialing status
Premium billing
Invoicing and payment for groups and individuals.
- 820 premium payment files
- Invoices, adjustments and delinquency
- Reconciliation with enrollment
Claims
Adjudication and payment.
- 837 intake and edits
- Auto-adjudication and pend queues
- 835 remittance
Reporting and data access
What the rest of the plan needs from the core.
- Operational reporting
- Extracts to the data warehouse
- FHIR APIs for members, providers and other payers
Industry Challenges
Why is modernizing a legacy core admin system so hard?
The core touches everything, and most plans cannot stop it to replace it.
Everything depends on it: portals, APIs, finance and reporting all read the core, so a change in one table reaches every team.
Rules live in the code: decades of benefit and pricing logic with no specification other than the system itself.
Batch by design: nightly files, where portals and CMS-0057-F APIs now need answers in seconds.
Vendor timelines: a module the plan needs this year sits on a roadmap the vendor controls.
Decision table
Should you modernize or replace your core admin system?
How the two paths compare on the points that decide most core programs. Many plans do both: APIs around the core now, module replacement over time.
| Criteria | Modernize around the core | Replace the core |
|---|---|---|
| Best fit | The core works but cannot expose data or change fast enough | The core cannot express your products or is leaving vendor support |
| First result | An API or module in production while the core keeps running | A full migration and cutover before value shows |
| Risk shape | Small per step; each API or module can be rolled back | Concentrated in migration and cutover |
| Data migration | None at first; the core stays the source of truth | Full member, provider, benefit and claims history |
| Rules | Documented as each one is wrapped or replaced | Rediscovered and rebuilt all at once |
| Vendor dependence | Reduced module by module | Moves to another vendor, or to your own team |
| Cost shape | Spread over releases | Concentrated up front |
| Where it ends | A core with modern edges, with modules replaced as needed | A new core, with the same integration work afterwards |
Our Approach
How do we put APIs around a legacy core?
The sequence we use so the core keeps running while its edges change.
Read first
An API layer reads enrollment, benefits, provider and claims data from the core through its database, extracts or existing interfaces.
Write through the core
Updates go through the core's own transactions, so its rules and audit trail still apply.
Replace a module behind the API
When a module is rebuilt, the API keeps the same contract and its consumers do not change.
Retire what is empty
Core functions with no remaining consumers are switched off, with the data archived.
Capabilities
What do we build for payer core programs?
Core modules and the layer around them, built for the lines of business you run.
834 enrollment processing
Enrollment files from employers, exchanges and state agencies, with effective-dated coverage and exception handling.
Eligibility services
270/271 responses and real-time eligibility APIs for portals, providers and the call center.
Benefit configuration tools
Plan designs your analysts configure, version and test without a developer.
Provider data management
A provider record of truth with NPIs, locations, contracts and directory feeds.
Premium billing
820 payment processing, invoicing, adjustments and reconciliation with enrollment.
Core API layer
FHIR and REST APIs over the core for member apps, provider portals and CMS-0057-F.
Engineering Stack
Which standards do payer core systems depend on?
The transactions, implementation guides and platforms we work with on core programs.
X12
834820270/271837835
FHIR
FHIR R4US CoreDa Vinci PDexCARIN Blue Button
Data
PostgreSQLEvent streamsData warehouse
Backend
JavaNode.jsPython
Infra
AWSAzure
Measured Impact
What should a core program measure?
Measures we build reporting around, agreed with your operations and IT leads before launch.
Enrollment accuracy
834 records loaded without manual fixes
Enrollment transactions processed with no exception.
Eligibility latency
Time to answer a 270 or an API call
How long a portal or a provider waits for a coverage answer.
Change lead time
Days from a benefit change to production
Measured per plan version.
Core dependence
Consumers reading the core directly
Tracked down as the API layer takes over.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Compliant Women’s Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
Who do we build payer core software for?
Payer organizations whose core cannot keep up with their products or their APIs.
01
Regional health plans
Plans on a legacy core that cannot expose data or change benefit designs fast enough.
02
Medicaid managed care organizations
State 834 files, program-specific benefits and reporting.
03
Third-party administrators
Multi-client plan designs, billing and claims on one platform.
04
Insurtech and new plan startups
Payer core for startups: a first release with enrollment, eligibility and benefits before the full core.
05
Provider-sponsored plans
Plans built on a health system's data that need a core connected to the EHR.
06
Dental, vision and specialty benefit administrators
Cores for products that general-purpose systems model poorly.
Integrations
Which systems connect to a payer core?
The feeds in and the consumers out that a core program has to keep working.
Enrollment
Employers, exchanges and states (834)
Claims
Clearinghouses (837, 835)
Finance
Banks and lockbox (820, EFT)
Experience
Member and provider portals
Interoperability
FHIR server and APIs
Analytics
Data warehouse
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
Fast Healthcare Interoperability Resources
Enabling standardized health data exchange through standards-based API mappings.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we reduce development cycles and get your product to market 40% faster.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How do we build or modernize a payer core?
How to build payer core software without a stop-the-plan cutover. Timing depends on scope and is agreed on the scoping call.
01
Scoping call
We agree which module or API comes first and which systems it must keep working with.
02
Core data map
We document the core's tables, feeds and rules for that module, including the undocumented ones.
03
Fixed-scope first release
One module or API in production, reading from or writing through the existing core.
04
Module by module
Replacement modules go live behind stable APIs, each with a parallel run and a rollback path.
05
Support and change
Plan versions, new lines of business and regulatory changes under agreed support terms.
Facts and sources
Which rules shape payer core software?
Short facts behind core administration systems, each linked to its primary source.
HIPAA adopts the ASC X12 834 Benefit Enrollment and Maintenance transaction (version 005010X220) as the standard for enrollment and disenrollment in a health plan.
Source: 45 CFR 162.1502 (eCFR)HIPAA adopts the ASC X12 270/271 Health Care Eligibility Benefit Inquiry and Response as the standard for dental, professional and institutional eligibility transactions with a health plan.
Source: 45 CFR 162.1202 (eCFR)HIPAA adopts the ASC X12 820 Payroll Deducted and Other Group Premium Payment for Insurance Products transaction (version 005010X218) as the standard for health plan premium payments.
Source: 45 CFR 162.1702 (eCFR)CMS-0057-F requires impacted payers to build a FHIR-based Prior Authorization API, along with Provider Access and Payer-to-Payer APIs, with compliance dates generally beginning January 1, 2027.
Source: Federal Register, February 8, 2024 (CMS-0057-F)The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
Source: 45 CFR Part 164 Subpart C (eCFR)
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related services
Which related services do core programs use?
Detailed pages for the work that usually sits next to a core program.
Software development for health plans and payers
Our payer page: CMS-0057-F APIs, prior authorization, member and provider portals.
Healthcare software modernization
Modernizing legacy healthcare systems without a big-bang rewrite.
FHIR development services
FHIR R4 APIs and SMART on FHIR apps over your core data.
X12 EDI integration
834, 820, 270/271, 837 and 835 transactions with trading partners.
Healthcare system integration services
Connecting the core to portals, EHRs and data platforms.
Insurance eligibility verification automation
Automated eligibility checks that read from the core.
Healthcare software development company
Our healthcare industry page, with every service and audience we build for.
HIPAA requirements for software teams
The safeguards we build into every system that holds member data.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
It depends on whether the first release is an API around the existing core or a replacement module, and on how many feeds it touches. We agree a fixed-scope first release on the scoping call and give a timeline for that release, not for the whole program.
Yes. A core holds protected health information for every member, so Agnotic signs a business associate agreement before any data is shared, and we can work inside your cloud account.
Yes. We read from it through its database, extracts or existing interfaces, write through its own transactions, and keep it as the source of truth until a module is deliberately replaced.
Yes. Typical first releases are an eligibility API over the core, a benefit configuration tool, or 834 enrollment processing for one line of business.
The number of modules in scope, the lines of business and plan designs the rules must express, the feeds that must keep working, data migration from the current core and the length of the parallel run. We describe these drivers on the scoping call rather than quote a price before it.
Yes. The Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs all need enrollment, claims and authorization data that lives in the core, so an API layer over the core is often the first step for both programs.
We use AI tools to help document legacy rules and draft code and tests. An engineer reviews every output, and every rule is checked against the core's existing behaviour before release.
Industries