Hospital Intelligence Brief
Why SPARCS Records Get Rejected and How to Fix Them
A rejected record does not count toward compliance. A short list of common edits, a few file rules and a habit of checking acceptance the next day prevent most problems.
Short answer
SPARCS rejects records that fail its edits, such as an injury diagnosis with no cause-of-injury code, a race code with no ethnicity code, or a file whose segment count does not match its trailer. Rejected records do not count toward compliance, so the fix is to correct the cause, resubmit, and confirm acceptance the next day.[1]
Why does a rejected record matter?
A SPARCS submission is not finished when the file is sent. It is finished when the records inside it are accepted. The Department’s July 2026 submitter forum summary says that records not accepted into the data warehouse are not reflected in the compliance dashboards or reconciliation reports.[1] In practical terms, a rejected record is the same as a record that was never sent.
That is why rejections sit behind so many compliance problems. A facility can submit on time every month and still fall short of its volume target if a share of its records keeps failing the edits. The program says as much: discrepancies in volume are almost always due to rejected records, or to newly accepted records that have not yet reached the weekly dashboard.[1] A team that treats rejections as a routine daily task rather than a periodic cleanup is much less likely to see a warning notice.
Which SPARCS edits are triggered most often?
The July 2026 forum summary listed edits that continue to appear among the program’s ten most-triggered. They fall into three groups: missing clinical codes, missing or invalid demographic or address elements, and file structure errors.[1]
| Edit | What it means (summary of the Department’s explanation) |
|---|---|
| N0003 | An injury diagnosis code was submitted without a required cause-of-injury code. |
| N0002 | A cause-of-injury code was submitted without a required place-of-injury code. |
| H10904 | The transaction segment count in the file’s trailer does not match the actual number of segments. |
| H10023 | An unexpected segment: the file does not follow the X12 837R implementation guide. |
| H20205 | An incomplete loop: a required element, such as part of a patient address, is missing. |
| P2242038 and P2242037 | A New York county code is invalid, or is missing when the subscriber lives in New York. |
| P2242041 | A race code was received without an ethnicity code, or the reverse; a minimum of two iterations is expected. |
| P2242051 | An outpatient claim lacks a procedure code on a service line. |
The injury edits show how the logic works. A concussion diagnosis code requires a cause code, such as a fall from a tree, and the cause code in turn requires a place code, such as a forest.[1] Because the edits are chained, a registration or coding gap at one level produces an error at the next.
What file rules cause errors?
Several rejections come from the file itself rather than from any record. The forum summary gives the current rules. A file should contain data for a single facility identifier. Files sent by SFTP must begin with “FAC” followed by the facility identifier, and the original file name is limited to 89 characters. Files uploaded directly through the portal must not exceed 5 MB, and the program recommends keeping SFTP files under 10 MB.[1] It also recommends avoiding submission between midnight and 1 a.m. Eastern and avoiding the simultaneous submission of several large files.[1]
One identifier error deserves special attention. If the portal reports that the facility identifier in the file does not match the record, check three places: the identifier inside the file, the billing entity selected in the portal, and, for SFTP, the file name. All three have to agree.[1] A vendor that handles several facilities is especially vulnerable to this mistake.
What habits prevent repeat rejections?
The forum summary offers a set of working habits. Review the Processing and Errors tab when a file is rejected, and do not resubmit the same file repeatedly without correcting the cause. Log in the day after submission to confirm that the records were accepted. Remember that submitted files can be viewed on the portal for 60 days from submission, so a problem found late may mean going back to the source system.[1]
Claims that look like duplicates deserve their own attention. The summary explains that multiple original outpatient claims with the same patient, procedure codes and date of service are treated as duplicates. If two claims bill separate services, the appropriate modifiers should be included to distinguish them. If a claim needs correcting after it was submitted, it should be sent as an adjustment claim, not as a new original claim.[1]
A useful internal measure is a monthly rejection rate by edit. The Department does not publish rejection rates by facility, so a team has to measure its own. Ranking edits by count and fixing the top three at the source system usually removes most of the volume.
Who can help when an edit is unclear?
For help with rejections, the program points facilities to the Optum Help Desk, which handles portal support, file or record rejections, and interpretation of edit error reports. Callers should always provide the facility identifier. If an error report ticket is already open, the caller should update it, by replying to the existing thread or calling the help desk, rather than opening a new one.[1] Compliance questions, such as exceptions and extensions, are a separate matter and go through the compliance ticketing system, as explained in the article on 2026 changes.
Several rejection causes are best fixed by the people who capture the data, not by the people who submit it. Missing injury cause codes are typically a coding or documentation issue. Missing ethnicity codes are a registration screen issue. Address and county errors can often be prevented by validating fields at registration. Bringing those teams into the monthly review is usually more effective than asking the submitter to patch records after the fact.
Frequently asked questions
Why was my SPARCS file rejected?
Records are rejected when they fail edits, for example a missing cause-of-injury code, a race code without an ethnicity code, a segment count that does not match the file trailer, or an invalid county code.[1]
Do rejected SPARCS records count toward compliance?
No. The program says records not accepted into the data warehouse are not reflected in the compliance dashboards or reconciliation reports.[1]
What is the SPARCS portal file size limit?
Files uploaded directly through the portal must not exceed 5 MB, and the program recommends keeping SFTP files under 10 MB.[1]
How should SFTP files be named for SPARCS?
SFTP files must begin with “FAC” followed by the facility identifier, and the original file name is limited to 89 characters.[1]
Who do I contact about a SPARCS rejection?
The Optum Help Desk handles rejection and edit-report questions; callers should provide the facility identifier.[1]
What to do next
- Pull last month’s rejection report and rank edits by count.
- Fix the top three at the source system with the teams that own them.
- Confirm acceptance the day after every submission.
- Check that file names, sizes and facility identifiers follow the rules.
Explore Your Hospital’s Opportunities
Two Pillars can help hospital leadership investigate market, financial, operational and strategic questions using relevant organizational data, public information and a structured assessment process. A good first step is a SPARCS review that confirms your obligations, contacts and calendar, and sets up a simple routine your team can keep.
Sources
- New York State Department of Health, SPARCS Quarterly Submitter Forum Summary, July 30, 2026. Accessed October 2026.
- New York State Department of Health, SPARCS Data Submission. Accessed October 2026.
Sources checked October 2026. This guide is general information for healthcare leaders and is not legal, financial, clinical or compliance advice. Figures and rules are cited to the sources below and may have changed since they were accessed, so confirm anything you rely on against the current source. Two Pillars & Co is independent of the organizations cited. See our editorial policy.