Dental Insurance Automation Developer

Senior AI / Automation Developer — Build Dental Insurance Verification & RCM Platform We are a growing pediatric dental practice in Seattle looking for a senior software developer to build an AI-enabled dental insurance verification and revenue-cycle automation platform. This is not a dental billing or virtual assistant position. We are looking for a strong developer who can build software that automates the work currently performed manually by experienced dental insurance and revenue-cycle staff. Our practice-management system is Oryx Dental, and we also use Vyne for insurance/claims workflows. Initial Project: Comprehensive Dental Insurance Verification The first module will automatically perform detailed insurance verification for patients scheduled at our practice. A simple eligibility check is not sufficient. The system should determine detailed procedure-level benefits, limitations, history and eligibility. For example, for a pediatric patient, the system should be able to determine: General Benefits • Active coverage and effective dates • Subscriber/member information • Individual and family deductibles • Deductible remaining • Annual maximum • Annual maximum remaining • Preventive/basic/major coverage percentages • Waiting periods • Plan type • Network status • Coordination-of-benefits information where available Pediatric Procedure-Level Benefits We need detailed verification for procedures including: • D0120 / D0140 exams • D0210 full-mouth radiographs • D0220/D0230 periapical X-rays • Bitewings • Prophylaxis • Fluoride • D1351 sealants • Space maintainers • Stainless-steel crowns • Fillings • Pulpotomies • Extractions • Other common pediatric dental procedures • Orthodontic benefits For sealants, for example, the system should determine where available: • Is D1351 covered? • Coverage percentage • Eligible ages • Eligible teeth • Frequency limitation • Replacement/reapplication limitation • Prior sealant history • Last date of service • Whether coverage is based on calendar year or rolling months • Any plan-specific exclusions or limitations This level of detail is important. Data Retrieval Strategy We expect the developer to design a layered system that can obtain information through multiple channels. Preferred hierarchy: 1. Insurance / clearinghouse APIs 2. Vyne or other available eligibility APIs 3. Insurance payer portals 4. Browser/RPA automation when APIs are insufficient 5. AI extraction from PDFs or benefit documents 6. Eventually automated payer phone calls where necessary 7. Human exception handling when automation cannot confidently determine the answer We do not want a system that simply uses an LLM to guess at benefits. Every benefit should ideally include: • Source • Retrieval timestamp • Confidence level • Raw source data or evidence • Normalized result Example Workflow Each evening, the application might: 1. Pull the next day's patients from Oryx. 2. Identify patients requiring insurance verification. 3. Retrieve insurance demographics. 4. Query available eligibility APIs. 5. Determine which benefit fields are missing. 6. Log into payer portals where additional information is necessary. 7. Retrieve procedure-level benefit details and history. 8. Normalize the data into a standard schema. 9. Flag conflicting or uncertain information. 10. Write verified benefits into our internal system and potentially back into Oryx. 11. Present staff with an exception queue for cases requiring manual attention. Longer term, we want to expand the platform beyond eligibility into broader revenue-cycle automation. Longer-Term RCM Modules Potential future modules include: • Claim creation and claim scrubbing • Required-attachment identification • Automatic attachment of radiographs and documentation • Rejected-claim correction • Denial categorization • Appeal generation • Aging-report management • Automated payer-portal follow-up • Automated insurance phone calls • ERA/EOB reconciliation • Payment posting • Patient-balance reconciliation • Coordination-of-benefits workflows • Timely-filing monitoring • Human approval queues for financial adjustments Our long-term goal is a system where humans manage exceptions, rather than manually processing every claim. Technical Background We Are Looking For Strong candidates will have meaningful experience with several of the following: • Python • TypeScript / Node.js • FastAPI • Selenium • Playwright • Browser automation • RPA • API integrations • REST APIs • OAuth • Webhooks • PostgreSQL or similar databases • AWS / Azure / GCP • LLM APIs • Structured LLM outputs • Agent frameworks such as LangGraph, OpenClaw, GrokBot, Claude-based agents, or similar • PDF/document extraction • OCR/document intelligence • Workflow orchestration • Secure credential management • Audit logging • Healthcare software integrations Experience with dental insurance portals or healthcare payer portals is a major advantage. Experience with systems such as: • Oryx Dental • Vyne • DentalXChange • Availity • Delta Dental • Premera • Regence • Guardian • MetLife • Cigna • Aetna • UnitedHealthcare would be particularly valuable. HIPAA / Security This application may ultimately process protected health information. The production architecture therefore must be designed appropriately for healthcare data. Candidates should understand concepts such as: • HIPAA • Business Associate Agreements • Encryption at rest and in transit • Role-based access • Secure credential storage • Audit logging • PHI-safe application logging • Data-retention policies • Environment separation • Least-privilege access Please do not apply if your proposed architecture is simply to put patient information into consumer AI products or an unmanaged browser automation environment. Who We Are Looking For We want a developer who thinks like a software architect, not someone who simply chains together prompts. The ideal candidate will look at a problem such as: "Determine whether this 7-year-old patient is currently eligible for D1351 sealants, on which teeth, at what coverage percentage, subject to what age/frequency limitations, and whether prior history makes the patient currently eligible." and think about: • structured data models • APIs • payer-specific adapters • state machines/workflows • browser automation • source provenance • confidence scoring • exception handling • retry logic • audit trails rather than simply asking an LLM to answer the question. Initial Engagement We would like to begin with a relatively small paid proof of concept. Proof-of-Concept Goal Build a workflow that takes patient insurance information and retrieves detailed benefits for a defined set of procedures from several dental insurance carriers. For example: • Delta Dental • Metlife • Cigna • Guardian • Regence The prototype should normalize the results into a structured data model and clearly identify any fields it cannot confidently determine. If the proof of concept is successful, this could become a substantial ongoing project covering the complete revenue cycle. When Applying Please answer the following questions. 1. Relevant projects Describe the most technically similar automation system you have personally built. Please provide enough technical detail that we can understand what you personally implemented. 2. Insurance portals Have you automated healthcare or insurance websites before? If so, which types of workflows? 3. Browser automation What framework would you use for payer-portal automation and why? For example: • Playwright • Selenium • UiPath • another approach 4. API vs. browser automation How would you decide when to use an API versus browser automation? 5. Sealant example Assume we need to determine whether a pediatric patient is eligible for D1351 sealants. We need: • coverage percentage • age limitation • tooth limitation • frequency limitation • prior procedure history • last date of service The eligibility API only returns coverage percentage. Briefly describe how you would design the workflow to obtain the remaining information. 6. Data architecture How would you design the normalized data model for benefits received from many different insurance companies? 7. Confidence and provenance How would your application distinguish between: • directly reported payer data • extracted information • inferred information • unknown information 8. HIPAA Describe your experience building systems that process PHI or other sensitive healthcare data. 9. Demonstration Please include links, screenshots, GitHub repositories, architecture diagrams or descriptions of relevant software you have previously built where possible. Generic chatbot projects are not particularly relevant. 10. Your role Are you personally writing the software, or will the work be performed by other developers at your company? We strongly prefer direct access to the senior engineer responsible for the architecture and core development. Engagement Structure We are open to either: • an experienced individual developer, or • a small senior engineering team. We expect to begin with a paid proof of concept and expand the engagement if the system performs well. This has the potential to become a significant long-term development project.