Testing a FHIR ML Platform Engineer's Real Depth Means Testing the Seam

Your Denial Model Is Ready and the FHIR Feed Is Not

The model works. It flags likely denials four days before submission, and the pilot beat the billing team. Then it goes to production and the Bundle arrives with a Coverage reference pointing at a payer resource that does not exist outside the sandbox, and nobody on the team can say whether that is the EHR's fault, the payer's, or a mapping somebody wrote in 2023. That gap is the job.

A FHIR ML platform engineer owns the seam. Not the model, and not the interface engine, but the thin, unforgiving layer where a resource shaped by a standards committee becomes a feature with known provenance, and then becomes something written back to a chart a clinician will read.

The traits that matter are unglamorous. This person reads a server's CapabilityStatement before asking for credentials, because it says what the server actually supports rather than what the vendor's documentation claims. This person treats a terminology mapping as code with tests, not as a spreadsheet somebody maintains. This person can tell you which of an EHR's three ways of exposing the same observation is the one that survives an upgrade, and why the other two look identical until it does not.

The tells that separate the real from the performed are easy to hear once you listen for them. Someone who has done the work reaches for a specific painful example inside a minute: a bulk export timing out at the group level, a payer API returning a 200 with an empty OperationOutcome, a lab result whose units changed silently at the source. Someone who has only read about it stays at the level of resource names and the word interoperability. Ask what broke last quarter. Real depth answers with a date, a resource type, and the name of the person they had to call.

Start With the Interface Engineer Who Taught Themselves Python

Almost nobody trains for this. The reliable producers are interface engineers who taught themselves Python well past HL7 v2, and data engineers at payers or digital health companies who got handed a model to serve and learned the standard on the way. Both arrive with the scar tissue that matters, which is having been badly wrong in production about what a field meant.

Three less obvious routes produce better hires than the two above, and a keyword search will never surface them. A revenue-cycle analyst who automated their own denial worklist has already lived inside the exact data the denial model needs, already knows which fields the payer disputes, and would read that missing Coverage reference as a payer-side artifact rather than a bug in the pipeline. A clinical informatics pharmacist who built order-set logic knows terminology at a depth most engineers never reach. A former EHR implementation analyst knows where the bodies are: which build decision at go-live in 2019 is the reason a field is empty for one department and populated for every other.

What none of those backgrounds guarantee is the model half, so probe it directly rather than assuming. Ask how they would tell whether a drop in model performance came from the model, from a schema change upstream, or from a clinic that changed its documentation habits. The answer separates people who have run a clinical model in production from people who have trained one.

One caution on titles. The postings for this work appear under several names, and a candidate who has done exactly the job may have never held the label. Search on the artifacts instead: bulk export pipelines, SMART on FHIR apps, terminology services, feature stores over clinical data. In a health system this role reports somewhere near, and sometimes into, whoever holds the chief health AI officer mandate, which is worth settling before the offer rather than after.

Ask How the FHIR ML Platform Engineer Checks What the Model Told Them

The best people in this role got fast by using AI heavily and then getting burned by it in a domain where being confidently wrong is expensive. Ask about that directly. A model will happily produce a plausible FHIR search parameter that no server implements, an extension URL from a profile that was never published, or a mapping between two code systems that reads correctly and is clinically wrong.

The practice behind the skill is a habit of checking against something outside the conversation. Strong candidates describe a loop: draft the query with an assistant, then run it against the actual server's CapabilityStatement, then validate the resource against the published profile, then check the terminology against the source of truth rather than against the model's memory of it. They will usually have a story about the time they skipped a step.

Listen for where they refuse to delegate. Generating boilerplate for a resource transform is a fine use of an assistant. Deciding that two code systems mean the same clinical thing is not, and a candidate who cannot articulate that boundary will eventually ship a mapping nobody reviewed. This is the same judgment a healthcare AI governance and risk officer will later ask them to document, so hiring for it is cheaper than auditing for it.

The practical version of this screen is not a quiz. Give them an assistant, a messy real export, and forty minutes, and read what they actually did: which claim they checked, which they took on faith, and what they wrote down for the next person.

Where a FHIR ML Platform Engineer Already Works, and What Closes One

They are findable, but not on job boards. The HL7 connectathons and FHIR DevDays draw the people who implement the standard rather than talk about it, and the public FHIR community chat is full of engineers debugging real servers in public, with their reasoning attached. Reading six months of someone's answers there tells you more than any resume screen.

One staffing firm's 2026 healthcare AI hiring report names Epic, Oracle Health, Optum, Innovaccer, Particle Health and payer organizations as the employers competing for this title ¹. That is a recruiter's view of a market rather than a census, so treat it as a starting list to check against those companies' own postings. Adjacent roles worth sourcing from: integration engineers inside a health system's IT group, platform engineers at digital health vendors who ship SMART on FHIR apps, and data engineers at Medicaid managed care plans, who have been living inside the prior authorization rules since they took full operational effect on January 1, 2026 ².

What closes them is rarely money alone. This is a population that has spent years asking for data access and getting a committee. The offer that lands names the first dataset, names the clinical owner they will work with, and gives a date for credentials. The offer that dies makes them the compliance function as well as the engineering function, or buries them under a ticket queue where every clinical model waits behind a printer integration.

Two more things they ask about, in almost every conversation. Whether there is a second person who understands the seam, because being the only one is how this role burns out. And whether the model they are asked to serve has a named owner who will decide what happens when it is wrong.

What Does a FHIR ML Platform Engineer Cost, and Do They Sit Onsite?

One staffing firm's healthcare AI hiring report, dated August 2026, puts this title at $190,000 to $295,000 base in major US metros for full-time direct hire, and $235,000 to $390,000 in total compensation with bonus and equity ¹. That is a recruiter's book of business rather than a market consensus, and no second series turned up to check it against. Read it as one dated reading with a small pool behind it.

If you would rather not post against one recruiter's numbers, the proxy is close to hand. The seat hires against your senior or staff platform engineer band, because the work is platform work with a domain tax on top: production ownership, on-call, and a standard nobody else on the team can read. Set the midpoint where your staff platform engineers sit, then add for the FHIR half, which is the part you cannot hire around. The published band is worth interrogating for the same reason. Because the title is new, some postings at the lower end are interface-engineer roles with a model attached, and some at the top are staff-level platform roles that happen to touch FHIR. Anchor on the work described above rather than on the label, and expect the payer side to pay differently from provider systems, which run on thinner margins.

On location, the work itself is remote-capable and the constraints usually are not. FHIR APIs, sandboxes and CI all work fine over a VPN, and much of the community that produces these engineers has been distributed for years. What pulls them onsite is specific: an interface engine that lives inside the hospital network, a security posture that will not extend production access off-premise, and the fact that the first six months of the job are mostly conversations with clinicians and revenue-cycle staff who are physically in the building.

A workable pattern many systems land on is onsite for the first stretch, then two or three days a week, then largely remote once the person has the relationships to debug by phone. Say which one you are offering in the posting. Candidates in this band have options, and an unstated hybrid expectation discovered in week three is a resignation in month four.

See what gets scored >