Dental Practice RCM Automation Development

# Senior AI / Automation Engineer — Build End-to-End Dental Revenue Cycle Management Platform ## Project Overview We are a growing pediatric dental practice in Seattle seeking a senior software engineer, AI engineer, or small development team to build an **end-to-end dental revenue cycle management automation platform**. This is **not a dental billing, virtual assistant, or RCM operator position**. We are looking for a developer to build software that automates a substantial portion of the work currently performed manually by: * Dental front-office staff * Insurance coordinators * Billing specialists * Accounts receivable staff Our current practice-management system is **Oryx Dental**, and we use **Vyne** for portions of the insurance and claims workflow. Our long-term goal is to move from a revenue cycle where humans manually touch most claims to one where: **Software handles routine work automatically and humans manage exceptions, approvals, and unusual cases.** The platform should use APIs wherever possible, browser automation/RPA where necessary, AI for interpretation and workflow decisions, and potentially AI voice agents for insurance-company calls. --- # Major Functional Requirements The system should ultimately cover the complete insurance revenue cycle. ## 1. Patient Insurance Information Collection The platform should collect, validate, normalize, and maintain patient insurance information. Potential workflows include: * Requesting insurance information from patients before appointments * Collecting insurance card images * Extracting information from insurance cards * Identifying: * Insurance carrier * Subscriber * Member ID * Group number * Employer/group * Patient relationship to subscriber * Subscriber DOB * Effective date * Detecting missing or incomplete information * Automatically contacting patients for missing information * Validating insurance information before the appointment * Identifying terminated or inactive plans * Identifying primary vs secondary insurance * Identifying possible coordination-of-benefits issues * Maintaining an audit trail of changes The system should minimize staff involvement unless information cannot be obtained or confidently interpreted. --- # 2. Detailed Dental Insurance Benefit Verification This is a critical component. We are **not** looking for simple active/inactive eligibility verification. The platform must retrieve and normalize detailed dental benefits at the procedure level. ## General Benefits Examples include: * Active coverage * Effective date * Termination date * Individual deductible * Family deductible * Remaining deductible * Individual annual maximum * Family maximum if applicable * Annual maximum remaining * Preventive coverage percentage * Basic coverage percentage * Major coverage percentage * Orthodontic coverage * Orthodontic lifetime maximum * Remaining orthodontic maximum * Waiting periods * Network status * Plan type * COB information * Age limitations * Frequency limitations ## Procedure-Level Pediatric Dental Benefits We need detailed benefits for common pediatric procedures, including but not limited to: * D0120 periodic exam * D0140 limited exam * D0150 comprehensive exam * D0210 full-mouth X-rays * D0220 / D0230 periapical X-rays * Bitewings * D1110 / D1120 prophylaxis * Fluoride * D1351 sealants * Space maintainers * Restorations * Stainless-steel crowns * Pulpotomies * Extractions * Other pediatric dental procedures * Orthodontic services For each procedure, where available, the system should determine: * Whether the procedure is covered * Coverage percentage * Applicable deductible * Age limitation * Frequency limitation * Tooth limitation * Replacement limitation * Prior history * Last date of service * Remaining frequency availability * Downgrades * Alternate-benefit provisions * Plan exclusions * Calendar-year vs rolling-month limitations ### Example: Sealants For **D1351**, the application should ideally determine: * Is the patient eligible for sealants? * What percentage does insurance pay? * What ages are covered? * Which teeth are eligible? * What is the frequency limitation? * Are replacement sealants covered? * Has the patient previously received sealants? * On which teeth? * On what dates? * Are those teeth currently eligible again? This level of detailed benefit determination is one of the central requirements of the project. --- # 3. Multi-Source Insurance Data Retrieval We expect the developer to build a layered retrieval strategy. Preferred hierarchy: 1. Direct payer APIs 2. Clearinghouse APIs 3. Vyne integrations 4. Other insurance eligibility APIs 5. Payer websites 6. Browser automation / RPA 7. Benefit PDFs and documents 8. Automated phone calls 9. Human exception handling The system should not simply ask an LLM to guess insurance coverage. Each data element should maintain provenance such as: * Source * Retrieval time * Raw value * Normalized value * Confidence level * Verification method --- # 4. Claim Creation and Claim Scrubbing The system should eventually help prepare insurance claims based on completed clinical procedures. Functions may include: * Identify completed procedures that have not been billed * Identify missing claims * Create draft claims * Verify CDT codes * Validate insurance information * Validate provider information * Identify missing tooth numbers/surfaces * Validate dates of service * Identify missing narratives * Identify missing documentation * Identify required radiographs * Identify required intraoral photographs * Detect likely payer-specific claim issues * Detect duplicate claims * Detect possible timely-filing issues Claims should be automatically prepared whenever confidence is sufficiently high. --- # 5. Claim Attachments and Documentation The system should determine what supporting documentation is required for individual claims. Potential functionality: * Identify payer attachment requirements * Retrieve appropriate radiographs * Retrieve clinical notes * Retrieve intraoral images * Generate appropriate narratives from clinical documentation * Associate documents with the correct procedure/tooth * Submit attachments through Vyne or another appropriate channel * Verify successful submission Humans should be able to review uncertain cases. --- # 6. Claim Submission Once a claim passes validation, the system should: * Submit the claim electronically * Record submission time * Record clearinghouse acknowledgement * Detect immediate rejections * Categorize rejection reasons * Automatically correct straightforward errors * Resubmit appropriate claims * Escalate uncertain cases The system should maintain a complete claim history. --- # 7. Outstanding Insurance / Accounts Receivable Management The system should continuously monitor unpaid insurance claims. For every outstanding claim it should determine: * Claim age * Current claim status * Expected payment date * Whether additional information is required * Whether the claim has been denied * Whether the payer has received the claim * Whether the claim needs resubmission * Whether an appeal is appropriate * Whether timely-filing limits are approaching The platform should prioritize claims based on: * Dollar amount * Claim age * Timely-filing deadline * Probability of successful collection * Required next action --- # 8. Automated Payer-Portal Follow-Up When appropriate, the system should log into insurance-company portals and: * Search claims * Retrieve claim status * Retrieve payment information * Retrieve denial reasons * Download EOBs * Download benefit information * Review claim history * Obtain prior procedure history * Retrieve required documents * Record reference numbers Browser automation must be robust enough to handle payer-specific workflows. Potential technologies include: * Playwright * Selenium * Browser automation frameworks * RPA platforms The developer should anticipate: * MFA * Session expiration * Changed page layouts * CAPTCHA/escalation scenarios * Retry logic * Audit logging * Credential management --- # 9. Automated Insurance Company Phone Calls An important future component is an AI voice agent capable of calling insurance companies when information cannot be retrieved electronically. Potential workflows include: ### Benefit verification The agent may ask: * Is the patient active? * What are the preventive/basic/major benefits? * Is D1351 covered? * What is the age limitation? * Which teeth are eligible? * What is the frequency limitation? * What was the last date sealants were performed? ### Claim follow-up The agent may ask: * Has claim X been received? * What is its current status? * Why was it denied? * What information is missing? * When should payment be expected? * What is the payer reference number? ### Denial resolution The agent may determine: * Why the claim was denied * Whether it can be corrected * Whether an appeal is required * What documentation is necessary Call functionality should include: * Structured call scripts * AI voice interaction * Call recording where legally appropriate * Call transcription * Extraction of structured answers * Confirmation/reference numbers * Confidence scoring * Human escalation when necessary We are interested in platforms such as Twilio, Bland, Retell, ElevenLabs or other appropriate healthcare-compatible voice infrastructure, but are open to the developer's recommendations. --- # 10. Denial and Exception Management The software should classify exceptions rather than simply presenting staff with a large AR report. Examples: ### Automatically resolvable * Missing attachment * Incorrect subscriber information * Claim not received * Simple eligibility issue * Duplicate submission error * Missing provider identifier * Correctable coding/data issue ### Requires human review * Ambiguous coverage determination * Complex COB issue * Medical necessity issue * Significant financial adjustment * Unusual denial * Patient dispute * Payer inconsistency The system should create an **exception queue** showing: * Patient * Claim * Amount * Problem * Recommended action * Supporting evidence * Confidence * Deadline * Human decision required Ideally, staff should manage exceptions rather than manually investigate every account. --- # 11. EOB / ERA Retrieval and Posting The system should retrieve and process electronic and paper EOB/ERA information. Functions may include: * Retrieve ERA files * Retrieve EOBs * Match payments to patients * Match payments to claims * Match payments to procedures * Identify contractual adjustments * Identify deductible amounts * Identify coinsurance * Identify patient responsibility * Identify denied procedures * Identify downgraded procedures * Identify partial payments * Detect unexpected payment amounts The system should reconcile: **Claim submitted → payer adjudication → EOB/ERA → payment received → amount posted** --- # 12. Insurance Payment Posting Insurance payments should be automatically posted where the match and adjudication are clear. The system should: * Match ACH/check payments to ERA/EOB records * Match claims and patients * Allocate payments by procedure * Post insurance payments * Post contractual adjustments * Calculate patient responsibility * Detect discrepancies * Prevent duplicate posting Low-confidence cases should be routed to the exception queue. We want strong auditability around financial postings. --- # 13. Payment Reconciliation The system should reconcile: ### Payer ERA/EOB against ### Cash ACH/check/deposit against ### Practice Management System Amount posted to patient accounts. The application should identify: * Missing payments * Unposted payments * Duplicate payments * Underpayments * Overpayments * Incorrect adjustments * Deposit discrepancies * Patient-account discrepancies --- # 14. Patient Billing After insurance adjudication is complete, the system should calculate the patient's final responsibility. However, **patient billing should initially require human approval.** Workflow: Insurance adjudicated → EOB processed → insurance payment posted → contractual adjustments applied → patient responsibility calculated → account reviewed for anomalies → system recommends patient bill → **human approves** → bill is issued Patient billing may eventually include: * SMS * Email * Payment links * Statements * Payment reminders * Automated follow-up We do not initially want the AI autonomously sending questionable patient balances. --- # 15. Human Approval and Controls Some actions should be fully automated. Others should require approval. Examples of actions likely requiring human approval initially: * Large account adjustments * Write-offs * Refunds * Unusual appeals * Changing patient responsibility * Sending disputed patient bills * Complex COB decisions The system should have configurable approval thresholds. Example: "Insurance paid $312. The EOB indicates a $74 contractual adjustment and $86 patient responsibility. Confidence 99%. Approve patient balance?" A human should be able to approve or reject directly from the dashboard. --- # 16. RCM Command Center Ultimately we envision a dashboard showing the health of the entire revenue cycle. Examples: ### Today 186 appointments reviewed 174 insurance plans verified 12 verification exceptions ### Claims 81 claims generated 76 automatically submitted 5 require review ### Outstanding Insurance $143,000 outstanding $82,000 processing normally $34,000 requiring automated follow-up $18,000 requiring staff review $9,000 approaching timely-filing deadlines ### Payments $42,000 insurance payments received $39,800 automatically reconciled $2,200 requiring review ### Patient Billing 34 accounts ready to bill 29 recommended for automatic approval 5 require investigation Our objective is to give management a real-time understanding of: **Where every dollar is in the revenue cycle and what needs to happen next.** --- # 17. Architecture We are open to architectural recommendations. Likely components include: ### Integration Layer Oryx Dental Vyne Insurance APIs Clearinghouses Payer portals Bank/payment systems ### Data Layer Normalized patient, insurance, claim, EOB, payment and workflow database. Potentially PostgreSQL or equivalent. ### Workflow / Orchestration Layer Potential technologies: * Python * FastAPI * Node.js / TypeScript * Temporal * LangGraph * OpenClaw * other agent/workflow orchestration systems ### Browser Automation Potentially: * Playwright * Selenium * RPA ### AI Layer Potentially: * OpenAI * Anthropic * Grok * other models Different models may be appropriate for different tasks. ### Voice Layer Potentially: * Twilio * Retell * Bland * ElevenLabs * other voice-agent infrastructure We care more about the architecture being reliable and maintainable than about using any particular fashionable AI framework. --- # 18. HIPAA and Security This is healthcare software and may process PHI. Production architecture must therefore be built with appropriate healthcare security controls. Candidates should understand: * HIPAA * Business Associate Agreements * Encryption at rest * Encryption in transit * Role-based access * Least-privilege permissions * Secure credential vaults * MFA * Audit logging * PHI-safe application logging * Data-retention policies * Production/development separation * Backup and recovery * Vendor security * Secrets management Do not apply if your proposed architecture involves placing PHI into unmanaged consumer AI tools or insecure browser-automation environments. --- # 19. Reliability Is Critical This system will eventually touch real financial and patient data. Therefore, we care about: * Deterministic workflows where possible * Idempotency * Retry logic * Transaction logging * Error handling * Confidence scoring * Human escalation * Source provenance * Automated testing * Monitoring * Alerting * Version control * Documentation We are not looking for a demo that works 80% of the time. The long-term objective is production-grade infrastructure. --- # 20. Ideal Candidate We are looking for someone with a strong combination of: * Senior software engineering * API integrations * Browser automation/RPA * AI-agent development * Workflow orchestration * Databases * Healthcare systems * Financial reconciliation * Security Experience with healthcare insurance or dental systems would be particularly valuable. Experience with any of the following is a major plus: * Oryx Dental * Vyne * DentalXChange * Availity * Dentrix * Open Dental * Eaglesoft * Delta Dental * Premera * Regence * Guardian * MetLife * Cigna * Aetna * UnitedHealthcare --- # Development Approach We do **not** expect the entire platform to be built at once. We expect the project to be built in phases. ## Phase 1 — Insurance Verification Build detailed automated insurance verification for several major payers. Initial emphasis: * Delta Dental * Premera * Regence Demonstrate procedure-level benefit determination including D1351 sealants. ## Phase 2 — Claims and Attachments * Claim generation * Claim scrubbing * Documentation * Attachments * Submission ## Phase 3 — Claim Follow-Up and AR * Claim-status monitoring * Portal automation * Denial resolution * Exception queues ## Phase 4 — Payments * ERA/EOB processing * Payment matching * Insurance payment posting * Reconciliation ## Phase 5 — AI Voice * Insurance verification calls * Claim-status calls * Denial follow-up calls ## Phase 6 — Patient Billing * Patient responsibility determination * Human approval * Billing * Payment follow-up The architecture developed in Phase 1 should anticipate these later modules. --- # First Paid Proof of Concept We would like the engagement to begin with a paid proof of concept. The POC should take a defined set of patients and automatically obtain detailed insurance benefits from several insurance carriers. For **D1351 sealants**, for example, the system should attempt to determine: * Coverage * Percentage * Age restriction * Tooth restriction * Frequency * Previous sealant history * Last date of service * Current eligibility It should return a standardized structured record showing: * Answer * Data source * Evidence * Confidence * Missing information * Recommended next step If data cannot be obtained through an API, the software should demonstrate the ability to proceed to a payer portal or appropriate fallback workflow. --- # Please Answer These Questions When Applying ## 1. Most Relevant Build Describe the most technically similar **production software system you personally built**. Do not simply describe a healthcare company you worked for. Explain your contribution. ## 2. Architecture At a high level, how would you architect the platform described above? ## 3. Insurance Verification How would you obtain detailed dental benefits when a standard eligibility API provides only partial information? ## 4. Sealant Test Suppose we need to determine eligibility for **D1351 sealants**. The API provides: Covered at 80% But does not provide: * Age limitation * Tooth limitation * Frequency * Prior history How would your system obtain the missing information? ## 5. Payer Portals What experience do you have automating insurance or healthcare portals? Which browser automation technologies have you used? ## 6. Portal Reliability How do you design browser automations that remain reliable when: * Sessions expire * Page layouts change * MFA appears * An element fails to load * Portal data conflicts with API data? ## 7. AI Voice Have you built an AI voice agent that conducts structured outbound calls? If so, describe the architecture. ## 8. Financial Posting Have you built systems that reconcile financial transactions or automatically post payments? Explain how you prevented: * Duplicate posting * Incorrect matches * Incorrect adjustments ## 9. Exception Handling How would you determine when the software should: **act automatically** versus **request human approval?** ## 10. HIPAA Describe your experience building applications involving PHI or similarly sensitive information. ## 11. Technical Stack What stack would you recommend for this project, and why? ## 12. Team Will **you personally write the core software**, or will the work be delegated? If you are an agency, identify the engineer who would be responsible for architecture and core development. ## 13. Demonstration Please include links to relevant: * GitHub repositories * Applications * Architecture diagrams * Videos * Screenshots * Technical case studies Generic chatbot examples are not particularly relevant. --- # Who Should NOT Apply Please do not apply if your primary experience is: * Dental billing * Virtual assistance * Manual insurance verification * Generic chatbot implementation * Prompt engineering without substantial software engineering * No-code automation without production software experience We need a **software developer/architect**, not someone to manually perform the revenue-cycle work. --- # Engagement Opportunity We expect to begin with a paid proof of concept. If successful, this could become a substantial long-term development engagement. Our goal is ambitious: **Build a software platform capable of automating the majority of a dental practice's insurance revenue cycle—from collecting insurance information before the visit through benefit verification, claim submission, payer follow-up, adjudication, insurance payment posting, reconciliation, and ultimately approved patient billing—with humans primarily managing exceptions.** We are looking for an engineer who wants to build that system.