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. Two of the repositories on this path have no continuous integration yet, and the whole surface is currently held by one engineer who is also carrying our confidential-computing work. That's the gap we're hiring to close.

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 failures on this path tend to be structural rather than sloppy, and they're genuinely interesting. Two recent ones give the flavor. One task peaked at roughly nine times the size of the request body and got OOM-killed mid-request, which reached us as a bare 502 from the load balancer with nothing else to go on. Another was a firewall rule scoped to a single address that had been applied to the wrong egress IP, producing a mid-stream 403 that looked for all the world like a TLS problem. Both cost us days, and neither was visible in the application logs. If that kind of 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. International offers are cash-only, with no equity, and we neither require nor sponsor a visa.

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.