Interfaces – open and
secure for the future
through global standards.

Compliance with international standards ensures the long-term availability of the data

Right from the start, e-pacs was conceived and implemented so that is based on a few globally recognized standards. Essentially, the following interfaces are available:

  • The e-pacs department server contains a complete DICOM Archive Server for manufacturer-independent long-term archiving of medical image data
  • The e-pacs File Management Gateway makes possible secure long-term archiving of non-DICOM data (e.g. from patients’ electronic records)
  • e-pacs can be simply and efficiently integrated into the clinical workflow with HL7.

DICOM Storage Service Class Provider

The e-pacs department server is usually implemented “behind” the PACS as a long-term archive.  The communication is based on the standard DICOM commands and offers the following functional spectrum.

  • Archiving by transmitting the image data via C_STORE
  • Confirming via DICOM Storage Commitment
  • Querying via DICOM Query (C_FIND)
  • Requesting via DICOM Retrieve (C_MOVE)

Alternatively, the e-pacs department server can also be used in smaller installations as a full-fledged PACS server. For clients who do not have failure-secured architecture in their primary PACS, this offers a genuinely elegant failure-protection concept: in the event of a disturbance in the primary PACs, the e-pacs department server assures that selected workplaces have access to the complete database.

For details of the DICOM connection as intended in the standard, please refer to the DICOM Conformance Statement of the e-pacs Storage Service.

PACS solutions from the following manufacturers are already equipped with an e-pacs interface and are currently being productively used with e-pacs:

  • AGFA
  • Cerner
  • Chili
  • Digithurst
  • GE
  • Infinitt
  • Medos
  • Medical Communications
  • Öhm & Rehbein
  • Siemens
  • Tiani

e-pacs File Management Gateway

The e-pacs File Management Gateway is used to archive non-DICOM data, e.g. from patients’ electronic records or from a sleep laboratory. For reasons related to long-term availability, it is deliberately not conceived and realized as a hierarchical storage-management solution that depicts a virtual file system. Instead, it essentially consists of four directories:

  • ARCHIVE: All data which need to be archived are stored here under unambiguous file names.
  • RECEIPT: Each file is individually confirmed via an ASCII file.
  • REQUEST: The request for archived files occurs via an ASCII file.
  • RESTORE: e-pacs places into this directory the files, in their original formats, which have been made available from the archive.

For a detailed description of the interfaces, please refer to the specification of the e-pacs File Management Gateway. The e-pacs File Management Gateway is optionally available and only in combination with the e-pacs Storage Service
 

HL7 Interface

The HL7 protocol integrates the e-pacs Storage Service into the clinical workflow. It is implemented on several levels:
 

Changing Patients’ Core Data (Patient Update / Patient Merge)

If subsequent changes are necessary in patients’ core data, e.g. to correct misspelled names, the erroneous data are corrected in the Hospital Information System (HIS). Images which have already been generated prior to this point in time now receive the “wrong” patient data. Because the e-pacs Storage Service unalterably archives the data as required by the x-ray regulations, patient data in the images cannot be subsequently changed. Via the HL/change service, e-pacs can subsequently insert the changes that have been received via HL7 into the database and update them on the fly, without changing the originals. This means that changes in patients’ core data are automatically incorporated afterwards in the PACS. In addition to taking effect when changes need to be made in core data, this mechanism also comes into play in the event that two patients must be merged into one because, for example, a returning patient had not been recognized as such and had been erroneously entered as a new patient by patient-reception personnel.
 

Triggering of Pre-fetching via Electronic Request for Services (Order Entry)

Pre-fetching can be triggered if electronic requests for services – i.e. so-called Order Entry messages, which are ordinarily transmitted from KIS to the Radiology Information System (RIS) – are sent to HL7 and if copies of these requests are relayed to the HL7 Gateway of the e-pacs Storage Service. When this occurs, the system automatically checks, according to individualized guidelines, to ascertain whether or not all necessary earlier images are available for speedy access in local image storage. If some or all of the necessary images are not available here, the required earlier images which were generated prior to the time when the patient undergoes the most recent examination will be automatically made available from the e-pacs Storage Center.

The HL7 Interface is optionally available and only in combination with the e-pacs Storage Service.