An HL7-to-DICOM Integration Engine, Built for Multi-Vendor Environments

Built for Multi-Vendor Environments

ZiKiT integrates against the HL7 v2.x standard, and against whatever variation of it a given site actually sends. Epic, Oracle Health (Cerner), MEDITECH, athenahealth, and smaller regional systems all speak HL7 differently in practice: different Z-segments, different code sets, different field usage, sometimes even across two installs of the same EMR. ZiKiT’s HL7 Listener and Message Broker are built around that reality, not around one reference implementation.

The mechanism is ZiKiT Mapper: HL7 message structures are dynamic, configured per site rather than hard-coded, so when a site’s ADT or ORM feed doesn’t match what was built for the last one, the mapping rule gets adjusted – a field remapped, a segment added – instead of a code change. That’s the difference between an on-site customization and an engineering release, and it’s what makes one integration engine practical across a genuinely multi-vendor fleet of systems and devices.

True Dynamic Mapping for On-the-Spot Modifications

ZiKiT installs with a zero-configuration SQLite database and a working set of default mapping rules, so a first inbound and outbound HL7 message can run within minutes of installing – no separate setup project. From there, the same configuration tooling points at MS SQL Server or MySQL for production, without re-platforming.

Underneath, ZiKiT Mapper maps HL7 and DICOM fields directly onto database tables and columns, and the Query/Retrieve, Modality Worklist, and Storage service definitions are themselves SQL views and mapping rules rather than compiled logic. That’s what makes the configuration dynamic: a schema change, a new field mapping, or a device-specific quirk gets handled by editing a view or a rule, in the same SQL terms your team already works in – not by opening a code editor or waiting on a vendor release.

• Storage, Query/Retrieve, and Modality Worklist service definitions are SQL views and mapping rules, not compiled code.
• Works out of the box with SQLite and a default rule set; scales to MS SQL Server or MySQL without changing tooling.
• One engine, one schema, for DICOM Storage, Query/Retrieve, Modality Worklist, MPPS, and HL7 messaging.

Supported Database Engines

Every message rule, every mapping, every configuration screen works the same way across all three – move up to a bigger database without redesigning your interfaces.

Configuring Mapping Rules With ZiKiT Mapper

ZiKiT Mapper is the tool for building and adjusting mapping rules: drag fields from the incoming message structure onto your database schema to build inbound rules, and watch the actual HL7 message get generated as you edit outbound rules, with a live preview and validation as you go.

DICOM Mapping Into Your Own Database Schema

Most PACS servers store DICOM files and stop there. ZiKiT’s DICOM Mapper extracts data directly out of DICOM tags into your own database schema, using the same mapping tooling as the HL7 side. Because those tag mappings are configurable per device, ZiKiT stays compatible with modality vendors that structure their DICOM output differently – the same mechanism that handles multi-vendor HL7 differences handles multi-vendor DICOM differences.

Main Features

An Integration Partner Throughout the Deployment

ZiKiT is built to be configured to each site – and that’s also how H.R.Z. Software Services works with the teams that run it. Our own integration engineers build the first set of mapping rules alongside your team, tune them against your actual HL7 traffic and DICOM devices, and stay engaged for support once the interface is in production.

A small, senior team, involved for the life of the deployment – the same kind of relationship healthcare IT teams expect from a dedicated integration partner, running on an engine your own team can also configure directly once you know it.

Proven at Scale

ZiKiT’s DICOM Server is the same engine H.R.Z. Software Services builds its other imaging products on – battle-tested across multiple deployments, not written from scratch for this one. It also stands entirely on its own: run it by itself as a lightweight, on-prem PACS, and add HL7 integration whenever a given site actually needs it.