What HL7 and DICOM interoperability actually means for a hospital IT team

If you work in or around hospital IT, you've heard HL7 and DICOM mentioned constantly, usually in the context of an integration project that's running behind schedule. Both are decades-old data standards that most clinical systems rely on, and both are frequently misunderstood by people who aren't working with them day to day. Here's a plain explanation of what each one actually does, and why getting them to work together is harder than the acronyms suggest.

HL7: the standard for clinical data messages

HL7 (Health Level Seven) is a family of standards for exchanging clinical and administrative data between healthcare systems: things like patient admissions, lab results, orders, and discharge summaries. The most widely deployed version in production hospital environments is HL7 v2, which uses a compact, pipe-delimited message format that looks cryptic to anyone who hasn't worked with it, but is genuinely just structured text: patient identifiers, event types, and clinical data fields separated by delimiters.

The catch is that HL7 v2 is intentionally flexible: the standard defines the message structure, but leaves a lot of room for how individual vendors implement specific fields. In practice, this means two systems that both claim "HL7 compliance" can still disagree on how a given message should be formatted, which is where most real-world integration work actually happens: not in implementing the standard, but in reconciling how two specific systems interpret it.

DICOM: the standard for medical images

DICOM (Digital Imaging and Communications in Medicine) is the standard that governs how medical images, such as X-rays, CT scans, MRIs, and ultrasounds, are stored, transmitted, and displayed. Unlike HL7, which is about structured data messages, DICOM defines both an image file format and a network protocol for how imaging devices, PACS (Picture Archiving and Communication Systems), and viewing workstations talk to each other.

A DICOM file isn't just pixels. It's an image bundled with metadata: patient information, study details, acquisition parameters, and more. That metadata is exactly the kind of data HL7 also carries, which is where the two standards intersect and, frequently, where things go wrong.

Where interoperability actually breaks down

A common real-world scenario: a patient gets registered in the hospital's EHR (an HL7-driven event), that registration needs to reach the imaging modality and PACS so the correct patient is associated with the correct scan (a DICOM workflow), and the resulting report needs to flow back into the EHR (HL7 again). Every one of those hand-offs is a place where a mismatched patient identifier, a misconfigured message segment, or a vendor-specific quirk can cause data to silently fail to match up, which in a clinical setting is a patient-safety issue, not just an IT inconvenience.

• Patient identifiers not matching exactly between the HL7 feed and the DICOM study
• Vendor-specific HL7 field usage that differs from what the receiving system expects
• Network and firewall configuration blocking the DICOM protocol between modality, PACS, and workstations
• Version mismatches between HL7 v2.x implementations across systems installed years apart

Why this requires production experience, not just documentation

The HL7 and DICOM specifications are publicly available, but reading them doesn't prepare you for the reality of a live hospital environment: dozens of interconnected systems from different vendors, each with its own quirks, running in an environment where downtime has to be scheduled around patient care and every change carries regulatory weight. Getting these integrations right consistently comes from having actually done it (deployed the systems, debugged the mismatches, and gone through the regulatory sign-off process), not from reading the standard once. That's the background behind Datashark's healthcare systems integration work.