Web-Based Data and Knowledge Sharing Between Stroke Units and General Practictioners

Abstract

We describe a telemedicine application for emergency management in Stroke Units, where prompt decisions must be taken, often knowing neither the clinical history nor the stroke symptoms onset modality. We have designed and implemented an Information and Communication Technology architecture for the situation in which a general practitioner is called for a suspected stroke and provides for the admission to a Stroke Unit. By means of a palmtop and a wireless Internet connection, he can send to the Stroke Unit the demographic data, the list of the patient’s problems, current and/or recent therapies, and a guideline-based stroke-specific form with the objective examination results. In this way, the Stroke Unit team is alerted and informed before the patient arrival, and can manage the urgency at the best. The proposal involved 20 general practitioners and one Stroke Unit in the Lombardia Region, Italy.

INTRODUCTION

More and more evidence is showing that medical decisions are often impaired by lack of communication, or even communication errors, among the healthcare professionals involved in a patient management. This is particularly true when patient transfer and different professional skills are necessary. As a consequence, several diagnostic procedures are duplicated, interventions are delayed, and wrong treatments may be delivered. This causes both health damage and waste of resources. The problem is not confined to our country¹, on the contrary it has been highlighted worldwide². This might be due to the fact that both medical knowledge and technology are growing so rapidly that it is difficult for practitioners to keep up, and the health care system itself is evolving so quickly that it often lacks co-ordination.

“... These stunningly high rates of medical errors - resulting in deaths, permanent disability, and unnecessary suffering - are simply unacceptable in a medical system that promises first to ‘do no harm’ “ says William Richardson, chair of the committee that wrote the American report². The majority of medical errors do not result from individual recklessness, the report says, but from basic flaws in the way the health system is organised. To give simple examples, illegible writing in medical records resulted in the administration of different drugs, while sparseness of data resulted in the administration of a drug for which the patient has a known allergy. Again, when several practitioners treat a patient, each of them often does not have the complete information about the medicines prescribed and the patient’s history.

On the other hand, the potential of the information and communication technology is nowadays enormous and several patients’ data are stored electronically, even if they are sparse: the challenge is to devise suitable functional architectures able to deal with the very complex workflows of the different healthcare settings.

In this paper, we describe the context of ischemic stroke management and we show how new technologies can be successfully applied for shortening the intervention time for these patients.

The paper is organised as follows. The second Section describes the medical problem; the third Section briefly illustrates a widespread software tool, which GPs were using, also before the project startup, for storing patients’ data during the encounters in their office. The fourth Section illustrates the functional and technical architecture that was built on top of that tool, with particular attention to the communication aspects with the SU. The sixth Section illustrates the system functionality from the SU side. The last Section presents conclusions and future developments.

THE MEDICAL AND ORGANISATIONAL PROBLEM

Stroke is a cerebrovascular pathology with a big social impact: the prevalence in Italy is 1262 events per 100,000 inhabitants; there are more than 700,000 subjects who experienced a stroke and are surviving with minor or major effects. More than one third of them have a disability degree impairing the daily living activities. The forecast is that in 2008 the number of stroke patients will increase to about 950,000, due to the population aging. In the world, stroke is the third cause of death and the first cause of disability in elderly people. These numbers justify the efforts for a better stroke management. In fact, scientific evidence definitely showed that there is a “need for speed”, that only special departments, called Stroke Units (SU), can guarantee, to limit the damage of the cerebral infarction³.

Interventions to shorten the time from onset to treatment are being developed by different groups⁴, because the most effective therapies may be delivered only in the first four/six hours from the symptoms onset. But too many patients still arrive at the hospital with a great delay, when the therapeutic time window is over. In addition, once the patient is admitted, both radiological and laboratory examinations must be performed as soon as possible and drug treatments must be initiated, that can benefit from knowing patient allergy, intolerance, current treatments and previous side effects.

Unfortunately, patients are often unconscious or too confused to provide correct information, and relatives are not always informed enough about them: these patients have a mean age over sixties, often they live alone and have co-morbid conditions requiring multiple drug treatment. This causes effective treatment delay and errors.

That’s why data and knowledge sharing between the Stroke Unit (SU) team and the General Practitioner (GP), who holds the most complete knowledge about the patient clinical history, could be of extreme value. Our project promotes this cooperation. Consider that in Italy, in the daytime, it is quite normal to call the GP for urgencies. From our database of past stroke patients we estimated that a high number of them or their relatives (about 45%) called the GP, the most part within 2–3 hours from the symptoms onset. Moreover we estimated that the GP arrives within one hour (median value) from the call. The median time from home to hospital is half an hour. As mentioned, more time is often lost at the hospital for the initial assessment. Our system is thus an opportunity for a good percentage of stroke patients to receive a better treatment, and remain within the “therapeutic window”.

THE GENERAL PRACTITIONERS’ ELECTRONIC CLINICAL CHART

Before describing the telecommunication system, we illustrate the package that GPs participating to the pilot study have been using for some years, because it is one of the main starting points of the project. In fact, GPs share a common structure for the electronic patient record, implemented through the Millewin™ package^§. It is a problem-oriented clinical chart⁵, storing all the information collected during the encounters at the GP’s office. Its main characteristic is that every prescription must be related to a patient’s “problem”, codified through the ICD9-CM (International Classification of Diseases–9^th revision). Only when the problem is not present in the classification, the GP can create his own code for it. In this way, the data are collected according to a well-defined rationale, thus allowing the performance of sensible statistics and comparison among different practices.

Of course, attention must be paid in managing patient’s problems correctly. Problems may (and must) be closed when patients recover from them. If this is not done, it may occur that two opposite problems, for example hypertension and hypotension, appear simultaneously. But also closing problems deserve attention: for example, a myocardial infarction is an acute problem (ICD9-CM code 410). If the patient recovers, the acute problem may be closed in few weeks, but having a past history of infarction is important, because it puts the patient at risk for future cardiovascular events. In this case, once the acute problem is closed, another problem, namely “previous myocardial infarction” (ICD9-CM code 412) must be opened and never closed.

Following these rules of thumb, Millewin allows maintaining a rational view of the patient status, thus representing a good basis for communicating fundamental data to specialists and colleagues in different healthcare institutions.

The main idea of our project was to allow GPs to send as soon as possible the most useful information to the Stroke Unit, when a patient has a stroke, independently from the setting where the diagnosis has been done, whether at the office, or, more frequently, at patient’s home. We remark that stroke may be recognised with a high probability in a very short time: clinical manifestations and patient history are in general sufficient to make the diagnosis, while instrumental and laboratory tests are necessary to establish the specific stroke type and to plan the therapy accordingly.

THE FUNCTIONALITY OF THE SYSTEM

Figure 1 provides a functional view of the system. Millewin runs on a PC, and it is extremely rare that GPs bring with them a portable PC during domiciliary visits. Thus, as the first step of the project, GPs have been provided with a palmtop computer. Here, a subset of the Millewin data is daily reversed, in order to be available for the home visits. The data subset, for each patient, is composed by demographic data, the list of the actual problems, including allergy and intolerance, and the list of the current therapies: this is the minimal data set that GPs consider sufficient to improve the efficiency of their visit at the patient’s home in general, i.e. not only for stroke patients. In addition, the palmtop embeds a stroke-specific form, to be filled in the case of such a patient. These additional data concern pre-stroke disability, Cincinnati pre-hospital stroke scale, useful to identify patients who may be candidate for thrombolysis, the symptoms onset time, and some simple measurements, such as blood pressure, cardiac frequency, cardiac rhythm and glycaemia (see figure 2). A free text field is available to enter additional information, that may be provided also by relatives or the patient himself. A rule-based alert system is also embedded for the differential diagnosis with hyperglycaemic coma.

Figure 1.

The functionality of the system. Internet connections, both wireless and not, allow the communication between the general practitioners and the Stroke Unit team

Figure 2.

The information collected on the palmtop and immediately transmitted to the Stroke Unit.

We remark that collecting and interpreting these data is suggested by the SPREAD guidelines⁶, thus our system is compliant with the most recent evidence-based literature.

As soon as the form is filled, an internet connection is opened, through the infrared coupling of the palmtop with the mobile phone. Both the Millewin data subset and the information collected “on site” are transmitted to the SU, which hosts a relational database management system together with a web server.

Data arrival in the SU database fires an alert, i.e. a window pops up with the name of the arriving patient, the GP who sent the data, and the timestamp, as shown in figure 3. At the same time, a vocal message alerts the personnel. Alert runs on several PC workstations, in order to maximize the probability to be acknowledged as soon as possible.

Figure 3.

The alert for the Stroke Unit

This workflow model allows the SU operators to know in advance some important characteristics of the incoming patient: knowing the personal history helps to choose therapies once the actual clinical situation has been evaluated. For example, if a patient’s problem is renal insufficiency, mannitol will not be used; on the other hand, a favourable condition for fibrinolytic treatment could be devised, also in relation to the elapsed time between symptoms onset and admission. Moreover, knowing the patient’s conditions at the moment of the GP encounter is very useful to evaluate the early stroke evolution (stationary, improving, worsening).

The Technical Architecture

Figure 4 shows the technical solutions devised to develop the functionality described above.

Figure 4.

The technical solutions for the different architecture components

1. A Visual Basic program queries the Millewin database in order to obtain the minimal data set for all the patients; data are reversed into an MS-ACCESS file, whose structure is present also in the palmtop (the choice of MS-ACCESS just derives from its availability on the WINDOW-CE operating system of the palmtop); this operation only requires the physician to run a simple Export application on his PC;

2. As soon as the palmtop is put into its support, connected to the PC USB port, the synchronisation program automatically updates the MS-ACCESS file on it. Export and synchronisation take about half a minute. From now on, the physician can leave the office with his patients’ minimum data set on the palmtop. The palmtop user interface has been developed in Visual Basic.

3. To send data to the SU, it is necessary to open the internet connection: the only optional required for the mobile phone is the infrared port. On the SU side, a web server accepts the data and stores them again into a MS-ACCESS file. Another server is enabled to alert clients in case of a patient’s data arrival. These clients reside on the SU operators PCs.

THE STROKE UNIT WEB SITE

Physicians in the SU may look at the data sent by the GPs through the reserved area of the SU web site. Clicking on the alert window they can immediately access the page: Figure 5 shows the data visualisation. We’ve already described the usefulness of such information for planning the acute phase treatment, but the SU server provides services also after the acute phase, for both citizens and GPs. In fact, the latter will benefit from the system not only because they can access, through the palmtop, the crucial patient data at the bed-side, but also because they can follow their patients’ evolution: as a matter of fact, the SU server will make available to them a summary of the patient status, and the patient destination after discharge. The discharge letter can be sent to the GP via e-mail, just by clicking on the patient’s name.

Figure 5.

Patient’s data at the Stroke Unit web site

Two services are addressed to post-stroke patients: a “questions-and-answers” area, where they can ask questions with a response guaranteed within 24 hours, and a diary for those undergoing anticoagulant therapy for secondary stroke prevention. Here, they annotate their INR (International Normalized Ratio) and PT (Prothrombine time) values, normally performed every some weeks, in such a way that physicians can access data on a more regular and frequent basis, without waiting for the control visit, that could be planned in few months. This allows early detection of a possible need for therapy adjustment.

CONCLUSION

The application described in this paper must be viewed as a piece of the puzzle that constitutes “the continuity of assistance”. That’s why we also gave a brief description of the information and telecommunication supports utilized before and after the acute episode. As a matter of fact, we believe that any medical informatics application cannot achieve its effectiveness unless it is fully integrated with the healthcare workflow, where the patient is always at the centre of the process, wherever he/she is treated. The authors are aware that more benefits for stroke patients would derive with the involvement of other healthcare structures, such as emergency departments and ambulance services, to cover the cases where GPs are not called. This is in the future plans of the project.

The pilot study is at the beginning. We involved 20 GPs, and thus, considering the incidence statistics, during the first year we plan to collect experience about 40 stroke patients with the new proposed management modality. First of all we want to evaluate the acceptability and the perceived usefulness of the system.

As future developments, since the architecture is applicable to several diseases, additional disease-specific tools will be added to the palmtop application, and more formal evaluation studies will be carried on.