DICOM, HL7 FHIR, PACS and EHR interop. Segmentation, registration and reconstruction. Biosignals. All in Rust, with the regulatory data plane wired into the source, not bolted on at the end.
A DICOM parser is a solved problem. What is not solved is arriving at a design review with a dependency tree that a notified body will accept without a stack of justification documents.
| Library | Language | Licence | Shippable in a device | 62304 evidence |
|---|---|---|---|---|
| dcm4che | Java | AGPL / commercial | Runtime + licence problem | You produce it |
| DCMTK | C++ | BSD-style | Yes | You produce it |
| GDCM · ITK | C++ | Apache / BSD | Yes | You produce it |
| Commercial toolkits | C / C++ | Per-seat, per-device | Yes | Partial, at a price |
| OxiMed | Rust | Apache-2.0 libraries | Yes | Shipped with the release |
Every option above except the last one leaves you holding the same job: classify the software, inventory the SOUP, justify each item, trace requirements to tests, and defend memory safety in code that was written in a language which does not have any. That work is where the schedule goes.
Rust does not make your device safe. It removes an entire category of hazard from the analysis, and it lets the evidence be produced by the build system instead of by a technical writer reading a diff.
Modular. Take the DICOM layer alone for an interop project, or the imaging pipeline for a diagnostic product.
The libraries are Apache-2.0 and always will be. What is commercial is the dossier that goes into your technical file, regenerated for every version you ship.
We supply evidence for our software as a SOUP item in your device. We are not your notified body, your consultant or your quality system, and the classification of your device remains yours to determine.
Nothing is gated during development. You only need a commercial agreement when the software goes into a regulated submission.
The full workspace. Build, ship, modify, fork. No field-of-use restriction, no contact required, no expiry.
The full dossier above, regenerated per release. SBOM and VEX service. 5 business day response on defects affecting your classification.
Everything above, plus a named engineer, participation in your design reviews, and a commitment to support your shipped version for the device lifetime.
Nine years removing C. The medical stack is what got built on top.
Registration is optimisation. Reconstruction is transforms. Segmentation is tensors. Every medical imaging toolkit in existence sits on ITK, on VTK, on BLAS, on FFTW — and all of it is C, C++ or Fortran, which is why every SOUP inventory in the industry is long and every justification is hard.
The imaging layer could not be clean until the numerics were replaced. So we started at the bottom and worked up, and OxiMed is what became possible once the floor was Rust.
A Rust wrapper over ITK still puts ITK in your inventory. Ours does not, because the layer beneath it was rewritten first, and the layer beneath that one before it.
The stack is public on GitHub — 60+ projects, Apache-2.0. The evidence is the part we sell.
Genuinely — send the current list, or just the device class and what it does. You will get back a mapping of which items OxiMed replaces, what stays, and an honest estimate of what that removes from your documentation load. One business day, no call required.