Download Development of Tools for Medical Teleconsultations

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Business intelligence wikipedia , lookup

Medical privacy wikipedia , lookup

Medical transcription wikipedia , lookup

Transcript
Teleconsultations – synergy of medicine and IT technology
Jacek CAŁA, Łukasz CZEKIERDA
{cala, luke}@ics.agh.edu.pl
Distributed Systems Research Group (DSRG),
Department of Computer Science,
AGH – University of Mining and Metallurgy,
Kraków, POLAND
Abstract. Combination of medical sciences with computer networks
and computer telematics creates wide spectrum of new applications
called telemedicine. One of telemedical domains is to make available
digitally represented medical data to medical technicians and
professionals from remote locations. This can improve healthcare and
lower its costs. The application discussed it this article is remote
access to medical patients documentation, and DICOM images in
particular, for consultation purposes.
The paper concludes the research and implementation done so far by
DSRG group in the area of telemedicine. It shows the functional
evolution of applications designed and developed by the group.
Starting from relatively simple WWW-oriented services through
dedicated access and consultation applications, DSRG has created a
comprehensive and sophisticated environment called TeleDICOM
allowing participants from the distributed consultation team to
diagnose the patients in the collaborative way.
Teleconsultation services as very demanding ones should be designed
with deep knowledge and experience in the area of medical data,
distributed systems, computer networks and many others. All these
issues were in mind when constructing the applications and are
discussed in the article.
Introduction
The combination of medical sciences with computer networks and computer telematics
creates incredibly wide spectrum of new applications called telemedicine. The main issue
addressed by telemedicine is overcoming distance barriers. Hence, medical knowledge may
be easily spread to almost any place giving experts chance to intervene in most difficult cases,
physicians to share knowledge or patients to obtain medical advice. As a developing domain,
telemedicine appears more and more frequently in everyday life. The most important factor
which propels its expansion is reduction health care’s costs. Moreover, easy dissemination of
experts knowledge through medical portals, teleconsultation tools or telesurgery results in
improved patient care.
For better understanding of telemedicine it is good to divide the whole area of telemedical
applications into three segments [3]:
1. Content, services, and community. In this category health portals should be rated. They
are organized medical sites that contain information connected with functioning of
medical centers as well as provide expert information to wide range of recipients. Medical
portals can act in a number of ways. They can improve the health care service level for
patients allowing them e.g. to make appointments in hospitals or outpatient clinics. More
advanced systems can provide users with personalized information and services
facilitating access to their medical documents or interaction with medical personnel or
equipment tracking their health condition.
2. Connectivity and communications. The second application in telemedicine is a
rationalization of the health care operation. Internet-capable applications are able to
electronically deliver medical records, claims submissions, referrals, eligibility
verification, lab reports, prescriptions and other clinical and administrative data. Moreover
on-line remote consultations between medical centers either in well-known WWW-based
style or with the ability to offer collaborative, interactive work on shared medical data can
not only considerably diminish costs but also be of great educational importance. Into this
segment a new, promising application – telesurgery may be also counted. Currently,
remote surgery is slow down by very high costs of such service and deficiencies of the
specialized surgery devices which ought to be controlled remotely. It is only matter of
time when this appliances will have proper level of accuracy and allow surgeons to work
freely.
3. E-commerce. The e-commerce segment of the Internet health industry is generating the
greatest opportunity of revenue. Pharmaceutical companies have recognized the value of
this alternative marketing and distribution channel. Health related e-commerce
encompasses other products, including health insurance and business-to-business services.
The article concentrates on the second segment of telemedicine – connectivity and
communications – presenting its evolution from simple web-based applications to advanced
multi-user, interactive teleconsultation systems.
With increase of computer network throughput and computer systems performance,
capabilities of telemedical systems are increasingly sophisticated. In the beginning they just
offered remote access to static patient data e.g. to pictures from radiological database.
Performance gain gave access to multimedia resources and introduction of wireless networks
yielded easiness of such access also from small, handheld devices or even mobile phones.
Currently, there are no technical constraints which could stop or restrain the development of
telemedicine. The only issue is financial barrier connected with costs of migration and
implementation of new systems into healthcare. In Poland bad financial condition of
healthcare is the major obstacle in free development of telemedicine although sometimes it is
the only possibility for ordinary patients to gain high qualified experts knowledge.
Distributed Systems Research Group was recently involved in development of different
telemedical systems and remote consultation tools. Next section presents a brief overview of
achievements of the group in the area of telemedicine and teleconsultations in particular.
Further sections present briefly evolution of telemedical systems and more detailed
description of the developed tools. The whole paper is ended by conclusions.
1
Overview of our research activity in the area of telemedicine and teleconsultations
Distributed Systems Research Group was one of the first research groups in the South Poland
involved in telemedicine area. Interest of the group was started by European funded project –
6WINIT, which focused on validation of use of IPv6 and 3G mobile and wireless
technologies in different areas of life and especially in healthcare. The project resulted with
development of DICOM Viewer tool – the application which addresses the issues of
emergency access to radiology database over both IPv4 and IPv6 networks. The viewer was
dedicated to handheld devices giving users ability to remotely browse radiology database
based on NetRAAD and later on RADAS system.
Next step in extending research of the group in the area of telemedicine was participation in
KCT project (Krakow Centre of Telemedicine and Preventive Medicine). The aim of the
project was rationalization of work of medical centers by introduction of modern information
and telecommunication systems to their daily routine work. Project put strong emphasis on
teleconsultation systems and tools and as a result RaDAS, TeleNegatoscope and Konsul
system were developed. RaDAS offers easy access to a radiology database through WWW
service. TeleNegatoscope is a tool for interactive medical remote consultations over low
bandwith networks and Konsul is a web based system providing non-interactive mechanisms
for medical teleconsultations. Work in KCT project was supported by Krakow John Paul 2nd
Hospital and Department of Internal Medicine of Collegium Medicum UJ.
Currently the group is involved in development of a system for efficient, multi-user and
interactive medical teleconsultation called TeleDICOM. The system integrates and extends
functionality of TeleNegatoscope and Konsul into one powerful application.
State of research of the group was presented on many national and international conferences
including 1st and 2nd E-Health in Common Europe Conference organized by the group.
Activity in the area of promotion of telemedicine were supported by ProAccess project which
focused on creating a platform for promotion, dissemination and transfer of advanced health
telematics concepts and experiences from development and deployment of telemedicine
solutions to Newly Associated States of EU.
2
Technical and architectural background of modern consultation systems
Medicine, similarly to other domains of our lives benefits from the electronic exchange of
information. This can support better organization of medical data and improve health care
especially when distance separates participants – i.e. doctors and patients or doctors
themselves. Today, Internet-capable applications are able to electronically deliver almost any
kind of medical information. Internet health services can be divided into many categories,
among others: systems monitoring patients state, providing experts information to patients,
providing medical professionals with consultations tools and e-commerce services.
As already mentioned, the goal of this article is to concentrate only on accessing medical data
e.g. for consultation purposes and thus it pays no attention to other forms of contemporary
telemedicine. This chapter discusses requirements of telemedical consultation systems taking
into account many aspects which should be considered. The most important factors described
are representation of medical data, technical issues of remote access and importance of choice
of proper architecture for a developed system.
Electronic Health Record (EHR) is defined as a digitally stored healthcare information and
should keep all medical data (such as observations, laboratory tests, treatments, medicine
allergies an so on) collected throughout a patient lifetime. The main purpose of EHR is
supporting continuity of care and its effectiveness although research and educational aspects
are significant as well. An important part of the EHR are the medical images. They can
contain various graphs such as EEG or ECG or specialized images – radiology, USG etc.
Medical images can be represented in various general-purpose formats such as JPEG, but to
achieve truly diagnostic quality they need to be stored in a specialized and dedicated format.
DICOM [6] is the de facto standard in representing medical data. Beyond consisting of one or
more images (which can be then animated) DICOM document stores much more other
information precisely characterizing the examination conditions and patient itself. DICOM
format is extensively used in today medicine and most modern medical equipment support it
generating examination results directly in DICOM. DICOM browsers – applications designed
for accessing and displaying the information stored in DICOM documents – entirely eliminate
the need of printing them on films.
EHR data in hospitals or any other medical centers providing healthcare should be easily
accessible1 when necessary in many places such as outpatient clinic or operation theatre. A
system providing such a service uses hospital intranet network. The traditional wired local
network can be supported by a wireless local area network (WLAN) whose range can be
useful e.g. during visits at patients bed.
Sometimes data stored in EHR records will need to be transferred outside medical center. This
is necessary when EHR data is stored in central (possibly in a scale of geographical region)
repositories and must be downloaded to a particular hospital. When implementing cooperation
between medical centers in exchanging medical data many issues arise which must be solved.
They are shortly depicted below, although part of them is out of scope of this article:
1. need of compatibility of particular hospitals’ EHR systems,
2. need of applying strong security mechanisms and mechanisms ensuring data
consistency,
3. organizational and legal problems,
4. existing effective means of data searching and selecting because the EHR usually
contains great volume of patient’s medical history,
5. existing of broadband network links2 required for remote access. One must be
conscious that DICOM, despite its benefits, is very requiring in terms of bandwidth
and thus can be difficult in use in remote access scenarios. A single DICOM
examination can have several megabytes. A possible approach, when bandwidth is an
issue, is providing a lossy-compressed counterparts instead.
There exist more other reasons for transferring EHR records between medical centers than
only to share them and keep consistent. Access to the data can be required in a number of
situations e.g.
1. General practitioner (GP) doctor, nurse or ambulance worker need to immediately
view summary of the medical record of an accident victim or other emergency care
patient,
2. GP doctor during home visit may want to review medical data of a patient,
3. Patient’s case sometimes cannot be diagnosed by the doctor to which the patient has
directed. The patient’s documentation is transferred to a local hospital or to high-level
specialists from a central clinic in order to be consulted. The procedure can eliminate
the need of referring there patients themselves.
4. Patient’s case could be urgently consulted by a specialist which is temporarily outside
the hospital but is provided with a wireless handheld device able to download and
display medical information of the patient.
Progress in electronic and communication industry caused that above scenarios are technically
fully realizable from almost anywhere. Range of GPRS (and in near future UMTS) service
provided by GSM/GPRS operators encompasses virtually the whole territory of all European
countries. In some public places such as universities, airports or commercial centers there is
even available a public wireless LAN which can offer much faster access to the Internet.
Using public network requires among other things putting special attention to/on security
issues so as to protect medical data from being captured or modified by unauthorized
individuals.
Wireless appliances, such as Personal Digital Assistants (PDA) become more and more
technically advanced and financially affordable. It is possible to use such equipment even to
download and process DICOM images when necessary and PDA devices are very handy and
1
2
Obviously with the necessity of providing its confidentiality in mind
What – of the financial reasons – can pose a problem in many countries, including Poland
in many cases sufficient (see again example 4 above). The portable devices should be
provided with a wireless card, ideally multi-technology one – able to work e.g. in WLAN,
Bluetooth3 and GPRS networks.
Despite mentioned impressive progress in wireless communication, remote access to medical
documentation from place of accident using PDA device considerably differs from local
access from desktop computers. Public network infrastructure cannot currently provide as
good bandwidth and quality of service as dedicated intra- or inter-hospital networks (e.g.
maximum speed of GPRS is about 170 kbps). Moreover, due to insufficient size and quality
displays of handheld devices are able to provide only referential quality of examination (even
those stored in DICOM format), diagnosis must be performed using better screens.
Scenarios enumerated in previous paragraphs can be implemented in a number of ways using
either general-purpose tools or specialized applications with or with no regard on specific
kind of access. The systems’ functionality and user interface friendliness can be various, too.
The proper construction of a medical system is really the important issue and should be
preceded by a detailed analysis and supported with knowledge and experience in the area of
medical data, distributed systems, computer networks and many others. Software architectures
and styles of programming of computer systems continuously change thus it is highly
desirable to follow the trends to develop the application working efficiently and built
according to the state-of-the-art technologies. The analysis presented below has a rather
general significance but can be successfully applied to the discussed problem.
In mainframe systems popular a few tens of years ago programs were usually monoliths with
batch data processing. Progress in electronic industry allowed for popularity of personal
computers, which, initially working as standalone devices, became later a part of distributed
software systems communicating via a computer network. The developed client-server
architectures in which clients are requestors of the service, and the server is its provider, were
implemented in several ways using various techniques and mechanisms. The clients software
tend to become thinner and thinner in the sense that business functionality initially
implemented on the client side was gradually moved towards the server, allowing clients to
fully rely on functions being available on the server.
The modern design approach recommends building systems according to a service-oriented
architecture (SOA). In this style, the main functional components of the software are
packaged as separate loosely-coupled service implementations providing simple and wellknown interfaces for use by other architectural components. SOA is an architectural style that
formally separates services into two categories: services which are the functionality that a
system can provide, and service consumers which need that functionality. This separation is
accomplished by a mechanism known as a service contract, which is coupled with a
mechanism allowing providers to publish contracts and consumers to locate the contracts that
provide the service they desire.
The functional components being developed should be supported by special, already existing,
so called, infrastructure components which provide a set of common services needed by the
service implementations of functional components. The reusable entities can among other
things supply programmer with remote communication between components (e.g. CORBA,
J2EE, Web Services, COM/DCOM, JMX), data and event logging, security mechanisms,
thread management and user interfaces. Exploitation of the rich services available guaranties
considerable speed-up in the system development and increases code reusability. An
extremely popular approach is to provide contemporary systems with a user interface based
3
Bluetooth is a personal network standard, operating on short distances
on WWW browser. Enterprise-scale systems’ WWW interface should be delivered by a
portal.
Portal platforms provide many ready-to-use mechanisms such as:
 access to databases,
 personalization of user interface,
 security of access, including authentication and authorization of users and encryption
of data,
 support for different types of display devices allowing users to access portal services
both from e.g. PDA devices and desktop computers,
and many others. Portal technology allows all these aspects to be integrated and managed in a
consistent manner4.
What to do with systems developed using old, so called, legacy, software architectures? Being
aware of the advantages of the SOA and component-based environments one could say
‘adjust to new paradigms’. The factor which decreases the initial enthusiasm are simply costs
counted in hundreds or even thousands of man-months – depending on the system scale.
Modernization of the nontrivial systems is usually such a complex undertaking that it is not
performed unless there is a critically important reason. The stimulus which forces to the
action is mainly lack of some crucial features, necessity of integration with other systems or
porting to other platforms.
There is however more approaches possible than only rewriting the system from the scratch.
Sometimes it may be sufficient to replace malfunctioning parts of the system or satisfy the
required needs within the existing architecture. If the system is composed of loosely coupled
components with well defined and documented functionality, such undertaking can be
relatively simple. Unfortunately, legacy systems often are heavy monoliths what considerable
complicates the problem.
The remarks presented above have rather a general significance with no particular references
to computer medical systems. They are simply computer systems and the requirements
regarding architecture or implementation are the same. On the other hand they are usually
mission-critical applications with very high requirements regarding their reliability and
accessibility what should induce to drawing particular attention to the proper software
architecture.
Unfortunately, according to the authors’ knowledge, most of the medical systems have been
built using legacy architectures. They are rather monolithic constructions very hard to
enhance and modernize. This is so certainly due to financial factors but blame is also on
decision-makers which do not keep abreast with trends in computer science. The case study
presented in the next part of the article will shortly5 depict problems with functional
enhancing of legacy systems and will present a few systems developed during our research in
the area of telemedicine.
3
RADAS – Radiology Database System
RADAS is a database system providing access to medical examinations in form of DICOM
files and associated simple textual description via an ordinary WWW browser. It aims to
support doctors working inside a hospital by enabling them to view patients examination
using a lightweight application. Nevertheless, RADAS can be also used for teleconsultations
4
There exists lots of portal servers available o at the market such as Oracle 9ias Portal, Sun Java Enterprise
Portal System, IBM WebSphere Portal and Microsoft SharePoint.
5
For a detailed discussion about migrating medical systems towards a new architecture, see [4]
– in such scenario the part which wants their medical images to be consulted puts the images
into a database and provides read access for external users. In inter-hospital consultations data
can be stored either in local hospital database or uploaded into a remote hospital – usually
using some external means. The serious shortcoming of this approach is that RADAS user
interface provides read only access not allowing users to change anything. This makes it
rather poorly suited for consultation purposes.
The information presented by RADAS is organized hierarchically - there are many patients
with many examinations. Each examination can contain many images. The structure of
information is inherited from the NetRAAD system developed by UHC company on which
the system is partially based. Beyond hierarchical organization, RADAS system enables its
users to easily search through the resources using various criteria.
RADAS database stores two kinds of images: DICOM documents of high diagnostical quality
and referential, lossy-compressed JPEG images used for initial diagnosis and useful when just
looking through the database. The conversion between original DICOMs and their JPEG
counterparts is made automatically during placement in the system database.
Comparing to its predecessor – NetRAAD, architecture of RADAS has been thoroughly
changed. RADAS has been built using Java 2 Enterprise Edition (J2EE) technology according
to multitier paradigm with clear separation between business logic and presentation layer
what NetRAAD system is lacking in. The business logic in RADAS concentrates only data
accessing and processing. The presentation layer realized using JSP and Struts constitutes user
interface which has been also rebuilt to look nicer and be more user-friendly.
The screenshot of RADAS system is presented in Figure 1.
Figure 1. Screenshot of RADAS system
4
DICOM Viewer – access to RADAS resources from PDA devices
Wireless handheld devices (PDAs) become better and better equipped providing not only
running simple local applications such as games and spreadsheets but also implementing
applications communicating using the wireless network and performing not trivial data
processing. These growing possibilities allowed authors to design and develop application
remotely accessing DICOM images.
The application addresses the issue of home/street emergency access to patient's medical
radiology database over IP network. In case of emergency (e.g. during an road accident) or
during home visits the medical personnel can review (but not change) the DICOM encoded
radiology data and basic medical summary. In these scenarios, the hospital's data would be
helpful when accessed for reference. A small wireless appliances would be the most
frequently used devices although occasionally laptop computers could be applied.
During the design phase the idea of providing access through WWW browser (such as
RADAS does) has been abandoned. Small sizes of PDAs' displays made using the system
hardly possible although thanks to multitier architecture of RADAS system its presentation
layer could be easily suited to the new resolution. The final decision was other, namely to
develop a standalone application. This helped to organize the user interface optimally with no
overheads of WWW browser and limitations of HTML access strategy.
The layout of the application consists of a few tabs devoted to different functions. First of the
tabs was designed for searching patients in the database, the following ones for looking
through the chosen patient examinations and, finally, viewing the selected image. The user
interface has been so constructed to be possibly good suited to the PDA characteristics. The
handheld devices are usually provided with no keyboard and the virtual keyboard occupies a
lot of place. This is why most actions are possible to perform using only the easy to use stick.
Functional design of the viewer had to take into consideration its specified goals and limited
resources available. Nevertheless, the resulting functionality is quite rich and has been
favourably accepted by radiology specialists from John Paul 2nd Hospital in Krakow. A few
transformations can be performed on the downloaded DICOM image, such as zooming or
adjusting Hounsfield window. The dynamic images can be animated. The user is also able to
display the most important DICOM tags describing patient and the examination which are
associated with the image. Volume of radiology data could result in very large DICOM files,
thus making bandwidth a critical issue. In order not to make the client very bandwidth
consuming (especially due to low bandwidth of GPRS networks), database provides them
with lower quality (JPEG compressed) reference images useful for browsing over the
database.
The application has been implemented in Java programming language what makes it fully
platform-independent and enables running it on a number of devices. The only action required
when porting is reconfiguration of devices display sizes and a resolution.
In the part responsible for DICOM files processing the professional Java
DICOM toolkit from Softlink6 company has been used. The connection
with the hospital database was realized using next generation IPv6
protocol although traditional IP can be also used. Due to public network
usage, the security mechanisms should be very strong. The user needs to
be authenticated and verified (e.g. via token or PKI), and the connection
needs to be secure (i.e. encrypted). The transmission path encryption is
assured by means of HTTPS protocol suite performed by a HTTP server
of RADAS system.
Figure
Figure 1 View of iPAQ device with DICOM viewer running
DICOM viewer has been tested on Compaq's iPAQ PDA devices
provided with strongARM 206 MHz processor and 64MB of RAM and
working under Linux operating system control. Their computational
power was sufficient for this goal and the DICOM viewer worked very
stably. The most troublesome feature of the appliances was high power
6
See: http://www.softlink.be
Figure 2. View
of iPAQ device
with DICOM
viewer running
consumption especially when working in a WLAN environment. View of the iPAQ device
with running DICOM viewer is shown in Figure 2.
5
Konsul – easy way for non-interactive consultations
Konsul system, developed in John Paul 2nd hospital in Krakow, is a prototype system
providing medical teleconsultations for small peripheral hospitals. The main idea of the
system is to reduce costs and effort required to perform medical consultations. In some
difficult cases there is a need to consult with specialists from referential center. Previously,
the physician who wanted to get an advice had to drive from their hospital to the center and
wait for consultation. Moreover, is was difficult to assess if the patient should drive with the
doctor or the case is easy enough to make a diagnosis basing just on medical documentation.
Konsul allows physicians communicating medical documentation between each other using a
web browser. Documentation is uploaded onto a server in a referential center and the case is
consulted by medical professionals from the center. Then results are send back using e-mail or
any other conventional mean of communications. In case of tentative diagnosis the patient is
directed to referential center for detailed examinations.
As the idea of Konsul was accepted and the system was installed in several hospitals,
complete rebuild had been performed to extend its functionality and provide proper level of
security urgently needed in such solutions [4]. Real advantage of the system is the easiness of
use and combining DICOM files with other medical data in electronic form (e.g. Patient
Information Card, raster image files, textual data).
The architectural model of Konsul system is very simple and consists of three main
components running according a client-server scheme. Each component has been shortly
described below and their interaction is presented in Figure 3.
Consultant stations
Acquisition Station
FTP Server
HTTP Server
File System
Konsul I Server
Figure 3. Architecture of Konsul System


Acquisition station runs FPImage, one of many existing DICOM viewers, which can
among others convert DICOM images to various general-purpose data formats. The main
advantage of the tool, comparing to other similar viewers, is the built-in simple
proprietary scripting language which allows users to customize the application behavior
by writing their own programs. The language facilitates processing of loaded DICOM
images, invoking operating system scripts and also contains an embedded FTP client. One
of scripts supplied with FPImage distribution performs converting DICOM files to AVI or
JPEG format, links converted files to generated HTML pages and sends everything to
desirable FTP server. Making few cosmetic changes to the script enabled using it for data
acquisition.
Konsul system server consists of FTP server and HTTP server. Patient examinations sent
via FTP are stored in the filesystem which is the interface used by HTTP server. Finally,
HTTP server allows users to access data using web browsers.

Consultant station of Konsul system is just a web browser. Doctors consulting delivered
cases use it to download and display the files on their personal computers. Occasionally
phone calls with ordering hospital are established to provide the consulting specialists
with additional information regarding the discussed case. The computer used for
consultations is expected to have only graphical web browser and AVI player installed
what is common equipment of ordinary PC computer systems.
Although proposed model of consultation is acceptable and Konsul is well functioning in
three cities (as a client – in peripheral centers) and Krakow (as a server – in consulting center)
the needs for interaction are constantly growing. Using Konsul consultee and consulting
teams work independently and there is no communication between them during a process of
diagnosing. This gives the physician from a peripheral hospital no chance to take active part
in consultation and describe their problem online. Generally, WWW service is not appropriate
for interactive communication, so there must be implemented other more efficient tools to
make better use of faster and faster Internet connections.
6
Supporting teleconsultations with TeleNegatoscope
The KCT project benefited by creation of TeleNegatoscope, a tool for interactive medical
consultation [2]. The name of the tool is connected with its initial destination – remote access
to negatoscope – but it quickly turned out that TeleNegatoscope may be successfully used not
only to transfer radiological images but also other medical documentation like ECG, paper
forms etc (see Figure 4).
Figure 4. One side of TeleNegatoscope sample session
The tool allows two sides, peripheral and referential, to work on the same data at the same
time and exchange opinions and comments between each other. Data utilized by the
application are compressed digital images and annotations. Annotations are made using
simple shapes: ellipses and rectangles which are shared between the sides. Consultation is
also supported by shared pointers owned by participants. Thanks to that during a consultation
only small amount of data is transferred conserving network bandwidth.
As an efficient tool for peripheral medical centers with poor connection to the Internet,
TeleNegatoscope is limited to work only with ordinary graphical formats representing
medical documentation. Unfortunately, the quality of acquired pictures is not sufficient for
some kind of examinations (esp. CT or coronarography).
7
TeleDICOM – sophisticated teleconsultation environment
The idea of TeleDICOM strongly derives from the previous work concerning telemedicine
and teleconsultations performed by DSRG. DICOM format and means of storing medical data
were investigated during development of RaDAS system. The development convinced us that
DICOM is the preferred format giving integration of data and easiness in searching but
medical documentation is also often stored in textual or graphical format or any other format,
appropriate to a device generating the data.
Closely tight with RaDAS and NetRAAD systems is DICOM Viewer showing how to display
DICOM images and tags and what kind of graphical tools is necessary to effectively browse
through a database and view an image. Development of the viewer showed problem of
transferring a DICOM file through low bandwidth networks and the need to overcome such
obstacle e.g. in the way as NetRAAD system does – using JPEG thumbnails.
Konsul system was the first attempt to provide remote consultations. Despite of its noninteractive characteristics, hospitals are really interested in such way of communication. The
most important feature which decided of its success is easiness of installation and use, mainly
because consultation team uses web browser to access medical data.
Another form of teleconsultations offers TeleNegatoscope which is the predecessor one of
parts of TeleDICOM system. The concept of interactive remote consultations i.e. sharing a
common view of medical documentation and cooperating by pointing and drawing shapes,
enables to process consultation in a natural way. Experiments with TeleNegatoscope proved
also that a voice channel should be integrated into one system instead of providing it as a
separate tool. This makes the system easier in use and gives ability to store voice data as an
evidence for later review.
All the experience gained in development of the above applications benefited in better
understanding real needs and constraints of medical environment. TeleDICOM integrates
most of the features of the mentioned applications into one compound teleconsultation
environment [1]. In fact, the system is the combination of the data storage and access system
– called Konsul III – and the interactive tool for medical remote consultations based on
TeleNegatoscope shown in Figure 5. The name of the data storage part is not accidental,
Konsul III integrated in TeleDICOM is the extension of the previous, second, version of
Konsul system. TeleDICOM can be used in two consultation modes: interactive and noninteractive. Whenever possible i.e. computer network connecting participants has proper level
of QoS, the interactive mode should be used. In less efficient environments, TeleDICOM
gives ability to perform old-style non-interactive consultations using the same system.
Figure 5. View of TeleDICOM client during sample session
7.1
Functionality of the interactive part
TeleDICOM operates on so called sessions (or consultations) tied with one particular patient.
A session may consist of multiple examinations. Such an examination is usually a DICOM
image, either static or animated but it can also be other graphical, textual or media document.
As yet, medical documentation often exists only in paper form and the fastest way of making
it available to others via computer network is either to scan it or simply take a picture of it
with a digital camera. All these documents can be simultaneously opened and placed inside
the application window.
On each of such images it is possible to operate in the way analogous to a whiteboard-like
applications treating the medical document as a background. TeleDICOM allows participants
to draw basic geometric shapes such as lines, rectangles, circles, arrows as well as use
specialized tools such as magnifying glass or Hounsfield window adjustment tool. The shapes
mark the region of interest and may be moved, modified or deleted by any of participants
depending on their permissions. Together with the tools they provide an intuitive and efficient
way of performing remote consultations.
Interactive part of TeleDICOM system is a specialized teleconference application, thus to the
features which are surely worth implementing belongs participant management: notifying
about their appearance/disappearance and connecting/disconnecting. As already mentioned, it
is desirable to integrate additional media with the TeleDICOM client application so as to
improve convenience of its usage. Support for live audio and text channels (like chat) is
crucial and video channel is an option. Additional features also important in medical
applications are the following:
 Data anonymizing. Beyond being used for consultations between hospitals, the goal of
TeleDICOM is to become a very useful tool for teaching medicine students. They have the
opportunity to see cases interesting from the medical point of view and may be instructed
by their supervisor. Each student have direct and convenient access to the examinations
from theirs personal computers. Such dedicated sessions would not differ from ordinary
consulting sessions at all. To respect requirement of personal data protection, the medical
documentation is anonymized, i.e. all personal data are removed.
 Data filtering. There are no contraindications, moreover, it would be instructive, to allow
students to participate also in real consultations. This implies introducing a set of
permissions for various participant roles e.g. allowing students just for observation. Data
filtering mechanism can be easily extended as bandwidth available for users can vary.

7.2
There has been considered filtering of media making it possible for users with a lesser
network throughput either completely cut off particular streams (e.g. video) or worsen
their quality.
Session logging. Some sessions should be recorded what is necessary for evidence
reasons and if one wants to interrupt them and resume in some later time.
Functionality of the data storage and access part – Konsul III subsystem
The examinations which are going to be used in consultations must be prior delivered to a
central database forming a patient evidence. From there they are redistributed to computers of
session participants whenever necessary (the same data can serve in many consultations).
Since the volume of data designated for a consultation can sometimes be as huge as several
hundreds of megabytes it is desirable to be able to deliver it to participants’ computers before
exact meeting, e.g. during a night when the available network bandwidth is better and
cheaper. However, it should also be possible to send required but overlooked examinations
during the session.
The resulting diagnosis and recording of the session should be stored in the Konsul III
database as evidence and extension of the patients file.
Konsul III may work as a standalone system providing non-interactive consultations.
Comparing to its previous version main changes concern reorganization of the architecture
according to SOA paradigm and extension of functionality with some minor improvements.
8
Conclusions
The article reviewed applications developed or co-developed by DSRG within the confines of
a few telemedical projects. They have been received with interest by South Poland medical
environment and participants of medical conferences showing that there is substantial
acceptance and demand for such services. As already mentioned, Konsul system has been put
into everyday practice in a few hospitals. Nevertheless, financial condition of health service is
usually poor. Financial barriers manifesting among others in lack of modern medical and
computer equipment and broadband access to the Internet will unfortunately delay and stop
introducing modern telemedical applications into common use.
9
References
1. J. Cała, Ł. Czekierda, TeleDICOM - environment for collaborative medical consultations.
Proceedings of 1st International Conference on e-Health in Common Europe, Krakow
Poland.
2. J. Cała, TeleNegatoscope – medical consultations for low-bandwidth networks (pol.
TeleNegatoskop – konsultacje medyczne w sieciach o niewielkiej przepustowości); 6th
Conference of Internet and Medical Telematics (2002 Cracow).
3. S. McGeady, The Internet as Disruptive Force in Healthcare, Internet Technologies in
Healthcare, Industry Report, 1999
4. J. Cała, Ł. Czekierda, K. Zieliński, Migration Aspects of Telemedical Software
Architectures, Proceedings of 2nd International Conference on e-Health in Common
Europe, Kraków 11-12/03/2004.
5. J. Cała, Ł. Czekierda, K. Zieliński, S. Zieliński, Collaborative Teleradiology
6. DICOM – Digital Imaging and Communications in Medicine, http://medical.nema.org
7. J. Kosińska, P. Słowikowski, Technical Aspects of Portal Technology Application for eHealth Systems
8. M. S. Pallos, Service-Oriented Architecture: A primer, eAI Journal, December 2001