Embedding DICOM and HL7 Into Your Own Product
If you build a device or software product that ends up installed at many different hospitals, the hard part was never writing one HL7 interface. It’s that every site’s HIS sends slightly different HL7 messages – even for the same message type, even from the same EMR vendor.
Per-Site Differences, Without a Per-Site Engineering Ticket
ZiKiT Mapper is built around that reality. When the next site’s ADT or ORM feed doesn’t quite match what you mapped last time, the mapping rule gets adjusted – a field dragged onto a different column, a segment definition added – instead of a code change routed back through your engineering team. That can mean your own field or support team handles most site variations directly, and R&D only gets involved for genuinely new scenarios.
License the DICOM Server as a Component
The DICOM side works the same way for hardware and imaging device manufacturers: run ZiKiT’s DICOM Server – Storage SCP, Query/Retrieve SCP, Modality Worklist SCP, MPPS – standalone, on whatever footprint your device has. It installs with a zero-configuration SQLite database, so it runs on genuinely light hardware, down to a single tablet, with no database administration burden on the device itself. Add the HL7 Message Broker for a given deployment only if and when that site actually needs HIS integration.
The Same Engine, End to End
Because the DICOM Server, the HL7 Message Broker, and ZiKiT Mapper are one product sharing one database schema, a product line that starts as a standalone DICOM device doesn’t need a different engine when a customer later asks for HIS integration – it’s the same component, configured further. That’s also what lets a small, single-site deployment on SQLite scale into a load-balanced, multi-instance MS SQL Server installation without re-platforming, the way Center for Vein Restoration has run ZiKiT in production for over a decade – read the full case study.
DICOM and HL7 are registered trademarks.