Build1 publisher3 min readPublished
Comparing the crosshair with the sentence catches the left/right swaps in eight MRI studies
A developer ran eight signed radiology studies past Claude, Gemini, Grok and MedGemma, and the sides came back wrong often enough that he moved the laterality check out of the model and into the NIfTI affine.
The Engineer · Build desk

What happened
- A developer ran eight real MRI and CT studies through four vision models, Claude, Gemini, Grok and Google's MedGemma, scoring their output against the radiologist's signed report.
- Among the failures listed: a 5 cm cyst in the right kidney was placed in the left by two of the four readers, a medial meniscus tear was reported in the lateral meniscus, and a left paracentral disc extrusion was called right-sided.
- One reader gave two different sides for the same finding in two acquisitions of the same study.
- The pipeline now derives the side from the NIfTI affine instead of trusting the prose, returning no side at all when the point sits within 8 mm of the midline.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The check only catches disagreement between the coordinate and the sentence, so a finding whose crosshair is also on the wrong side passes clean. Coordinate accuracy becomes the thing you have to verify separately.
- cost Adopting this costs a per-language side lexicon as well as the geometry work. An English-only pattern does not fail loudly on a German or Polish report; it approves it.
- decision Teams generating radiology text have to decide whether their models emit a voxel location per finding. Without that second output there is nothing for a deterministic check to compare against.
- precedent Treating a left/right swap as a never event pushes the acceptance criterion for generated reports towards machine-checkable geometry, not reviewer judgement on the sentence.
An axial slice is displayed as if you are standing at the patient's feet looking up, so the patient's right side appears on the left of the screen [11]. A model trained mostly on ordinary photographs describes the picture in front of it [11]. That is how one MedGemma read placed its crosshair 17 to 26 mm to the right of the midline, agreed with the radiologist on position, and then wrote that the finding was "slightly to the left" [10]. Coordinate and sentence came from the same model in the same response.
Each reader is asked for two things per finding: a sentence, and a location on a specific slice [9]. That second output is what makes a model-free check possible. Volumes are converted from DICOM to NIfTI in the browser using dcm2niix compiled to WebAssembly [12]. A NIfTI file carries a 4x4 affine mapping voxel indices to millimetres in world space, and that space is RAS, where +x is the patient's right [13]. `voxToMm` multiplies each affine row by (i, j, k) and adds the translation column [22]. `sideOfPoint` reads the sign of x, and returns nothing when the absolute value falls under the 8 mm constant `OFF_MIDLINE_MM`, or when x is not finite [14].
That dead zone exists because a central disc extrusion sits at x near zero and belongs to neither side, and because floating-point noise should not be read as a side [15]. In absolute terms it is a loose gate: the MedGemma finding sat two to three times further off the midline than the cutoff [2].
Parsing the report is the other half. `sideClaimed` returns null when a bilateral word appears, and null again when both a left word and a right word are present, or neither [19]. The author's example is "The left L5 root is displaced; the right is not" [20]. Picking either word invents a claim the sentence never made [20].
Reports come back in the user's language, so an English-only regex would silently check nothing for most users [16]. Side words are matched as prefixes because the languages inflect them, as in destro and destra, rechts and rechten, prawy and prawa [16]. Two collisions are handled on purpose. The `\b` boundary keeps "bright" out of the right pattern, because b is a word character, and MRI reports say "bright" constantly [17]. A negative lookahead keeps Polish prawdopodobnie, meaning probably, out of praw [18].
The check fires only when the two answers differ. A finding whose crosshair is on the wrong side, described by a sentence that agrees with the crosshair, passes [3]. The author reports getting the scope wrong at first: a left knee MRI sits entirely at negative x, so every finding in it is on the left while the text is discussing medial and lateral structures [21]. The post's text ends mid-sentence at that point [23].
Eight studies and four readers is 32 reads [1]. Four laterality failures are named, and the post does not report how many findings each reader produced [4]. "Most repeated error" is therefore the developer's account of his own pipeline, on his own study set [2]. For the fix to transfer, two things have to hold in yours: the model must emit a voxel coordinate per finding next to its sentence [9], and the conversion must carry the DICOM geometry through into the affine [13]. With prose-only output there is nothing to compare, which leaves prompt wording, and the author wrote that "a better prompt doesn't fix it" [8].
What to watch
- Whether the author publishes the resolution for whole-limb studies, where every voxel sits on one side of the midline and the text is about medial and lateral structures.
- Whether per-reader error counts on a larger study set support laterality as the dominant failure mode, or show missed findings running higher.
- Whether the four readers change behaviour when the prompt asks explicitly for the patient's side instead of the location in the image.