italiano
english
 ORGANIZATION OF A MODERN DIGITAL ECHO-LAB
version 1.0
The advantages of digital echocardiography laboratory can be summarized in the following points relating to the echocardiographic reporting:
  • Research and consulting reports easier and quicker
  • Complete overview of patient data
  • Comparison of the examinations easier and more effective
  • Availability data transmission
  • Communication with other specialists increased
  • More tools for research and publications
and following, relating to the archiving digital images:
  • Better quality
  • No degradation over time
  • interpretative content unchanged
  • Export of images in different formats
  • Possibility of measures and calculations offline
These two components can be varied in the laboratory of echocardiography in relation to the needs and available resources that are not only economic but also human.
Finally, a limiting factor may be the amount of memory needed to store this information.
The architecture of the laboratory can vary widely and depend on:
  • No. of echocardiographic rooms that requires a network to be in communication
  • Logistics of echocardiographic points within the hospital
  • Presence of a computer network
  • Type of available echocardiography with possibility to export digital static images or video, according to the most modern standard DICOM (Digital Imaging and Communication in Medicine) or only in analog format, usually RGB or S-Video. .
If we think to using the images for archiving and offline calculations outside the echocardiographic machine we have three possibilities:
  1. Analog-Digital connection: is to build a video connection between ultrasound machine and PC that allows to export images in analog format, as RGB or S-Video; the connection to the PC is secured by a card that allows video grabbing, i.e. convert images from analog to digital and then save them in various digital video formats using compression algorithms (MPEG, DVX, etc.).
  2. Analog-Digital conversion: allows to transform, through software, data in analog format in digital DICOM images.
  3. Digital-Digital connection: is requested to insert the ultrasound machine in a DICOM network to make the transfer of DICOM files. Prerequisites are represented by the possibility from the ultrasound machine to export DICOM files and to insert him in a DICOM network according to defined protocols of communication. On the other side to have on the PC a viewer of DICOM files with a module that allows the communication and the receipt inside a DICOM network. Also giving the possibility to make calculations on echocardiographic images transmitted by exploiting the potential offered by the DICOM protocol.
Regarding the storage of images they can be stored on fixed memory of the PC, or other mass media represented by CD-ROM or DVD.
In a extended network the images can be stored on servers with large capacity or PACS (Picture Archive and Communication System) where the potential allow to keep the images online for some time. Obviously the network and the memory are the main cost of digitizing echocardiographic laboratory.
The easy accessibility of clips (dynamic images) and simple static image that would normally constitute the study of the patient allows for a simple and immediate measures eco-linear calculation of volumes and ejection fraction, Doppler measurements, etc.. It also comes increased ease of communication as both static and dynamic images can be exported directly to digital video formats, viewable from any PC for study or presentation.
A network model, focused on images archiving that we propose, can be represented in the below figure where the latest generation of ultrasound machines are connected to PC via LAN for transferring files with DICOM protocol.

The PCs are added into an Ethernet network that through SI_Viewer allows the acquisition of DICOM images by ultrasound machine. SI_Viewer has a local server (Storage SCP - Service Class Provider in DICOM terminology) that is prepared in a network in order to receive and store images on hard disk for a DICOM client wants to send.
As mentioned the received files from the local server are stored in a folder of your choice, if you enable the indexing of DICOM files then all the images received from the local server will also be indexed in a local relational database.
The indexing operation in the relational database consist to store some TAGs (eg patient name, patient ID, mode, etc.) present in the header of each DICOM image, these are subsequently used when the user make a search/query operation and/or retrieval, using appropriate filters of course. Note that SI_Viewer also allows you to manually perform this indexing operation, image by image.
SI_Viewer also provides the users the "Send to remote server" service, which is an implementation of the DICOM Storage SCU (Service Class User). This service allows you to send to another DICOM application (another SI_Viewer installed on another computer, or even a central server DICOM) one or more images selected from those present in the Preview panel.
A remote server or a DICOM PACS (Picture Archiving and Communication System) is an essential service to centralize the storage of DICOM files that many customers will want to send. Note that the nature of these clients may be more heterogeneous, such as other computers, medical equipment like ultrasound machine, etc., it is necessary only that they speak the same language (must be adhering to the standard DICOM). The central server to be complete must allow several clients to search (query, which are done by the DICOM Find SCU) and possibly the retrieval (retrieve done via services Move SCU) the images it contains.
Let's look at a typical use case in which the user wants an image that SI_Viewer suppose not currently present in the local database, but instead present in the central server. First SI_Viewer make a query locally but with negative results,
then it send the same query to the server confirming the success of operation sending to SI_Viewer the image requested. SI_Viewer to receive the images must also perform an operation of local storage and indexing of the new images .
At a subsequent request of any of these images by you, SI_Viewer can recover from its local database without having to ask the server again. Adds the note, perhaps already implied, that all this must be and is transparent to the user.
It is clear that such behavior is proving crucial in order to speed up the interaction between user and program. Indeed, the continuous recovery of DICOM images from remote servers, which can also easily reach the 40/50 Mb, making the entire user-program much slower and therefore boring, also in this way is an important thing, not to run the risk of saturating the Ethernet.