Forward-Deployed Integrations Engineer

You may also contribute to integration standards, playbooks, and tooling; help interview and onboard future hires; and join occasional customer webinars or partner sessions. Other duties as assigned.

• 5+ years in software, integration, or solutions engineering, healthcare interoperability, or another hands-on technical role where you owned integrations through production. \n

• Production engineering skills. You are highly proficient in TypeScript and comfortable reading and shipping in C# and Elixir, or confident you can get there quickly. You use SQL to inspect and validate data.

OhMD is an AI patient communication platform trusted by thousands of healthcare organizations. Our suite includes two-way patient texting, an AI voice and text assistant that handles inbound patient calls with a human always in the loop, and integrations with leading ambulatory EHRs, including athenahealth, eClinicalWorks, Veradigm, DrChrono, Elation, and Healthie. Practices using OhMD reduce inbound call volume by 50% or more. That’s the difference between a front desk that is drowning and one that can actually take care of patients.

\n

\n

Why this role exists

\n

Every healthcare organization runs on a unique technology stack. One EHR exposes a clean FHIR endpoint. Another has a vendor-specific API with its own authentication and rate limits. A third has no supported API at all. Even practices on the same EHR configure it differently and run different front-desk workflows.

\n

\n

OhMD still has to work. Our AI assistant cannot book, confirm, or reschedule an appointment it cannot see. Our integrations must be reliable enough for real patient interactions, secure enough for PHI, and clear enough that customers trust them.

\n

\n

This role owns the path between a practice’s real-world workflow and a working production integration. You’ll sit with customers, understand how their systems actually operate, choose the right approach, build it, test it, launch it, and stay with it until it works cleanly.

\n

\n

Our footprint spans more than a dozen EHRs across three codebases:

\n \n

• a .NET service for patient sync and chart write-back \n

• an Elixir platform for scheduling and reminders \n

• a TypeScript and Playwright service for systems without a usable API \n

\n

\n

You won’t need to be expert in all three on day one, but you’ll need to be comfortable reading and shipping in each.

\n

\n

This is not a role where you write a spec and hand it off. You’ll be the engineer in the customer conversation and the customer-facing owner in the code.

\n

\n

Your first 90 days

\n

Weeks 1-4: Live in the product. Learn how OhMD connects to EHRs today, shadow discovery sessions and go-lives, and understand how patient, scheduling, and workflow data move through the platform.

\n

\n

Weeks 5-8: Own your first integration with support. Scope requirements, select the technical path, build and validate it, and support the customer through testing. Ship something that runs against a real production workflow.

\n

\n

Weeks 9-12: Lead an integration workstream independently, from discovery through early production support. Bring us a point of view on three questions: what should become a reusable connector, what belongs in shared infrastructure, and where our current approach will break at scale.

\n

\n

What You’ll Own

\n

Customer integrations, start to finish. You’ll work directly with healthcare organizations, EHR vendors, and internal teams. You’ll translate operational workflows into technical requirements, define what is feasible, and surface dependencies early. You’ll own each integration through go-live and stabilization. When a customer says, “We need OhMD to know whether this patient has an appointment,” you’ll determine where that information lives, how to access it, how trustworthy it is, and what happens when it’s missing or wrong.

\n

\n

The right interface, not just the obvious one. You’ll build and troubleshoot integrations using REST APIs, webhooks, event-driven interfaces, file-based exchange, and vendor-specific methods. You’ll handle the details that matter outside a demo: OAuth 2.0, API keys, pagination, rate limits, idempotency, retries, reconciliation, version changes, and partial failures.

\n

\n

Healthcare interoperability that survives the real world. You’ll build, map, and troubleshoot integrations using FHIR R4, SMART on FHIR, and vendor APIs, with occasional older FHIR versions and CDA. You’ll investigate missing identifiers, duplicate records, patient-matching problems, delayed events, and the many ways healthcare data refuses to behave like the spec says it should.

\n

\n

Browser automation as production infrastructure. When no usable API exists, you’ll build Playwright automation that retrieves data from web-based EHRs and portals in a controlled, secure, auditable way. That means:

\n \n

• resilient selectors \n

• session and credential management \n

• deterministic navigation \n

• structured extraction and validation \n

• logging, retries, failure recovery, and alerting \n

\n

A browser workflow working once is not an integration working every day.

\n

\n

Data mapping and transformation. You’ll turn inconsistent source data into stable models the product can rely on. That data includes demographics, appointments, providers and locations, communication preferences, and refill context. You’ll define mappings, validation rules, and fallback behavior, and decide which source is authoritative when systems disagree.

\n

\n

Go-lives and production quality. You’ll own the technical workstream during implementations. That includes test plans, customer data validation, cross-system diagnosis, and go-live decisions based on evidence rather than optimism. After launch, you’ll monitor integration health and build the logging, alerts, and recovery mechanisms that keep integrations reliable.

\n

\n

Security and patient trust. You’ll apply least-privilege access, secure credential handling, encryption, audit logging, and careful data retention. You’ll partner with security and compliance, and treat reliability and security as product behavior, not paperwork added at the end.

\n

\n

Patterns that outlive you. The first time we solve an integration problem, it may be a customer project. By the fifth time, it should be a reusable capability. You’ll turn common data models, auth patterns, browser workflows, and validation rules into shared connectors and tools. You’ll also document them so others can operate them.

\n

\n

A tight loop with product and engineering. When an integration exposes a platform limitation, you’ll define the problem clearly. Then you’ll help decide whether the fix is customer-specific, a reusable component, or core product. You’ll influence the roadmap without waiting for every problem to become someone else’s ticket.

\n

\n, * API depth: REST, webhooks, JSON, XML, OAuth 2.0, API keys, pagination, rate limits, and versioned interfaces. \n

• FHIR experience. You’ve built or supported production FHIR integrations. You can read resources and bundles directly and work with EHR interface teams without an intermediary. \n

• RPA experience. You’ve built and operated browser automation with Playwright or a comparable tool and know how to make it supportable. \n

• Customer-facing ownership. You lead technical discovery, explain tradeoffs, and set expectations. You work directly with customer IT, interface analysts, operators, and vendors. \n

• EHR integration experience with one or more major ambulatory or enterprise EHRs. athenahealth, eClinicalWorks, DrChrono, Elation, and Healthie are particularly relevant. \n

• Rigor with real systems and data. You trust logs and traced requests over documentation, and you catch mismatched identifiers and duplicates. You know a successful API call isn’t the same as a correct business outcome. You handle PHI and credentials with least privilege by default. \n

• Clear communication with engineers and healthcare operators alike, including useful implementation documentation. \n

• Care about the end user. These integrations affect real patient conversations, so accuracy, reliability, and graceful failure matter to you.