Skip to content
BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
.gitignore
.gitignore
 
 
CONTRIBUTING.md
CONTRIBUTING.md
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 

Repository files navigation

Awesome HL7 and DICOM Awesome

A curated list of HL7 and DICOM resources, tools, and hard-won field notes.

Healthcare interop is a field where the good tools are hard to find, the bad ones look identical to the good ones, and half the top search results have been abandoned since 2022. This list tries to be the thing you'd want a senior integration engineer to hand you on day one.

The curation bar: every entry is something a working integration engineer would be glad someone showed them. Maintenance status is stated honestly — (unmaintained) and (commercial) are labels, not insults, and a dormant-but-canonical tool still earns its place. Things that are dead and superseded live in Dead ends, because knowing what not to adopt saves more time than one more link.

Last verified: July 2026.

Contents

HL7

Notes and Tips

Unofficial field notes. These are the things that cost somebody a weekend.

  • Read the spec. Actually read it. You will learn more in one afternoon with the v2 standard than in a month of guessing. It's been free since 2020 — there's no excuse left.
  • Expect that the people you're integrating with have not read the spec. Your parser has to survive their interpretation of it. Be liberal in what you accept.
  • Follow the standard even when you can get away with not following it. You can stuff a 20-character Accession Number into a field — and it will work right up until it reaches a DICOM system, where AccessionNumber is a hard 16-character limit. The break happens three systems away from the mistake, months later.
  • "HL7 v2 is pipe-delimited" is a trap. The delimiters are declared in MSH-1/MSH-2 and you are supposed to read them, not assume them. Also: escape sequences (\F\, \S\, \T\, \E\, \R\) mean a field's raw text is not its value.
  • Z-segments are where the money is and the spec isn't. Every real interface has them. Document yours, because nobody else will document theirs.
  • MSH-9 tells you the message type; the trigger event tells you what actually happened. An ADT^A08 that arrives before the A01 is not a bug in your code — it's Tuesday. Design for out-of-order and duplicate messages from day one.
  • ACKs are a protocol, not a formality. Decide early whether you're doing original or enhanced mode acknowledgment, and what an AE vs AR actually means to your retry logic.
  • MLLP is a two-byte wrapper around a TCP stream and nothing more. No framing guarantees, no built-in TLS, no auth. Treat the transport as hostile.

The Standard

  • HL7 Standards Index - The front door to everything.
  • HL7 v2 Product Brief - The workhorse. ~95% of real-world clinical messaging is still v2, and it's free to download.
  • HL7 v3 Product Brief - The ambitious RIM-based rewrite that largely failed to displace v2. Worth knowing about mostly so you understand why CDA (its surviving child) looks the way it does.
  • HL7 Confluence - Working-group specs, ballot material, and the v2-to-FHIR mapping tables. Less polished, more current.

Integration Engines

In March 2025 NextGen took Mirth Connect closed-source as of version 4.6. 4.5.2 was the last open release. The community forked it twice, and both forks are alive and actively developed — this is the single most important fact in HL7 tooling right now.

  • Open Integration Engine (OIE) - The community-governed fork of Mirth 4.5.2, with a steering committee and an application to join the Eclipse Foundation. 4.6.0 GA shipped July 2026 (Java 17, 24 CVEs remediated). Site · Docs · Discord (the primary community channel).
  • BridgeLink - The other Mirth 4.5.2 fork, from Innovar Healthcare. Both forks are legitimate, both are actively developed, and there is little practical difference between them today — they share the same 4.5.2 ancestry and the same channel format. The distinction is governance (OIE has a steering committee and an Eclipse Foundation application; BridgeLink has single-vendor stewardship), which may matter more over time than it does right now.
  • Iguana - iNTERFACEWARE's engine, the main commercial non-Mirth comparator. (commercial)
  • NextGen Connect - The original. Frozen at 4.5.2 since September 2024 and now closed-source going forward. Do not start new work here — use one of the forks. Kept in the list for archaeology and because a decade of Stack Overflow answers point at it.
  • OIE Vendors - Who sells commercial support for OIE, if you need a throat to choke.

Engine Plugins and Tooling

  • Mirth-Snippets - Assorted OIE/Mirth scripts, templates, and how-tos. One of the most useful community repos.
  • Unofficial OIE Wiki - Community-maintained user manual, filling the gap the official docs haven't yet.
  • ballista - Admin-client launcher for Mirth/OIE/BridgeLink. Solves the Java Web Start pain that everyone hits on day one.
  • TLS Manager Plugin - Free TLS for HTTP/WS/TCP connectors, sponsored by NovaMap + Diridium and donated to OIE. The open replacement for NextGen's paid SSL Manager. Docs
  • Channel History Git Plugin - Git-backed version control for channels. Because "who changed this transformer" should have an answer.
  • ChristopherSchultz/mirth-plugins - A solid grab-bag of community plugins.
  • mirth-plugin-guide - The de-facto guide to writing a Mirth/OIE plugin, plus a sample plugin. Dormant since 2024 but still the best reference that exists. Its companion Maven plugin is archived — read it for the build wiring, don't depend on it.
  • Mike's Mirth Code - Battle-tested JavaScript code templates, helpers, and channels pulled from production HL7 integrations. (author of this list)
  • oie-tcp-multi-sender - Destination connector that sends MLLP to a list of endpoints with failover/failback and a per-endpoint circuit breaker, instead of the stock TCP Sender's single address. (author of this list)
  • jonbartels' SSL/TLS primer - The canonical explainer for Mirth keystore handling. Read before you fight the keystore.
  • HL7 Spec Extractor - Extracts HL7 spec tables, for when you're generating code or validators from the standard. Small and lightly maintained — included because HL7 v2 has no equivalent of innolitics/dicom-standard, and this is the closest thing to a machine-readable spec that exists outside HAPI's internals.

Libraries

  • Java — HAPI HL7v2 - The reference implementation, and what Mirth/OIE uses internally. If you're on the JVM, this is the answer. Docs
  • .NET — nHapi - The .NET port of HAPI. Actively maintained; the clear pick.
  • Python — python-hl7 - Simple parsing plus an MLLP client. Start here.
  • Python — hl7apy - Structure-aware: validates against the actual v2.x grammars (2.1–2.8.2). Heavier than python-hl7, and worth it when you need real validation. Quiet since early 2025, but the grammars it ships are the reason to use it and those don't rot. (dormant)
  • Node/TypeScript — node-hl7 - Client, server, and parser in TypeScript. The actively maintained JS option — note the standalone node-hl7-client repo is archived; development continues in this monorepo.
  • Node/JavaScript — simple-hl7 - Express-style HL7 middleware plus MLLP. Small, stable, and still widely deployed, but untouched since early 2025 — prefer node-hl7 for new work. (dormant)
  • TypeScript types — mirth-connect-types - Type definitions for the Mirth/OIE server-side JavaScript (Rhino) User API — the globals and Java classes available inside channel scripts. (author of this list)

Tools and Validators

  • NIST HL7 v2 Tools - The only free, authoritative v2 conformance validator. The General Validation Tool checks a message against a real conformance profile, not just "does it parse"; the domain suites (immunization, syndromic surveillance, lab) are what US certification actually tests against. The UI is government-grade, and it's still the thing to reach for when "is this message correct" needs an answer you can cite. Also embeddable as a Java library. Hosted — synthetic data only.
  • HL7 Soup - Windows HL7 editor, viewer, and integration host. Free viewer tier. (partly commercial)
  • 7Edit - Long-standing HL7 v2 editor/sender/receiver. (commercial)
  • Caristix View/Search/Edit - HL7 workbench with conformance profiling. (commercial)
  • HL7 Inspector Neo - Free browser-based HL7 analyzer and editor.
  • HL7 Viewer - Free client-side parser. Nothing is uploaded.
  • HL7Toolbox - Open-source (MIT), fully client-side HL7 v2 web tools: parser, viewer, validator, and message compare, plus a rule-based field de-identifier for scrubbing test messages. No uploads, and the tool pages load no analytics. (source)

Do not paste production HL7 into a web tool you don't control. Not the viewers above, not any of them. "100% client-side, nothing leaves your browser" is a claim, and it is routinely made by pages that also load third-party analytics and session-replay scripts (Microsoft Clarity, FullStory, Hotjar) — which exist precisely to record DOM content and ship it somewhere else. Unless the masking configuration is documented and the source is published, "client-side" and "nothing is captured" are not the same sentence.

This bites hardest on the tools that sound safest: an online PHI de-identifier is a contradiction in terms, because to de-identify your data it must first receive your data, while it is still identified. Use a local tool — a library, a CLI, or something running on your own machine. If you must use a hosted tool, feed it synthetic data and nothing else. A HIPAA breach is not worth the ninety seconds you saved.

Test Data

  • Synthea - Synthetic patient generator producing full longitudinal records as HL7 v2, FHIR, and CCDA. The answer to "where do I get realistic test data that isn't PHI." Site
  • NIST Immunization Test Suite - Test messages bound to machine-readable conformance profiles and used for ONC certification. Narrow — immunization VXU/QBP/RSP only — but the rare case where the sample message and the spec it conforms to are the same artifact rather than two documents that drifted apart.
  • VA VistA Imaging HL7 specifications - The PACS-facing interface specs, plus a list of approved PACS interfaces refreshed April 2026. Unusual in being a large real-world HL7 interface whose specification is public and maintained. More in the VA Documentation Library.

A sample message is a hypothesis, not a specification. Vendor-supplied examples routinely disagree with the vendor's own conformance spec, and even a public, well-maintained spec describes a baseline that local customization departs from — VistA is the standard illustration, where the published interface is real and every site's feed still differs from it. Build against what you actually receive on the wire, and treat any example message as something to verify.

FHIR

FHIR is not a replacement for v2 so much as the thing v2 shops eventually have to interoperate with. A few canonical starting points, deliberately not a full FHIR list:

Learning

DICOM

DICOM Notes and Tips

DICOM punishes assumptions. These are the assumptions it punishes most often.

  • Transfer syntax is negotiated per presentation context, not per association. The SCU proposes an abstract syntax with N transfer syntaxes; the SCP accepts exactly one per context. Always propose Implicit VR Little Endian as a fallback, or watch your contexts get rejected outright.
  • Whoever accepts a compressed transfer syntax owns the transcoding. DCMTK needs dcmjpeg/dcmjls; pydicom needs pylibjpeg/gdcm/pillow. "It works with my sample file" almost always means the sample was Explicit VR LE and you have not yet met JPEG 2000.
  • C-STORE and STOW-RS fail differently. C-STORE is a stateful association with per-instance status codes. STOW-RS is stateless HTTP with no negotiation, and it reports failures inside the response body (FailedSOPSequence) — often under a 200. Parse the body; never trust the HTTP status alone.
  • DICOMweb has no C-MOVE. Retrieval is a pull (WADO-RS). If a legacy modality can only C-MOVE, you need a proxy, not a URL.
  • AE Titles: 16 characters, no backslash, and vendors are fussy about case and whitespace. A mismatched AE Title is the number-one cause of "association rejected."
  • Implicit VR plus private tags equals an unparseable file. With no VR on the wire, an unknown private tag decodes as UN, and once it's UN your sequence and length assumptions are gone.
  • Never hardcode a private tag number. Private elements are block-allocated: read the Private Creator element at (gggg,0010–00FF), match its string, then compute the offset. Vendors move blocks between software versions, and your hardcoded tag will silently read someone else's data.
  • Accession Number (0008,0050) is SH — 16 characters, hard stop. A RIS that mints longer accessions will get them truncated or rejected somewhere downstream, far from the source. (Same class of bug: Patient ID is LO, 64.)
  • DS and IS are text numbers. Leading zeros, exponents, and whitespace are all legal. Don't assume your language's parser and the modality's writer agree.
  • PN is not a string. It's five ^-delimited components across up to three =-delimited group encodings (alphabetic/ideographic/phonetic). Treating it as a name will eventually mangle someone's name.
  • Character sets will find you. SpecificCharacterSet (0008,0005) can be multi-valued with ISO 2022 escape sequences. The sane modern answer is ISO_IR 192 (UTF-8) — and since DICOM JSON is UTF-8 by definition, DICOMweb quietly forces the issue for you.
  • If you change pixel data, you mint a new SOP Instance UID. Reusing one is the classic "PACS is still showing the old image and insists it's correct" bug. UIDs are ≤64 chars, digits and dots, no leading zeros per component; derive from your org root or use the 2.25.<uuid-as-integer> root.
  • Pixel data lies in several directions at once: MONOCHROME1 is inverted; apply Rescale Slope/Intercept before window/level; PixelRepresentation decides signed vs unsigned; JPEG color is usually YBR, not RGB.
  • Do not sort slices by InstanceNumber. Sort by ImagePositionPatient projected onto the normal of ImageOrientationPatient. InstanceNumber is a suggestion; geometry is a fact.
  • De-identification is not "strip the tags." Burned-in pixel annotation (BurnedInAnnotation (0028,0301)), private tags, and SR content all leak PHI. Follow the PS3.15 Annex E profiles, and keep a consistent UID mapping or your de-identified study won't hang together as a study anymore.

The DICOM Standard

Toolkits and Libraries

  • C++ — DCMTK - The reference toolkit and the canonical CLI tools. Effectively the coreutils of DICOM. Site
  • C++ — GDCM - The strongest codec and transcoding coverage, with Python/Java/C# wrappers.
  • Java — dcm4che - The Java toolkit beneath dcm4chee, plus a rich CLI suite of its own.
  • Java — PixelMed - David Clunie's toolkit. The site looks like 2003 and the code is more authoritative than most things written since.
  • Python — pydicom - The Python DICOM file library. Pair with pynetdicom for DIMSE networking (SCU/SCP) and CLI apps.
  • Python — highdicom - High-level construction of standard-correct derived objects (SEG, SR, annotations, parametric maps). Writing these by hand is how you produce files that only your own viewer can open.
  • .NET — fo-dicom - Fellow Oak DICOM. Files, DIMSE, and rendering; the .NET pick.
  • JavaScript — Cornerstone3D - The modern web medical-imaging rendering and tools framework (volumes, MPR, segmentation).
  • JavaScript — dcmjs - DICOM read/write/derive in JS; the serialization layer under OHIF.
  • JavaScript — dicomParser - Small, fast browser DICOM P10 parser. Still the go-to for "just read some tags." (maintenance mode)
  • Node.js — dcmjs-dimse - C-ECHO/FIND/STORE/MOVE for Node. Fills the classic-networking gap in the JS ecosystem.
  • Node.js — dcmtk.js - Type-safe Node bindings for the DCMTK CLI tools: wraps 51 binaries, long-lived server processes, a pooled auto-scaling DicomReceiver, and a queued DicomSender with backpressure. (author of this list)
  • Rust — DICOM-rs - Pure-Rust parsing and networking, including TLS.
  • Go — suyashkumar/dicom - High-performance Go parser plus a dicomutil CLI.

Servers and Archives

  • Orthanc - Lightweight single-binary DICOM server with a REST API and a strong plugin ecosystem (DICOMweb, PostgreSQL, OHIF, Python). The default answer to "I just need a PACS by lunch." The Orthanc Book
  • dcm4chee-arc-light - Full enterprise PACS/VNA: HL7, IOCM, FHIR, UPS worklist. The heaviest and the most complete.
  • mercure - A DICOM orchestrator: rule-based routing into containerized processing/AI modules. The interesting new entry in this category.
  • Microsoft dicom-server - Open-source .NET DICOMweb server; the engine behind Azure Health Data Services.
  • Dicoogle - Indexing-focused open PACS with a plugin SDK. Strong for research and query-heavy workloads.
  • Conquest DICOM Server - Tiny, scriptable, Windows-friendly, still quietly running in radiotherapy departments worldwide. (legacy but alive)

Viewers

  • OHIF Viewer - The zero-footprint web viewer. DICOMweb-native, extension-based, and the de-facto standard for browser viewing. Docs
  • Weasis - Desktop Java viewer, launchable from a portal. PET/CT fusion, curved MPR, genuinely capable. Site
  • 3D Slicer - Research imaging platform — segmentation, registration, a huge extension library, and a real DICOM database underneath.
  • VolView - Kitware's browser-based 3D volume renderer and annotator. Processes data in the browser; ships opt-out Sentry crash reporting (see the note below). Hosted demo
  • DWV - Small, dependency-light JS viewer. The good embedding and teaching option.
  • Horos - The macOS open-source viewer (an OsiriX fork; OsiriX itself went commercial). Now supports Apple Silicon.
  • MicroDicom - Capable Windows viewer, free for non-commercial use. (freeware, not open source)

The hosted viewers here clear a bar the HL7 web tools don't — verify anyway. OHIF, DWV, and VolView all publish their source, so "it runs in your browser" is a claim you can audit instead of one you have to take on faith. That is the difference between them and the hosted HL7 tools, and it is why this note is shorter and less alarmed than that one. Read it anyway, because DICOM leaks differently than HL7 does:

  • You cannot eyeball a DICOM for PHI. You can read a PID segment before you paste it. You cannot see the patient name burned into an ultrasound frame, or sitting in a private tag, or embedded in an SR. The file you think is clean usually isn't.
  • The filename is PHI too. VolView's crash reporting is on by default (toggleable in settings, no session replay, source is public — this is disclosed, not sneaky). But SMITH_JOHN_20240115.dcm in an error report is a disclosure whether or not a single pixel moved.
  • "Client-side" stops being true at the codec boundary. JPEG 2000 and JPEG-LS are miserable in-browser, so some viewers quietly round-trip to a server to transcode — see the transfer-syntax note. That is an upload, whatever the front page says.
  • The risky control is the URL bar, not the file picker. Pointing a hosted viewer at your institution's DICOMweb endpoint hands a third-party page your archive and your credentials. Pushing a study to a public demo archive publishes it.

There is no shortage of local viewers above. Use one for real studies, and keep synthetic data for anything hosted.

DICOM Tools and Utilities

  • DCMTK command-line tools - storescu, storescp, findscu, movescu, dcmdump, dcmodify, dcmconv, img2dcm, dcmqrscp. The test-and-simulate workhorses; learn these before you write any code. Tool index by category
  • pynetdicom apps - echoscu, storescp, qrscp and friends, pip-installable and runnable as python -m pynetdicom echoscu. Ideal for spinning up an SCP inside CI.
  • nodejs-dcmtk - Docker image: Node.js on Alpine with DCMTK compiled from source with full library support (XML, zlib, PNG, TIFF). (author of this list)
  • RSNA CTP - The Clinical Trial Processor: the industry-standard de-identification and routing pipeline for trials.
  • RSNA Anonymizer - The standalone "just de-identify this folder" utility.
  • pydicom/deid - Recipe-driven Python de-identification, including pixel scrubbing.
  • KitwareMedical/dicom-anonymizer - PS3.15 profile-based Python anonymizer that's easy to embed.
  • DicomCleaner - Clunie's GUI import/clean/save de-identifier, including pixel-data blackout.
  • dicom-validator - validate_iods checks a file against the IOD/module requirements of a chosen standard edition. Pure Python and CI-friendly.
  • dciodvfy - The reference IOD validator. Grumpy, precise, and still the gold standard. It and dicom-validator disagree in places — if compliance matters, run both.
  • DVTk - Protocol- and message-level validation plus emulators. DICOM Editor is the standalone piece worth knowing: a GUI for editing attributes and sequence items and exporting to text — handy for hand-building test data. (Windows
    • .NET only)
  • Weasis Dicomizer - Wraps images, PDFs, MPEG-2/4 video, and STL into DICOM objects with a GUI for the patient/study/series metadata. The friendly alternative to img2dcm when someone hands you a scanned report that has to land in the PACS.
  • gdcmconv - GDCM's repair tool. Rewrites broken DICOM into something parsable and forces transfer-syntax conversion; the companion to gdcmData and the first thing to reach for when a vendor hands you a file nothing will open. Note GDCM's own doc site is long dead — the Debian manpage is the surviving reference.
  • dicomweb-client - Python DICOMweb client (QIDO/WADO/STOW). The easiest way to script against an archive.
  • dcm2niix - DICOM → NIfTI/BIDS conversion; the standard in neuroimaging.

DICOM Test Data

The DICOM equivalent of Synthea: real, de-identified, publicly redistributable pixel data. Read each collection's licence — "public" is not the same as "yours to ship in a demo."

  • NCI Imaging Data Commons (IDC) - The best modern answer. ~99 TB across 176 collections, DICOM-native end to end (including SEG/SR and slide microscopy), with a Python API and cloud-bucket access instead of a zip-and-pray download. Start here when you need volume or modality variety.
  • The Cancer Imaging Archive (TCIA) - The long-standing NCI-funded archive IDC is largely built on. Still the right entry point when you want a specific disease/modality collection with the clinical metadata attached. Mostly CC-BY, per-collection.
  • DCMTK DICOM test images - The curated index of small, weird, standards-exercising files — the ones that break parsers. This is what you want for unit tests, not a 40 GB CT collection.
  • pydicom-data - pydicom's test corpus as an installable package. The fastest way to get a handful of valid files into CI without vendoring binaries.

Known-bad and unusual DICOM

Valid files prove your parser works. These prove it survives. Everything below is a file some vendor actually shipped, or a specific correctness trap the standard sets for you.

  • gdcmData - The known-bad corpus. 232 files that broke a real implementation, named so you know how before you open them: PICKER-16-MONO2-No_DicomV3_Preamble.dcm, IllegalGroup2ImplicitTS.dcm, GE_GENESIS-16-MONO2-WrongLengthItem.dcm, AMIInvalidPrivateDefinedLengthSQasUN.dcm, MR_Philips_Intera_No_PrivateSequenceImplicitVR.dcm. This is GDCM's own regression suite, so none of it is hypothetical. If you are writing a parser, this is the set that matters. Downloads
  • David Clunie's test images - Correctness traps rather than broken files, from the editor of the standard. Each set targets one thing implementations get wrong: character sets, deflate transfer syntax, signed pixel ranges, and pixel spacing. Pairs with the notes above, which describe these same traps in prose.

DICOM Learning

  • DICOM is Easy - Roni Zaharia's long-running blog. The best "explain it like a programmer" introduction to DICOM, and still being written.
  • Innolitics DICOM articles - A genuinely good series on why DICOM exists, how DCMTK fits together, and what Part 15 means.
  • Saravanan Subramanian — DICOM tutorials - Hands-on Java (dcm4che) and C# (fo-dicom) tracks: C-ECHO → associations → C-FIND/C-MOVE → C-STORE.
  • The Orthanc Book - Its "Understanding DICOM" chapters are a practical primer well beyond Orthanc itself.
  • Book: Digital Imaging and Communications in Medicine (DICOM): A Practical Introduction and Survival Guide — Oleg S. Pianykh, Springer. Still the standard printed introduction.
  • open-dicom/awesome-dicom - A broader (if less curated) DICOM list. If something you need isn't here, look there.

IHE

HL7 and DICOM each tell you what a message may contain. Neither tells you who sends what to whom, in what order. That's IHE — profiles that constrain both standards into an actual workflow, and the vocabulary your vendors will use in requirements documents whether or not you know it.

  • IHE Technical Frameworks - The front door. Domain-organized, freely downloadable, and normative in a way vendor documentation is not.
  • IHE Radiology profiles - Where Scheduled Workflow (SWF.b) lives: the profile that defines how an HL7 order becomes a DICOM Modality Worklist entry and comes back as a study. If you have ever wondered where MWL fits between the RIS and the modality, this is the document.
  • IHE Profiles wiki - Plain-language summaries of what each profile is for. Read this before the technical framework PDFs, not after. PIX/PDQ (patient identifier cross-referencing and demographics query) are the two you'll meet first on the HL7 side.

Security

Healthcare protocols were designed for a trusted network that has never existed.

  • DICOM PS3.15 — Security and System Management - The normative security part: TLS (BCP 195) profiles, the de-identification confidentiality profiles, digital signatures, and audit trail.
  • Both protocols are plaintext by default. MLLP has no transport security at all. DICOM classic networking runs cleartext on 104/11112 (DICOM-TLS is 2762, and vendor support is uneven). The realistic mitigation is network isolation, VPN, and strict AE-title/IP allow-listing — plus TLS wherever both ends genuinely support it.
  • Millions of patient records at risk (Aplite, Black Hat EU 2023) - 3,800+ internet-exposed DICOM servers, ~16M patients, and under 1% with proper authorization. Press coverage
  • CVE-2019-11687 — malware in the DICOM preamble - The 128-byte preamble happily accepts a PE header, so a file can be both a valid .dcm and a working Windows executable — malware living inside PHI that AV can't quarantine without HIPAA consequences. Writeup
  • DICOM parsers are attack surface. Orthanc 1.12.11 (April 2026) alone fixed nine CVEs in parsing and decompression, and CISA issued a medical advisory for DCMTK in 2026. Treat untrusted DICOM the way you'd treat untrusted media files — because that's what it is.
  • Trend Micro — exposed DICOM servers - Background on how these ended up on Shodan in the first place.

Dead ends

Things that rank well in search results and will waste your time. Each one has a live successor.

Don't use Why Use instead
hl7-standard (npm) 53★ and prominent in search; last release 2022 node-hl7 or simple-hl7
Bugs5382/node-hl7-client (standalone repo) Archived; the npm package now ships from the monorepo node-hl7
mirthstunnel Archived Feb 2026 TLS Manager Plugin
tobchen/tc-ssl-plugin Abandoned since 2022 TLS Manager Plugin
tonygermano/mirth-user-privacy-plugin Archived 2025 —
elomagic/hl7inspector (Java desktop) Archived 2020 HL7 Inspector Neo (web)
Imebra Rebranded to DicomHero and went commercial DCMTK, GDCM, or fo-dicom
DICOMcloud Dormant since 2023 Microsoft dicom-server
Starting new work on NextGen Connect Closed-source as of 4.6; OSS line frozen at 4.5.2 OIE or BridgeLink

Contributing

Contributions are welcome — please read CONTRIBUTING.md first. The short version: be honest about maintenance status, disclose it if you're submitting your own project, and understand that tools touching PHI get extra scrutiny.

License

CC0

To the extent possible under law, Michael Lee Hobbs has waived all copyright and related or neighboring rights to this work.

About

A curated list of HL7 and DICOM resources, tools, and hard-won field notes for healthcare integration engineers.

Topics

awesomeawesome-listdicomdicomwebfhirhealthcarehealthcare-interoperabilityhipaahl7hl7v2integration-engineinteroperabilitymedical-imagingmirth-connectopen-integration-enginepacs

Resources

Readme
CC0-1.0 license

Contributing

Contributing
Activity

Stars

12 stars

Watchers

3 watching

Forks

2 forks
Report repository

Releases

Packages

Contributors