Claims and X12 EDI integration
Digital Scientists builds the integrations and analytics around claims, remittance and eligibility data: X12 837 claims, 835 remittance, 270/271 eligibility and 276/277 claim status. For Congruity Health we built the pipeline that takes in claims and eligibility files from third-party administrators over secure FTPS and turns them into telehealth interventions, with 7,020 enrolled patients tracked. Clearinghouse connections such as Availity and Waystar are a capability we prove before the build depends on them. Most work starts with a week-one check of your files, your clearinghouse and your payer mix.
Updated
Enrolled patients tracked from Congruity Health claims and eligibility data
Intervention triggers the Congruity platform raised from claims data
Cardiometabolic savings identified for Congruity Health
RAF improvement from risk adjustment AI that used claims among six data sources
Do you integrate claims, remittance and eligibility data?
Yes. We've built pipelines that take in claims and eligibility data and turn it into work people act on, and we connect to clearinghouses, payers and billing systems through X12, APIs or secure files.
X12 is the EDI standard HIPAA requires for administrative transactions between providers, payers and clearinghouses. Version 5010 is the one in use today.
Our delivered work is file and API based. For Congruity Health, claims and eligibility files from third-party administrators (TPAs) land on a secure, client-specific FTPS server, then move into BigQuery for rules and analytics. For Fathers' UpLift, we sync patient demographics, billing claims and charge capture with Tebra through its SOAP API, so Tebra stays the billing system of record.
Direct clearinghouse connections are a capability. We haven't run one in production, and we'll say so in the plan. Claims work is one part of our healthcare integration services, alongside EHRs, FHIR, labs and payer APIs.
TPA files
Claims and eligibility over secure FTPS. Delivered for Congruity Health
Billing systems
Tebra SOAP API for claims and charge capture. Delivered for Fathers' UpLift
Clearinghouses
Availity, Waystar and others. Capability
Payers
Direct 270/271 and 276/277 where the payer offers it. Capability
Which X12 transactions do you work with?
The ones that carry the revenue cycle: 837 claims out, 999 and 277CA acknowledgments back, 835 remittance back, plus 270/271 eligibility and 276/277 claim status. The status column says what we've delivered and what's capability.
Each transaction has a direction and a job. A claim goes out as an 837. The clearinghouse or payer answers twice before any money moves: a 999 says the file was readable, and a 277CA says each claim was accepted or rejected. Weeks later the 835 reports what was paid, adjusted or denied.
Every payer publishes a companion guide that narrows the standard, so two payers rarely want exactly the same 837. We test against the clearinghouse or payer's test environment before go-live. Acknowledgments matter more than they look: a rejected claim that nobody reads is a claim that never reached the payer.
X12 transactions, what each carries and where we stand
| Transaction | What it carries | Direction | Status |
|---|---|---|---|
| TPA claims and eligibility files | Paid claims and member eligibility for self-funded health plans | TPA to platform, over secure FTPS | Delivered (Congruity Health) |
| 837P / 837I claim | Professional or institutional claim: patient, provider, diagnoses, procedures, charges | Provider to payer, usually through a clearinghouse | Capability for submission; claims data analytics delivered |
| 999 acknowledgment | Whether the file passed syntax checks | Clearinghouse or payer to provider | Capability |
| 277CA claim acknowledgment | Each claim accepted or rejected at the front door | Payer or clearinghouse to provider | Capability |
| 835 remittance (ERA) | Payments, adjustments and denial reason codes, claim by claim | Payer to provider | Capability |
| 270/271 eligibility | Coverage inquiry and the payer's answer: plan, dates, copay, deductible, benefits | Provider to payer and back | Capability |
| 276/277 claim status | Where a submitted claim stands in the payer's process | Provider to payer and back | Capability |
| 278 prior authorization | Request and response for services that need approval | Provider to payer and back | Capability; see payer APIs and prior authorization |
Delivered: built for a client and handed over or run for them. Capability: we know the transaction and build to it, proved against the clearinghouse or payer's test environment before the build depends on it.
Can you automate eligibility checks before the visit?
Yes, as a capability. A 270 asks the payer whether the patient is covered, and the 271 answers with plan, coverage dates, copay, deductible and benefits by service type. We'd run it in batch before the schedule opens and on demand at intake.
We haven't run real-time 270/271 in production. The closest delivered work is Congruity Health, where eligibility files from TPAs decided which members the platform tracked and who was enrolled.
The hard part is the 271. Payers return benefits in different shapes, and an "active coverage" flag doesn't tell the front desk what to collect. Eligibility problems are also among the most preventable denials, which is why we check them upstream of the claim.
Batch checks
Run tomorrow's schedule overnight through your clearinghouse and flag inactive coverage or changed plans before the patient arrives.
Checks at intake
A real-time 270 when a new patient books or reports a new payer.
Readable results
Parse the 271 into what staff need: active or not, copay, deductible remaining and services that need prior authorization.
Exceptions to a person
Coverage problems go to a work queue with the reason attached, where someone owns them before the visit.
What do you do with claims and 835 data once it's flowing?
We turn it into decisions: which claims will deny, which accounts collectors should work first and where payers paid less than expected. Claims and remittance history are the raw material for revenue cycle AI.
Our revenue cycle AI work starts here. Two of our AI guides set out the approach. A/R collection prioritization ranks accounts by how likely they are to collect, not by age or balance alone. Claim follow-up triage flags high-risk claims within days of submission, before the denial arrives.
Both are frameworks built on 837, 277 and 835 history. They describe how we'd build it, not a client result. Both need clean history: two years or more of claims, payments and denial reason codes. The table shows which transaction feeds which decision.
What each signal comes from and what it drives
| Signal | Where it comes from | What it drives |
|---|---|---|
| Denial reason codes (CARC and RARC) | 835 remittance | Denial patterns by payer, code and facility |
| Claim rejected at the front door | 999 and 277CA | A fix-and-resubmit queue before timely filing runs out |
| Claim status and age | 276/277 and claim history | Follow-up triage and collector work lists |
| Paid against expected | 835 against your payer contracts | Underpayment flags; see payer contract interpretation |
| Coverage changes | 271 eligibility responses | Eligibility denials stopped before the claim goes out |
What claims and billing work have you delivered?
Three projects ran on claims or billing data: Congruity Health's analytics platform, CommuniCare's risk adjustment engine and CommuniCare's MDS platform. None was an X12 clearinghouse build, and the hard parts carry straight over.
Congruity Health. We built the pipeline from FTPS to AWS S3 to BigQuery, a rules engine that raised intervention triggers, Salesforce tasks for telehealth agents and Tableau dashboards for employers and TPAs. Each client got its own isolated pipeline.
CommuniCare risk adjustment. Claims were one of six data sources, with diagnoses, health risk assessments, medications, progress notes and lab results, behind AI that surfaced missed HCC codes. It delivered $10M+ in RAF improvement at 90%+ accuracy for 20K+ patients across 7 states and 245 providers.
CommuniCare MDS. The MDS assessment sets the PDPM payment on a skilled nursing facility's Medicare Part A claim. We built the platform from April 2024 and handed it to CommuniCare's own team.
How it transfers: files that arrive late or malformed, patients with more than one ID and audit trails that tie every number to its source are the same problems in X12 work.
Intervention triggers from claims data (Congruity Health)
Recovered to date (MDS)
Forecast PDPM revenue (MDS)
Where does a claims integration project start?
With a week-one check of your files, your clearinghouse and your payer mix. If a clearinghouse enrollment or a payer's companion guide is the risky part, we prove it first.
Vendor paperwork sets more of the calendar than the code does. Clearinghouse onboarding, payer enrollment for 835 remittance and trading partner agreements all take time, so we start them on day one. These are common starting points, not rules.
Week-one integration check
Sample files, companion guides, clearinghouse access and a dated plan before the build depends on any of it.
Blueprint
When the claims feed is part of a bigger product, a Blueprint sets the architecture, the user stories and the integration risks before the build.
Start with files you already have
If 835s and claims extracts already sit on a server, start with denial patterns and A/R ranking before any new connection.
We run it, or hand it over
For platforms we build, L2 and L3 support with monitoring on every feed, and build-operate-transfer when your team is ready. See platform operations.
Work built on claims and billing data
Congruity Health
7,020 enrolled patients tracked
Claims and eligibility files from TPAs, taken in over secure FTPS and turned into telehealth interventions for chronic disease.
See the work
CommuniCare risk adjustment
$10M+ at 90%+ accuracy
Claims were one of six data sources behind AI that recaptured missed HCC codes for 20K+ patients across 7 states.
See the work
CommuniCare MDS
$10M+ recovered to date; $24M+ forecast PDPM revenue
MDS assessments set PDPM payment on Medicare claims. Built from April 2024 and handed to CommuniCare's own team.
See the workTrusted by healthcare leaders.
“The team at Digital Scientists was a huge help in not only developing our analytics platform, but understanding the competitive space and defining our true value proposition for our customers.”
Justin Davis
CEO, Congruity Health
Related healthcare integration work
Healthcare integrations
EHR, FHIR, labs, payers, claims and HIPAA cloud.
Healthcare integrations →Payer APIs and prior authorization
Eligibility, CMS payer FHIR APIs and electronic prior auth.
Payer APIs and prior authorization →FHIR and HL7 integration
Standards-based clinical data exchange.
FHIR and HL7 integration →EHR integration
PointClickCare and Netsmart (GEHRIMED) in production.
EHR integration →Revenue cycle AI
Denials, A/R and payer-aware intelligence.
Revenue cycle AI →Healthcare data engineering
Pipelines, warehouses and patient matching across sources.
Healthcare data engineering →
Questions about claims and X12 integration
Do you connect to clearinghouses?
Yes, as a capability. Availity, Waystar and most other clearinghouses accept 837 claims and return 999, 277CA and 835 files over SFTP or APIs, and many offer real-time 270/271 and 276/277. We haven't run a clearinghouse connection in production; our delivered claims work took in TPA files over secure FTPS. We connect through the clearinghouse you already use, test in its environment and start enrollment in week one.
Can you automate eligibility checks?
Yes. We'd send 270 inquiries in batch the night before the schedule and in real time at intake, parse each 271 into what staff need (active coverage, copay, deductible remaining, prior auth flags) and route problems to a work queue. We haven't run real-time 270/271 in production yet. Our closest delivered work is the TPA eligibility files behind Congruity Health's platform.
Can you reconcile 835 remittances to claims and deposits?
Yes, as a capability. An 835 reports what the payer paid, adjusted and denied, claim by claim, with CARC and RARC codes explaining each adjustment. We match each payment to the original claim, match the ERA to the bank deposit by its trace number, and flag denials and underpayments for follow-up. We prove it against your own remittance files before anyone relies on it.
How do you handle PHI in claims files?
We sign a BAA before we touch patient data. Files move over encrypted channels such as FTPS or SFTP, are encrypted at rest, and are read only by the services and people whose role needs them, with an audit log of every access. For Congruity Health each client had its own FTPS server and its own isolated pipeline. Our security plan is mapped to NIST CSF 2.0, and the pipeline can run in your own AWS account.
Do we need an EDI translator or integration engine?
Not always. If you already run an EDI translator or interface engine, we connect to it and work with the people who run it. If you don't, we parse and build X12 in code, on queues with retries and monitoring, inside your cloud account, so you own the code and skip a license. We choose in the week-one check.
How long does a claims integration take?
The vendors set most of the calendar. Clearinghouse onboarding, payer enrollment for 835 remittance and each payer's testing steps take longer than the code. We start that paperwork on day one, build against test files in parallel and give you a dated plan after the week-one check.
Talk it over
Tell us what you are trying to do. A senior person from our Atlanta team replies within one business day, and you can book a 30-minute call right after you send this.
- We tell you if we're the right fit, and if we're not, who is.
- Most work starts small, so you see how we work before you commit to more.
- We sign a BAA before we touch patient data.