The TELemedicine ANYwhere (TelAny) project is based on the medical community's organisational needs. Economic and technological factors heavily determine the way medical practice has been evolving. In the near future the traditional model of direct contact between patients and institutions during routine practice and hospital admissions will not be appropriate for the treatment of pathologies that need a continuous follow up of patients at their location. The other most typical case of remote assistance is emergency.
TelAny aims to address both those issues in a comprehensive approach. The project duration was from June 2001 to January 2003.
The project covers emergency and on-field telemedicine scenarios in extreme cases:
- Monitoring of patients directly accessing life signals using devices implanted in their bodies (scenario A)
- Emergency on board ships in Norway (scenario B)
- All the data collected during the project demonstration sessions will be stored centrally in a large database accessed by consulting specialists (scenario C)
These correspond to the required scenarios:
- Monitoring of patient medical data
- Triage for Medical Emergency
- Content On Demand
- Video conference
- Access to Medical Database
This project contains medical, telecommunications and software information. We think that only co-operation between different communities of professionals can accomplish the difficult goal of increasing the potential user awareness of the benefits of telemedicine.
The architecture is reported in terms of system building blocks (sub-systems) and data flow between the blocks. We start from general models and specialize to TelAny.
1.1. Architectural models
1.1.1. TelemedicineTelemedicine aims to augment the traditional medicine control system model using technology to speed up the process and improve effectiveness. The model we envisage is outlined in the figure below.
Sensors: a new range of external and implanted sensors can be used when connected to telemedicine systems. Non specialized paramedical and non-medical personnel can now help the remote physician in gathering data, thus extending the "sensor" concept. For example in TelAny the non-physician assistant onboard will receive data guided by the responsible physician via videoconference.
TLC: TLC networks are of course one of the essential building blocks of telemedicine. The networks used for gathering data and deliver feedback action can be different, posssibly because of different bandwidth requirements.
Logic: telemedicine logic is based on an interaction between software and physicians. The main software systems employed are: clinical record, decision support and collaborative work. We do not consider as telemedicine applications statistics and information diffusion systems, when not used directly for patient treatment. Of course these telemedicine-related systems are very important in health care, research and education. In many cases logic is completely absent from telemedicine systems. In these cases (TLC based) the system is used mainly for a second opinion.
In many telemedicine projects the responsible or consulting physician is the only "intelligent" actor. Decision support will become more and more important and completely automatic decision is an important future development. For example a control system can take an automatic decision based on data coming from an implanted device, and command drug administration via a feedback system connected to an implanted drug delivery device. A promising developmnt includes two of the TelAny contractors Medtronic and Kell which have developed a logic system based on fuzzy logic.
Feedback: feedback subsystem connects the logic back to the patient for immediate action. The action range from a simple instruction (as "hospital treatment needed") to automatic remote control on some device.
1.2. TelAny Architecture
TelAny implements the previous telemedicine architectural model as outlined in the following figure.
The figure is divided in three main parts, corresponding to the three TelAny scenarios. Both scenario A and B participants generalizing our telemedicine approach employ scenario C. The colors of the sub-systems and the letter beside each block are related to block function in the previous model:
The project is divided in the following work packages:
- Telemedicine applications definition: The aim of this work package is to lay the foundations for the project. This includes both what to do and how to do it.
- Demonstration session's definition: The aim of this work package is to prepare the demonstrative phase of the project. By the end of the WP, we shall have a preliminary plan for the demonstration.
- Telemedicine system architecture definition:Functional diagram of the hardware system with well defined components. Functional specifications for the software. This shall include field interface and user interface for each task. Functional specifications for the TLC networks.
- Procurement and Development Telemedicine sub-system elements: The completion of the developed software and hardware products. Procure the required software and hardware by purchasing or borrowing. Alternatively, a written agreement between the provider and TelAny must be established, ensuring the delivery of the required elements within the time set.
- Telemedicine system integration: During this project's phase the scenarios of Telemedicine test-bed system will be assembled and integrated. By the end of this work package, the end-to-end telemedicine applications shall be operational.
- Test Plan definition: The aim of this work package is to prepare the acceptance test and the installation.
- Test evaluation: Analyse the test results to understand: a) - The technical quality of the integrated telemedicine system; b) - The technical limitations of the integrated telemedicine system.
- Demo setting-up and rolling out: In this phase it will be carry out the experimental section of the project with on-field demonstration tests.
Scenario A is the first prototype of the future health care system where the patient is directly connected to a data network using implanted sensors, satellite telecommunications and sophisticated data treatment.
In TelAny data is transmitted from the patient to the physicians for monitoring. The demonstration sessions will be divided in two phases:
- device not implanted + interface + Globalstar terminal: this environment will test all the system components without real patients
- five patients with devices implanted by the participating cardiologists will be monitored from five centres (see scenario C)
Scenario B, TelAny has devised a demonstration session which will be performed using the telemedicine system on a passenger ship in order to achieve the following aims:
- Promote the user awareness in mobile Telemedicine applications for maritime environments
- Use the feedback gathered during the demonstration sessions, to identify which aspects and components may require further development in order to tailor the telemedicine system towards a competitive solution for emergency applications onshore and offshore emergency applications.
Scenario C, the scenario C itself, is already deployed and used in several programs. In particular, we can refer to the WEBGMS project (in the framework of ARTES 3), which is currently running.
TelAny will provide access to five centers for the demonstration sessions (mainly hospitals where participating physicians work) to access data. At present we foresee one center in Milan (Humanitas hospital - Dr. E. Gronda), one in Rome (San Filippo Neri hospital - Dr. M. Santini), one in Norway and one in ESTEC for demonstration purposes.
TelAny demonstrates the advantages that telecommunications can provide to the future health care system. The large database of scenario C will grow with data coming from scenario's A and B. The participating physicians in Italy and Norway will use this data to support decision making. The environment where data are gathered in scenario A and B are also innovative elements of TelAny. Scenario A directly probes life signals in real patients. Scenario B will test multimedia clinical data transfer in a particularly severe marine environment.
The TelAny system has proved to be successful. Contractors have addressed the issues pointed out in ESA Invitation to Tender (ITT) in 19 months of work, ending in January 2003.
The figures show the Kell J-Hospital diary data representation for one patient using a 7276 dual chamber Medtronic device monitored during the trials in January 2003. All these data (approx. 1000 text and number fields and 10 multimedia signals) have been transferred from the patient's home using the TelAny system. The non-multimedia fields are arranged in forms similar to the following, representing the long set of device parameters.
The multimedia fields are accessible using the dedicated browser. The browser has been developed following physicians recommendations and was one of the main innovations. Having access to both parameters and signals remotely enables a complete view of the clinical situation that earlier needed a complex programmer in order to be viewed. Furthermore, the programmer only gives access to one set of data at a time, while the Kell J-Hospital software stores all data at the Telespazio service center. The Telespazio Evolv-e network is used to enable physicians fast multimedia data access.
Click here for larger image
During the pilot trials data from the PC at patient home via Globalstar was also retrieved. The optimisations and compression of data stored and transferred enables access to signals in less than 30 seconds. This leads to the opportunity of a future extension of the system to allow Globalstar/GSM data access to physicians not in their offices.
During the project we learned a lot about about:
- Wounds and sickness in different maritime environments
- User requirements for maritime telemedicine
- Where the medical officer onboard calls in case of emergency
- Evacuation routines
- Experiences from other maritime telemedicine projects
Discussions after demonstrations gave us valuable information about what participants thought about the TelAny system. The response was very positive. The physicians reported that video-conferences in which the patient was included gave important information about the examination. Audio quality was very good. Picture quality was sufficient to examine the patient, but not good enough to look at details when examining a rash for example.
The medical email software (Doris by Well) is a very suitable application. Pictures are very informative. 12 lead ECG is important in cases;involving heart attacks. Temperature, non-invasive blood pressure, heart rate and oxygen saturation are important values in a number of cases. The doctors were not convinced whether sound from the stethoscope could give any relevant information. This must be further investigated. The documentation of a consultation is easier when it is recorded as an electronic record instead of a phone call. Doris gives very good documentation, especially because the question from the boat and the answer from the doctor are recorded together. A relevant problem is education of personnel on new equipment. The following other statements were selected from the discussion with the audience during press conferences which followed demos:
- Telemedicine is very important in a maritime environment. Often the distance between the patient and the doctor is very long. It may take days to transport the patient to a doctor
- Telemedicine is important in those cases where a seaman will make a regular doctor consultation (non-emergency)
- The medical officer wants to make use of this kind of equipment. It is difficult to explain everything verbally
- The verbal communication between shipboard persons and doctors will always be the main thing
- In a number of situations onboard, time is not relevant. This means that the medical officer can use the equipment without any stress
- The emergency dispatch centres must be able to receive multimedia data.
- Telemedicine equipment must be kept simple
- The equipment and applications demonstrated seem to be suitable for a maritime environment, but the seamen need training
Another important point is that most of the above issues apply to on-shore emergency also.
Last Update: 25 Jun 2012