> Markdown version of [/jobs/ext/4516976-engineer-data-integrations](https://www.wearedevelopers.com/jobs/ext/4516976-engineer-data-integrations). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # Engineer, Data & Integrations - **Company:** RECOURSE HEALTH LLC - **Location:** San Francisco, CA, United States - **Experience:** Experienced - **Contract:** Permanent contract - **Skills:** Adobe Acrobat, Application Programming Interfaces (APIs), Artificial Intelligence, Spreadsheets, Electronic Data Interchange (EDI), Information Extraction, Python (Programming Language), PostgreSQL, Parsing, Prism (Software), Standard Sql, Next.js, Systems Integration, TypeScript, Google Cloud, File Transfer Protocol (FTP), Fast Healthcare Interoperability Resources, Large Language Models, Claude Code, Backend, Health Level Seven International, Eobs, Data Pipelines, Legacy Systems - **Published:** November 2, 2026 - **Apply:** https://www.careerbuilder.com/job-details/engineer-data-integrations-san-francisco-ca--8352551c-e1e5-4c41-9ff9-8e13982531c7 ## About the Role Healthcare, Electronic Data Interchange (EDI), Spreadsheets, Adobe Acrobat, Litigation, Finance, Theater, Product Engineering, Sales Pipeline, Secure/SSH File Transfer Protocol (SFTP), * 4+ years building data pipelines, integrations, or backend systems in production * Strong SQL and data modeling instincts * Experience with messy real-world data: parsing, extraction, validation, reconciliation * Comfort with TypeScript or Python. The specific stack matters less than the ability to pick things up * Hands-on experience using LLMs for structured extraction from unstructured sources * Experience building in regulated or security-sensitive environments (HIPAA, SOC 2, PCI, financial controls) is a plus * A preference for small teams and early-stage chaos over mature org charts Strong plus, not required: healthcare data specifically. EDI, X12, 835/837, HL7, FHIR, clearinghouses, or revenue cycle systems. If you have it, you'll move faster. If you don't, we'll teach you. Sound judgment, technical depth, and ownership mindset are required. Grit matters more than pedigree. ## Description A federal arbitration system called Independent Dispute Resolution, or IDR, now determines billions of dollars in healthcare payments each year. Providers win the vast majority of disputes, yet most eligible claims are never filed. The process is manual, fragmented, and resource-intensive, and most providers don't have the infrastructure to pursue what they're owed. The No Surprises Act created the framework, and the market already exists. Today it runs on spreadsheets, consultants, and static playbooks. We're building the first intelligent system designed to operate inside it. Everything we do starts with data we don't control. A health system sends us 835 remittance files, 837 claim files, and explanation-of-benefits documents. If we can't reliably turn that into structured, trustworthy records, nothing downstream works. Why This Is Hard (and Interesting) Healthcare data is genuinely, memorably bad. An EOB arrives as a scanned PDF at fax resolution. Each payer formats theirs differently, so Cigna's table layout has nothing in common with United's. A single claim gets split across CPT codes in ways that only make sense if you know the payer's internal logic. Some of our customers have six separate legacy systems that reports have to be pulled from, none of which have an API. Then there's the standards layer. 835 and 837 files follow the EDI spec, mostly. The parts where they don't are where the interesting bugs live. The prize for solving this is large. Reliable ingestion is the thing that lets everything else scale, and almost nobody in this market has done it well., You'll own how data gets into Recourse and stays trustworthy once it's there. You will: * Build and maintain the ingestion pipeline for 835 and 837 files across every customer format we encounter * Own document parsing: OCR on scanned EOBs, LLM-assisted extraction, and the consistency guarantees that make it reliable * Build integrations with customer systems, SFTP endpoints, clearinghouses, and eligibility services * Design the data model that everything downstream depends on * Build the validation and reconciliation layer that catches bad data before it reaches a claim * Solve the "same document, two different answers" problem, which is the hardest reliability issue we have * Partner with operations to understand what real-world data actually looks like, not what the spec says it should look like We build with Claude Code daily and run a Codex review pass on every slice. The stack is TypeScript, Next.js, Prisma, and PostgreSQL on Google Cloud, with LLM reasoning throughout. Who You Are You like the unglamorous problems. Parsers, pipelines, edge cases, and reconciliation. The stuff that never demos well but decides whether the company works. You are AI-pilled. You've used LLMs for real extraction and parsing work and you know where they help and where they hallucinate. You have opinions about which tools are useful and which are hype. You are rigorous about correctness. Determinism matters here. If a pipeline gives different answers on different runs, that's a bug you take personally. You have a bias to action. You don't default to no. Speed of iteration over polish of iteration. You start, you learn, you fix things in motion. Most decisions are reversible and do not need extensive study. You are intellectually honest. You ask questions when you don't understand something. You say so when you're wrong. You use plain language. You respectfully challenge decisions you disagree with, and once a decision is made, you commit. You put the team first. You are reliable and fully invested. You take your vacations. You check on your teammates. You help build a culture where people do their best work because they are supported, not squeezed.