Computer applications are indispensable tools in cardiology today for digital image acquisition, deployment and reviewing, and also for documentation, dose reporting, quality assurance and exam scheduling in the Cardiology Information System (CIS). Image archiving systems (PACS) and electronic patient records reduce the required amount of time to access relevant patient information. Furthermore, billing in hospitals is unimaginable without the digital aid of Hospital Information Systems (HIS).
In the past, communication or data exchange between all these systems was impossible. For example, it was necessary to enter the patient name several times into different computer systems. Results from haemodynamic systems or laboratory results had to be re-entered into the CIS. Corrections of errors in patient names were not carried through to the CIS or PACS, a system flaw that doubles work and is a proven source for mistakes.
Interfacing all these systems at a high level is very time-consuming and requires a large effort from vendors and hospital IT administrators. Most of the above mentioned systems are developed by different vendors and operated by different applications in a hospital. That is why in many institutions, these interfaces are not being optimised.
Challenges of Interface Development
Usually, interfaces between two systems take into account only whatever data exchange is necessary for those two systems. In real life, all systems work together in a larger environment and interfaces need to follow the requirements of a complex workflow.
The goal of most communication standards like HL7 and DICOM is to exchange information between two parties using flexible configurations. These standards offer a lot of optional fields for additional information – data that might or might not be delivered by a given system. In practice, a receiving system will often not get any information that is required for the next work step. For example, an acquisition modality might send a set of data of a stress echo examination. The receiving system is able to display all images but does not get any useful information about stress stages and views. Without this information it is not able to perform a proper quad screen display. IHE targets exactly this problem. It defines abstract process models of real world workflows and datasets that are required for these workflows.
Setting Appropriate Communication Standards
In order to reach this goal, clinical experts and software engineers together define abstract workflow models for given scenarios. Using these abstract models, for each data exchange step between two systems the appropriate communication standard and transmission service is selected. In a final step the required data attributes are selected and specified. At this point IHE might overrule a given standard and define additional attributes that are required. Doing that, IHE reduces ambiguity and potential misinterpretation of present standards.
IHE Cardiology Domain
The IHE Cardiology domain was sponsored for the first four years by the American College of Cardiology (ACC) and supported by the European Society of Cardiology (ESC). Representatives from both societies are actively involved in the work of the IHE Cardiology Committee.
As in other IHE domains – such as Radiology, IT infrastructure or Laboratory – in Cardiology there is a Planning and a Technical Committee. Once a year, the Planning Committee defines the most urgent user demands. In the following months, the Technical Committee reviews existing standards and prepares solutions for the given topics. Every group of topics is handled in a so-called Integration Profile. The technical descriptions of these Integration Profiles are summarised in a Technical Framework. After a public comment phase, the vendors implement the framework into their products. Any problems with the framework are communicated back to the technical committee.
For cardiology there are already several Integration Profiles
available. The most important Integration Profiles shall be presented here. A
complete set of Integration Profiles is available at www.ihe.net.
Primary Cardiology Integration Profiles
Cardiac Catheterisation Workflow: The common workflow in a cardiac cath lab includes patient admission in the HIS, exam ordering and scheduling. Image archiving and notification of the HIS about the performed procedure and the availability of image data is also part of this workflow. Typical for cardiology routine, is the high rate of unscheduled emergency cases. It is not uncommon to start the exam with the creation of some images and report back all information to the HIS. This scenario is quite a challenge for proper reporting and billing because it is necessary to reference all exam information to the ‘official’ patient data set handled by the HIS.
Echocardiography Workflow: This workflow is very similar to the cardiac cath workflow as described above. Although ultrasound exams are commonly not performed in emergency situations, another characteristic is relevant from the IT point of view. Ultrasound systems are generally mobile units and therefore not always connected to a wired computer network. This results in problems in exam scheduling for this area. These problems can be covered using this Integration Profile. Another goal of this profile is the proper indication of stress stages and views for stress echo exams. These data can be used by a viewing station for a proper simultaneous display of different stages or views in a quad screen.
Retrieve ECG for Display: A typical problem in cardiology is the quick and easy distribution of ECGs inside or outside of the cardiology department. This Integration Profile makes use of web technology to distribute ECGs in PDF format. This feature might be used stand-alone in a web browser or as an embedded function of an electronic health record.
Displayable Reports: Reports in cardiology not only contain
plain text and numbers. Very often they also contain images, graphics or
tables. For a safe layout control this Integration Profile uses the PDF format to
create reports. These reports can be sent from image analysis workstation to the
PACS or HIS so they are available very quickly and can be sent to the EMR without
producing paper printouts.
Implantable Device Cardiac Observations: A new and promising Integration Profile, this handles the topic
of implantable devices – such as pacemakers or defibrillators that need to be
verified in regular terms using vendor proprietary equipment. Until now, these
data can be collected in vendor databases only or sent to a paper printer.
Using this profile the data from devices of different vendors can be sent over
a network – which also might be a wide area network – and collected in one and
the same database for further analysis or long term storage.
Validating Integration Profiles
All the above-mentioned Integration Profiles were validated in a practical setting during “Connectathons”, events where engineers from different vendors come together and exchange information following the specifications in the Technical Frameworks. IHE offers several advantages for the clinical user. IHE compliant products have already proved their ability to exchange data following the IHE specifications defined in the Technical Framework which includes detailed descriptions of the expected behaviour of each involved system. Therefore these documents can be used by hospitals for describing their demands on new systems and their interfaces.