Before a health plan writes a single feature spec, federal rules have already settled how its claims, eligibility and enrollment data must be formatted and exchanged. Health insurance software development starts from that fixed ground, and teams that treat compliance as a final review end up reworking their data model late.
This guide covers what the platform has to do, the interoperability APIs coming due, the security obligations that apply today, and how to scope a first release you can actually ship.
What health insurance software development has to cover
A health insurance platform has to move a small, well-defined set of transactions between plans, providers and members. Federal rules name the format for each one, so the feature list is less open-ended than it looks.
The CMS page on HIPAA adopted standards and operating rules lists them. Health plans, clearinghouses and providers that conduct these transactions electronically must use the standards, all of them ASC X12 version 5010 apart from pharmacy.
| Function | Standard | What it buys you |
|---|---|---|
| Claims (institutional, professional, dental) | X12N 837 | Submission and coordination of benefits |
| Eligibility and benefit verification | X12N 270/271 | Answering "is this member covered?" in real time |
| Claim status | X12N 276/277 | Status inquiries from providers |
| Payment and remittance | X12N 835 | Electronic remittance advice and payment data |
| Enrollment and disenrollment | X12N 834 | Adding and removing members |
| Premium payment | X12N 820 | Employer premium payments |
| Prior authorization and referrals | X12N 278 | Authorization requests and responses |
Retail pharmacy is the exception. Drug claims use NCPDP D.0 instead of X12.
Read the table as the backbone of your build. Each row implies a module, a data store and a set of validation rules, and a platform that skips one will push that work back onto staff or a clearinghouse.
Features members and staff actually use
Around that backbone sit the screens people touch. Members want to check coverage, find in-network providers and see where an authorization stands. Staff want a claims queue, an eligibility lookup and a way to correct enrollment errors without a ticket to engineering.
We'd build the member-facing layer and the staff tools on the same underlying records. Two copies of a member's coverage, one for the portal and one for the call center, is how a plan ends up telling a member something its own adjuster contradicts.
When we built OptimalMD's website, members portal and mobile app, we handled the whole product from design through launch. That's a healthcare membership product rather than an insurer's claims engine, but the member-facing pieces are the same kind of work.
The four APIs the CMS interoperability rule requires
Payers covered by CMS-0057-F must build four FHIR-based APIs, with a general deadline of January 1, 2027. The CMS fact sheet on the interoperability and prior authorization final rule names the affected payers: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care, and Qualified Health Plan issuers on the federally facilitated exchanges.
If your plan sits outside those categories, the rule may not bind you directly, but it is where member and provider expectations are being set.
- Patient Access API: adds non-drug prior authorization information to the data members can already retrieve.
- Provider Access API: shares patient data with in-network providers who have a treatment relationship. Patients can opt out, and the payer must maintain an attribution process.
- Payer-to-Payer API: moves claims, encounter and clinical data to a new payer when a member switches. It covers services within five years, and the patient opts in.
- Prior Authorization API: lists covered items, identifies documentation requirements, and carries requests, approvals, denials and requests for more information.
The rule also sets decision clocks. Expedited prior authorization requests get an answer within 72 hours and standard ones within seven calendar days, with a specific reason required for any denial. Drug authorizations are excluded, and so are exchange issuers from the timeframe requirement.
The standards are specific enough to design against: HL7 FHIR Release 4.0.1 and US Core 3.1.1 are required, along with SMART App Launch and OpenID Connect for authorization. HHS is using enforcement discretion on the X12 278, so a payer can build an all-FHIR API or pair FHIR with X12.
Plan for the opt-in and opt-out rules early. Consent state has to live in your data model from the first release, because bolting it on later means touching every record that feeds an API.
HIPAA security requirements that apply today
The current HIPAA Security Rule is the one OCR enforces, and an update that has not been finalized doesn't change that. As Paubox reported in July 2026, the proposed overhaul published on January 6, 2025 has slipped, with final action now expected no earlier than July 2027.
The proposal is still worth reading, because it shows where enforcement is heading. It would drop the distinction between required and addressable safeguards, so measures like multi-factor authentication, encryption and network segmentation become mandatory in most cases.
It would also require a written inventory of technology assets and a network map covering every system that touches electronic protected health information. Risk analyses would be reviewed at least every 12 months, with vulnerability scans every six months and penetration testing every 12.
Build as though those were already law. Encryption, MFA and an asset inventory are cheap to design in and expensive to retrofit onto a live claims platform.
Our guide to HIPAA compliant app development goes through the engineering side in more detail.
Build, buy or combine
Photo by Vladimir Srajber on Pexels
A plan has three realistic routes: license an existing administration platform, build custom software, or license a core and build around it. Each has a different failure mode.
A licensed core gets you claims adjudication quickly, but your member experience and API layer inherit its limits. A full custom build gives you control of the data model and costs more upfront, so it suits plans whose process genuinely differs from the standard one.
The combined route puts custom work where differentiation lives, usually the member and provider experience and the integration layer. Whether custom healthcare software is the right call depends on how unusual your workflows are, which we cover in when custom healthcare software solutions make sense.
We haven't quoted costs here because the published figures we found came from vendors selling the work, and the spread between them reflects scope, integrations and compliance depth more than any norm. Get a scoped estimate against your own transaction list instead.
Scoping a first release
Start with one line of business and the transactions it genuinely needs. List which X12 transactions you'll process, which of the four APIs apply to you, and which systems will touch protected health data.
That list becomes the scope document and the security inventory at once. An MVP that skips it tends to discover, at the compliance review, that a reporting tool nobody mentioned also stores member data.
For the funding and prioritisation side, see how to build a healthcare MVP that gets funded. If you're ready to scope a platform, our apps and SaaS development team can work from your transaction list.
Finish the first scoping pass by writing down, for each API, the single date it must be live and who owns the consent rules behind it.
Frequently asked questions
Which transaction standards must a health plan use?
Health plans, clearinghouses and providers that conduct these transactions electronically must use the adopted ASC X12 version 5010 standards, such as 837 for claims and 834 for enrollment. Retail pharmacy uses NCPDP instead.
When are the CMS interoperability APIs due?
CMS sets January 1, 2027 as the general deadline for the API requirements. Other provisions, including the new prior authorization decision timeframes and denial reasons, began on January 1, 2026.
Is the updated HIPAA Security Rule in force?
No. The proposal was published on January 6, 2025, and Paubox reported in July 2026 that final action has been delayed to at least July 2027. The existing Security Rule remains the enforceable standard.
Does the prior authorization timeframe apply to every plan?
No. CMS excludes drug authorizations and Qualified Health Plan issuers on the federally facilitated exchanges from the 72-hour and seven-day timeframes.
Cover photo by Leeloo The First on Pexels
