// the find
Krasnov777/DICOMFlow
Native macOS DICOM toolbench & viewer — SwiftUI + Metal + in-process DCMTK. DIMSE/DICOMweb/FHIR/HL7 tester, GPU volume rendering, MCP server for AI agents.
DICOMFlow is a macOS developer toolbench for PACS integration work — C-ECHO, C-STORE, C-FIND/MOVE, DICOMweb, FHIR, HL7 over MLLP, a built-in test SCP, and a pcap dissector for DICOM traffic, all in one native app. It also has a real GPU volume renderer (MIP, MinIP, DRR, iso-surface) via Metal. The audience is engineers writing PACS connectors or debugging medical imaging pipelines, not clinicians.
DCMTK statically linked in-process via an Obj-C++ bridge is the right call — no subprocess management, no PATH games, no version mismatch between what you installed and what the app uses. The pcap import that decodes DICOM PDUs is genuinely useful for debugging TLS-wrapped traffic you can't inspect live. The MCP server that exposes the same native engine to AI agents is an interesting architectural choice — one DCMTK build, two consumers. Test suite is offline-by-default with an opt-in Orthanc round-trip path, which is the correct way to handle live-PACS tests in CI.
Requires macOS 26 and Xcode 26, both of which are not yet released as of mid-2026 — this is not a tool you can hand to a colleague today. The repo lists 2 stars and 0 forks and was pushed yesterday, so there is no track record of the app working against real PACS systems in the wild; the claims about conformance and IOD validation are untested by anyone but the author. The README says 'no Python, no subprocesses' but there is a Python sidecar (`sidecar/dicom_sidecar/`) compiled into a binary — that is a subprocess, and it contradicts the headline. The MCP server is explicitly un-sandboxed, which is a real concern if you're feeding it paths or AE titles from untrusted input.