Integration Engineer, Clinical Data Path

Getting a study from a hospital's systems into ours, running our model, and getting the result back is where a lot of clinical AI quietly fails. A study arrives incomplete. A sender never closes its association. A parser reads a whole request body into memory and the task disappears behind a bare 502. A firewall rule meant for one address gets applied to the wrong egress IP and produces a mid-stream 403 that looks exactly like a TLS failure. This role owns that path end to end: how studies come in, how results go back, and how we show a hospital's IT team that it all works.

We build clinical AI that reads alongside radiologists. Our abdomen-pelvis CT triage device is FDA-cleared, and it's the first commercial system to simultaneously triage seven urgent conditions on abdomen-pelvis CT in the U.S. We're backed by Khosla Ventures.

A cleared device only helps a hospital once it works inside the systems a radiologist already uses. Our clinical data path covers software running inside hospital networks, cloud DICOMweb ingest, de-identification, tenancy, result delivery, and the documentation an IT reviewer expects. It is owned by one engineer today and needs a dedicated owner, and hardening the path, including bringing the gateway repositories under proper continuous integration, is early work for whoever takes it on.

What you'd own

On-premise ingest. A pynetdicom C-STORE service that assembles studies, copes with senders that never signal completion cleanly, applies backpressure, passes compressed transfer syntaxes through untouched, and spools to disk so nothing is lost when the link drops.

Cloud ingest. A DICOMweb STOW-RS receiver with a streaming, bounded-memory multipart parser, per-part study-UID checks, and exactly one canonicalization and one inference firing per request.

Tenancy and privacy at the boundary. Working out which customer a study belongs to, with no silent default, applying the DICOM PS3.15 confidentiality rules, running a fail-closed check before anything leaves the customer's network, and keeping a re-identification store encrypted under a key the customer holds and we never see.

The outbound lanes. JSON callbacks, dictation-system autotext, and HL7 v2 ORU^R01 over MLLP, shaped to whatever interface engine the customer actually runs.

Visibility. Per-study tracing, three-component health for each integration, checks for drift between what we think is deployed and what is, and continuous integration for both gateway repositories in your first week.

The technical answers in a security review. Precise, honest answers on transport, retention, and incident handling, and a clear account of what the system does and doesn't do.

The hard problems here are rarely sloppy code; they are structural, and they are the interesting part of the job. The kind of thing you would chase: an unbounded read that balloons memory well past the request-body size and gets OOM-killed mid-request, surfacing as nothing but a bare 502 from the load balancer; or a network rule that returns a mid-stream 403 that looks for all the world like a TLS failure. These rarely show up in an application log, so they yield to packet captures, memory profiles, and reading the protocol spec rather than to another log line. If that kind of outside-in debugging sounds like a good week, you'll like this role.

Who we're looking for

Someone who has implemented a protocol straight from its specification, not just used a library that wrapped one, because DICOM and HL7 are old, strange, and written in prose you have to read carefully and get right. Someone who has run software inside infrastructure they couldn't SSH into, where the only feedback is a log file a stranger emails you. When a bare 502 shows up with nothing in the application logs, you reach for a packet capture or a memory profile before you reach for another log line. You fail closed by instinct when patient data is involved, and you can write a document a hospital IT reviewer will trust because it's precise and honest about what the system does and doesn't do.

Helpful, but not required: DICOM, PACS, VNA, or teleradiology systems from any angle; HL7 interface engines (Mirth, Rhapsody, Corepoint) or having built one; open-source medical imaging work (Orthanc, dcm4che, DCMTK, pynetdicom); a networking, embedded, or payments background where the wire format was the hard part; healthcare or another regulated environment; de-identification or privacy engineering; and confidential computing or hardware attestation, which normally sits in a separate role here and would let you cover two surfaces we currently staff with one person.

Stack: Python, FastAPI, pytest; pynetdicom and pydicom; DICOM PS3.15 and PS3.18, DICOMweb STOW-RS, HL7 v2 over MLLP; AWS (S3, SQS, Cognito, ECS/Fargate, WAF, ALB, CloudWatch, Secrets Manager) under Terraform; Docker, and shell that has to run on a locked-down hospital box.

This is a customer-facing role, so where you sit follows the customers. You'll join hospital IT and clinical security reviews, be reachable during that customer's clinical day, and travel occasionally for an on-premise install. We place the hire to match the account base: US-based for US on-premise customers, and regional for our international deployments. Your location is also a disclosed sub-processor location in our customer agreements, so it's a real constraint rather than a preference.

Compensation (US): $140,000 to $180,000 base, plus an approximately 10% discretionary bonus. Equity may be offered to top candidates.

Compensation (international, remote): for candidates outside the US, the base is cash-weighted and set by the local market for the country where the work is done, and we'll share the specific range for your location early in the process. You would work from your own country, so no visa is needed and there are no immigration strings. International offers are cash-only, with no equity.

The team: a2z was co-founded by Pranav Rajpurkar, an Associate Professor at Harvard Medical School with more than 150 publications. Our engineers trained at MIT and Stanford, and our fellowship-trained radiologists read alongside the model every day.

To apply: use the application form below. Along with your CV and GitHub, we ask one short question: tell us about the last integration bug you chased that turned out to be nothing like what the error message said.