Medical billing software testing

Why does a billing defect not surface as a failure?

The claim it produces is valid. The schema accepts it, the required fields are populated, the code is a real code, and the system records a success. The defect sits in the choice the software made, so nothing inside the product is placed to notice it: every assertion written against the software's own output agrees with the software. The payer answers later, and the same rule has already run across every claim submitted in between.

That changes what the testing has to be. A functional suite asks whether the system did what it was told to do. On a billing product the open question is whether what it was told is right for this claim, and no arrangement of the product's own components can answer it.

What can a claim be checked against, other than the product itself?

Five artefacts qualify, and they are not equally available.

The code set release files are the first. 45 CFR 162.1002(c) adopts ICD-10-CM and ICD-10-PCS "as maintained and distributed by HHS", and each release ships as a named file carrying a stated effective date. Whether a code exists, and whether it existed on a given day, is settled by that file rather than by a lookup table inside the product.

The implementation guide adopted for the transaction is the second, and it is the only artefact here that has to be bought. 45 CFR 162.920(a) puts that in the regulation: "A fee is charged for all implementation specifications, including Technical Reports Type 3." What the regulation publishes is the designation of each guide, its title, version, date and document number, together with the section that adopts it. A test plan that treats a payer's companion guide as the specification has substituted a document one trading partner wrote for the one the Secretary adopted.

The Official Guidelines are the third, and they are inside the adopted standard rather than beside it. section 162.1002 adopts ICD-10-CM "including The Official ICD-10-CM Guidelines for Coding and Reporting", and uses the same construction for the PCS guidelines. A construction rule stated there binds the same way the code list does. What the code sets are, how they are built and what their release calendar does to stored data is covered in ICD-10 code mapping testing requirements.

The payer's adjudication response is the fourth. It is authoritative and it arrives after submission, which makes it excellent for seeding regression cases and useless as a pre-submission oracle.

The fifth is the clinical record the claim was derived from, and it is the only one that answers whether the code matches the care that was given. It also sits inside the customer's estate and is PHI, so reaching it is a contractual question before it is a technical one, raised at how we work with protected health information and settled before an environment exists. Where that record cannot be reached, the suite can still check the claim against the code set and against the product's own upstream inputs, and the gap between those two levels of assurance belongs in the test plan in writing.

Which rules bind a billing product?

45 CFR 162.1002 adopts the code sets by name, and ICD-10 is not the whole of what it adopts: paragraph (c)(1) pulls in the code sets at paragraphs (a)(4), (a)(5), (b)(2) and (b)(3) by cross reference, and the section also names HCPCS, CPT-4 and the Code on Dental Procedures and Nomenclature. Each of those has its own update cadence, so a product that holds several of them is tracking several calendars at once.

The table below maps the provisions a billing product is measured against to the assertion each one supports. Every row is a sentence a test can be written from.

HIPAA code set and security provisions in 45 CFR parts 162 and 164, each set against the assertion a billing product test suite makes.

Provision	What it says	What the suite asserts
45 CFR 162.1002(c)(2)	Adopts ICD-10-CM, including the Official Guidelines, for diseases, injuries, impairments, other health problems and their manifestations, and the causes of those	The validator encodes the guidelines' construction rules, not a payer edit sheet the guidelines do not support
45 CFR 162.1002(c)(3)	Adopts ICD-10-PCS for prevention, diagnosis, treatment and management on hospital inpatients reported by hospitals	An outpatient or professional claim is built without reaching into PCS
45 CFR 162.1000(a)	Use the medical data code sets valid at the time the health care is furnished	The verdict on a code follows the date of service, across every release the system accepts
45 CFR 162.1000(b)	Use the nonmedical data code sets valid at the time the transaction is initiated	A resubmission moves this anchor and leaves the date of service anchor where it was
45 CFR 164.312(c)(1)	Protect ePHI from improper alteration or destruction	An amended or reversed claim leaves a record of what changed and who changed it
45 CFR 164.312(e)(2)(i)	Transmitted ePHI is not improperly modified without detection until disposed of	A claim altered between the product and the receiver is detected by the receiver, not inferred later from a remittance
45 CFR 164.312(b)	Record and examine activity in systems that contain or use ePHI	The submission, the acknowledgement and the resubmission are each recorded as activity
45 CFR 164.316(b)(2)(i)	Retain the documentation for six years from creation or last effect	Test evidence for a release is retained on the same clock as the policies it supports

Who the rules bind is settled in the definitions. 45 CFR 160.103 makes a health care clearinghouse a covered entity in its own right, alongside health plans and providers who transmit health information electronically in connection with a covered transaction. The same section lists claims processing or administration, billing, benefit management and repricing among the functions that make a person a business associate, and 45 CFR 164.104(b) extends Part 164 to business associates where the standards so provide. A billing product's supplier is therefore usually inside the rule by the definition rather than by contract choice. What of the Security Rule can actually be tested, and what it obliges the customer to keep, is set out in the testable part of the HIPAA Security Rule.

Which transaction standard does a claim have to be built to?

The one part 162 adopts for that transaction, for the period in which the transaction is conducted. Each transaction subpart is built the same way: the first section says in plain English what the transaction is, and the second names an implementation guide by title, version, date and document number, for a stated range of dates. The answer to "what is our standard" is therefore always an answer about a date, and a product that holds only the current answer has nothing to compare a historical file against.

45 CFR 162.923(a) is the obligation. A covered entity conducting a covered transaction electronically with another covered entity "must conduct the transaction as a standard transaction". Paragraph (b) carries the exception a billing product meets most often. Where a provider uses direct data entry offered by a health plan, the provider "must use the applicable data content and data condition requirements of the standard" and "is not required to use the format requirements of the standard". A web form that raises a claim is inside the data content rules and outside the format rules, so a suite that tests the form as though the standard did not reach it is testing the wrong half.

Every designation below is transcribed from the section of 45 CFR part 162 that adopts it. Nothing about the contents of any of these guides appears on this page, because they are sold rather than published.

HIPAA transaction standards for billing, with the 45 CFR part 162 section adopting each and the implementation guide designation it names.

Transaction	Section that adopts the standard	Designation named in the regulation
Health care claims, professional	45 CFR 162.1102	ASC X12N/005010X222
Health care claims, institutional	45 CFR 162.1102	ASC X12N/005010X223 with Type 1 Errata 005010X223A1
Health care claims, dental	45 CFR 162.1102	ASC X12N/005010X224 with Type 1 Errata 005010X224A1
Coordination of benefits	45 CFR 162.1802	The same three 837 guides as the claim
Health care claim status	45 CFR 162.1402	ASC X12N/005010X212 with Errata 005010X212E1
EFT and remittance advice	45 CFR 162.1602	ASC X12N/005010X221 for the remittance advice, and a NACHA CCD+ specification for the payment
Eligibility for a health plan	45 CFR 162.1202	ASC X12N/005010X279
Referral certification and authorization	45 CFR 162.1302	ASC X12N/005010X217 with Errata 005010X217E1
Medicaid pharmacy subrogation	45 CFR 162.1902	NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3.0
Health care claims attachments	45 CFR 162.2002	ASC X12N/006020X314 (275) and ASC X12N/006020X313 (277), with HL7 CDA and C-CDA guides, from 26 May 2028

Three rows repay a second reading. Coordination of benefits is carried by the same three 837 guides as the claim itself, so a COB transaction has no guide of its own to conform to. Medicaid pharmacy subrogation is the only adopted transaction in the part with no ASC X12 component at all. And the attachments row is the only place in part 162 where an X12 designation is Version 006020.

Every other X12 guide in that table is a Version 005010 Technical Report Type 3 adopted for the period on and after 1 January 2012, and none of the amendments made in 2024, 2025 or 2026 moved an X12 version. What moved was NCPDP, twice. The accurate statement is that 5010 is the version part 162 currently adopts, which is narrower than saying 5010 is the current X12 version: what ASC X12 has published since sits outside the regulation.

One transaction named in the definitions has no standard at all. 45 CFR 160.103 lists first report of injury among the transaction types HIPAA administrative simplification covers, and part 162 contains no subpart for it. A product that advertises support for it is supporting a trading partner's format, because there is no adopted one to support.

The release calendar is also not shared. 45 CFR 162.1402(c) adopts the claim status standard "for the period on and after January 1, 2012" and stops there, with no 2027 or 2028 paragraph. Claims, eligibility, referral certification and authorization, coordination of benefits and Medicaid pharmacy subrogation each carry both. A regression plan that puts every transaction on one calendar is wrong about the five dated transactions or wrong about claim status.

Do we have to support claims attachments yet?

Not yet, and the date is fixed. 45 CFR 162.2002 adopts the attachment standards "for the period on and after May 26, 2028", so nothing in subpart T is enforceable today. The subpart was added by the final rule at 91 FR 14350 of 24 March 2026, whose DATES block reads: "Effective Date: This final rule is effective on May 26, 2026 ... Compliance Date: Compliance with these regulations is required by May 26, 2028." A standard for this transaction was proposed at 70 FR 55990 in 2005 and never finalised, which is why so much written guidance still says none exists.

The two-year gap is statutory. The rule's preamble attributes it to section 1104(c)(3) of the Affordable Care Act, which "prescribes a uniform 2-year compliance date for all covered entities (with no special provision for small health plans, unlike the original HIPAA statute)". A small health plan is on the same date as a large one.

What subpart T adopts is different in kind from the rest of the part. 45 CFR 162.2001 defines the transaction as attachment information sent from a provider to a plan in support of a claim, or a request from a plan to a provider for that information. 45 CFR 162.2002 then adopts an X12 guide for each direction and HL7 CDA and C-CDA guides for the attachment itself, so an attachments transaction couples an X12 envelope to an HL7 clinical document and a test fixture needs both halves.

The electronic signature requirement has a boundary worth writing into the plan now. The preamble states that the signature standard applies "when an electronic signature is used to sign attachment information at the time it is transmitted", and that it "does not apply to documents created prior to transmission that may later be included in a claims attachment; only signatures affixed in the course of a HIPAA-standard attachment transaction must meet the standard". A consent form signed last year and scanned into the record is not pulled inside the standard by being attached to a claim.

Is a CORE certificate evidence that the transaction is right?

A CORE certificate is evidence about a scheme the regulation declined to adopt. Operating rules exist for three transactions: eligibility at 45 CFR 162.1203, claim status at 45 CFR 162.1403, and EFT and remittance advice at 45 CFR 162.1603. The first two adopt the CAQH CORE rules "Excluding where the CAQH CORE rules reference and pertain to acknowledgements and CORE certification", so certification sits outside what part 162 makes binding. On the remittance side 45 CFR 162.1603(a)(6) adopts the Phase III CORE 350 infrastructure rule "except Requirement 4.2 titled 'Health Care Claim Payment/Advice Batch Acknowledgement Requirements'", so acknowledgement behaviour around the 835 is a trading partner matter and a test that reports it as a federal requirement is reporting something the regulation left out.

For the 837 claim there is no adopted operating rule at all. Subparts K, M, O, Q, R, S and T carry no operating-rules section, which leaves claims, referral certification and authorization, enrolment, premium payments, coordination of benefits, Medicaid pharmacy subrogation and attachments with an adopted standard and nothing beside it. The payer's companion guide fills that space in practice, and 45 CFR 162.915 sets four limits on what a trading partner agreement may do.

The plan side of this is testable from outside, because 45 CFR 162.925 states what a health plan may not do. It may not reject a standard transaction "on the basis that it contains data elements not needed or used by the health plan (for example, coordination of benefits information)". It must "accept and promptly process any standard transaction that contains codes that are valid, as provided in subpart J of this part", and it must keep code sets for the current billing period and for appeals periods still open under the plan's coverage. A rejection traced to one of those belongs in a different queue from a product defect, and the difference is only visible if the rejection reason is captured with the claim rather than counted.

What has to be exercised that a general suite will not reach?

The date of service comes first, and it needs more than one code set release loaded at the same time. FY2027 ICD-10-CM takes effect on 1 October 2026 and deletes thirty codes that were valid the day before. A September claim corrected and resubmitted in October is still a September claim, and 45 CFR 162.1000(a) anchors its verdict to the September release. A system holding one current code set answers wrongly on exactly the population that already went wrong once, which is the population being resubmitted.

Stored descriptions are the second, and they fail a code comparison silently. FY2027 ICD-10-CM revises four code descriptions without changing the codes themselves. A remittance advice, a patient statement or a denial report that prints a description copied at the time of the original claim prints text the code set no longer carries, while a regression that diffs the code list alone reports no change at all.

The rest are properties of the money path rather than of the code sets.

Reconciliation is where the interesting defects live, because it is the only step that compares two systems that were built by different teams under different assumptions. A duplicate created by a resubmission, a partially accepted claim whose unaccepted lines are dropped, and a reversal that leaves the ledger and the claim disagreeing are all invisible to a suite that tests each system on its own. Where the same reconciliation has to run against historical data loaded from a previous product, it is the same work as healthcare data migration testing.

What crosses a system boundary here?

Charges usually originate somewhere else. In an HL7 v2 estate they arrive as DFT, which HL7 Table 0076 defines as "Detail financial transactions" and places in chapter 6, Financial Management. That chapter "describes patient accounting transactions", and states that the DFT message "is used to describe a financial transaction transmitted between systems, that is, to the billing system for ancillary charges, ADT to billing system for patient deposits, etc." The trigger is P03, listed in Table 0003 as "DFT/ACK - Post detail financial transaction". BAR, "Add/change billing account", sits in the same chapter, so the account a charge posts to is created by a different message from the charge itself.

Two properties of that structure make test cases. In DFT_P03, MSH, EVN and PID are all 1..1 and required, while the VISIT group that opens with PV1 is 0..1: a conforming charge message can arrive carrying no visit, and what the billing product does with it is a decision somebody made rather than a parser outcome. Chapter 6 also defines an expanded trigger, P11, with its own structure DFT_P11, so an interface described as "we support DFT" covers two messages and needs fixtures for both. The general form of this work is in HL7 v2 conformance testing requirements, and the upstream system that raises most of these charges is covered in EHR and EMR testing.

On the FHIR side the stability question is the one to settle before writing the suite. The R4 resource index lists 145 resources and exactly 11 carry the Normative marker: Binary, Bundle, CapabilityStatement, CodeSystem, Observation, OperationDefinition, OperationOutcome, Parameters, Patient, StructureDefinition and ValueSet. No financial resource is among them. R4's own forward look says of the next release that "most if not all clinical knowledge/reasoning, care planning, and financial resources, are likely to remain at the Trial Use level as they are not expected to meet the criteria for Normative", and the specification states of Draft and Trial Use content that "there are no rules for maintaining any sort of compatibility between versions for content with these statuses".

Three things follow for a billing interface built on FHIR. The version string belongs in the fixture, and it is 4.0.1 rather than "R4", because 4.0.0 and 4.0.1 are distinct published artefacts. A conformance claim can be pinned only to what the server declares in the CapabilityStatement it returns from GET [base]/metadata, which is the one interaction every FHIR server is required to support. And an upgrade of the financial resources is a breaking-change candidate by the specification's own rule, so the suite has to be executable against two versions rather than migrated to the new one. Proving either interface end to end, across the systems that raise the charge and the systems that answer it, is healthcare interoperability testing.

Where does billing testing go wrong?

• Expected values in the suite are captured from the product's own output, so the suite ratifies the defect it was meant to catch.
• One code set release is loaded, so any claim whose date of service is outside the current release gets a verdict from the wrong file.
• The suite reports that a claim differs from the expectation without reporting which way the difference runs, so overbilling and underbilling arrive in the same queue at the same priority.
• Resubmission is tested as a happy path, so nothing exercises the case where the first submission was accepted and the receiver now holds two claims.
• Partial acceptance is treated as failure, so the lines that were accepted are never followed to the ledger.
• The ledger is asserted against the balance the product reports rather than against the sum of its own transactions, so a reversal that posts twice reconciles perfectly.
• Descriptions are copied at claim time and compared never, so a revised code description prints on statements long after the code set changed.
• The charge interface is stubbed, so a DFT message with no VISIT group never reaches the product under test.
• FHIR fixtures are pinned to "R4" rather than to 4.0.1, so a version change in Trial Use financial content lands as a runtime surprise.
• The adopted guide designation lives in a comment rather than in the fixture, so nothing in the suite fails when an adopted period ends.
• Every transaction is assumed to be on one release calendar, so the open-ended claim status standard and the dated claims standard are exercised as though they moved together.
• The payer's companion guide is treated as the specification, so a requirement 45 CFR 162.915 forbids is encoded as a pass condition.
• A CORE certificate is filed as evidence for eligibility and claim status, which 45 CFR 162.1203(b) and 162.1403(b) exclude from what is adopted.
• Test data is real claims, without the contract that permits it.

What do we run against a billing product?

The first piece of work is naming the oracle for each assertion, because that is what decides whether a green suite means anything. Assertions that can be settled against a published code set release go first, since the release files carry effective dates and can be loaded side by side. Assertions that need the clinical record are scoped separately, with the data question settled before the test question. Assertions that only the payer can settle are marked as such and fed back from production responses into regression rather than pretended to in advance.

From there the suite is built along the money path instead of along the module boundaries, because the defects worth finding sit between systems. Where the annual code set changeover has to run without a manual regression cycle, and where two code set releases have to stay loaded and exercised at once, that is healthcare test automation work.

The regulatory statements on this page were checked against the primary texts: 45 CFR 162.1000 and 162.1002 as published in GPO's govinfo XML of the CFR annual edition dated 1 October 2024, 45 CFR 160.103 and 164.312 through 164.316 as published in the eCFR XML for title 45 current as of 31 August 2026, the transaction and operating-rule sections of 45 CFR part 162 subparts I through S as published in GPO's govinfo XML of the CFR annual edition dated 1 October 2025, 45 CFR 162.2001 and 162.2002 together with the effective and compliance dates for claims attachments as published in the Federal Register final rule 91 FR 14350 of 24 March 2026, the FY2027 ICD-10-CM release files, HL7 Terminology code systems v2-0076 and v2-0003 with chapter 6 of HL7 v2, and the FHIR R4 specification at version 4.0.1. The ASC X12, NCPDP, CAQH CORE, NACHA and HL7 implementation guides named above were not read, and nothing on this page describes their contents.