Integration Engineer, Clinical Data Path

About the role

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.