Bridging a HIS/EMR to Your PACS

The Order-to-Report Loop

1. Order: the HIS sends an HL7 order or scheduling message (e.g. ORM^O01 or SIU^S12). ZiKiT’s HL7 Listener receives it.
2. Schedule: ZiKiT Mapper writes the patient and procedure data into the shared database, which feeds the DICOM Modality Worklist – so the modality pulls the correct patient demographics and accession number automatically, no manual re-entry.
3. Perform: the modality performs the study and sends it to ZiKiT’s DICOM Server via Storage SCP; ZiKiT’s DICOM Listener and Query/Retrieve SCP make it available to your PACS/VNA.
4. Report: the result goes back to the HIS as an HL7 result message (ORU^R01), a DICOM Structured Report, or an Encapsulated PDF – whichever the HIS expects.

Every step runs off the same database, so there’s no separate reconciliation process between the HL7 side and the DICOM side – they were never out of sync to begin with.

No Hand-Written Glue Code

The mapping between HL7 fields and database columns – in both directions – is built by dragging fields onto tables in ZiKiT Mapper, not by writing a parser. That matters because HL7 in the real world is a moving target: the same order message from the same HIS vendor often looks slightly different from one hospital to the next. When it does, you adjust the mapping rule instead of patching code.

See the whole loop working end to end with real messages in the Example Projects – Patient Admission, Appointment Scheduling, Results Reporting, and Query & Response.