Elaborate, evolving network to link radiology and cardiology
At Basle University Hospital, Switzerland, a unique networking project for the hospital's cardiology department is under development.
During an EH interview, Professor Stefan Osswald MD described this complex system and its future potential
Basically, we tried to set up a clinical database into which we could feed not only simple text formats, such as letters or examination results, but also alphanumerical data as numbers or categories. One example: A patient’s blood pressure is too high – this result is not fed into the system as ‘high blood pressure’ but is measured as a number which, in turn is translated by the system into a report. Angina pectoris is another example: We have classified four characteristics, then described Angina pectoris itself with grades I, II, III and IV. Then we had to determine what four components best describe a classical Angina pectoris. If, for example, only three of the four characteristics are positive, then this is an atypical form of Angina pectoris. Working with the system requires that everyone knows what we mean by terms such as Dyspnoe IV, or Angina pectoris II. We force the doctors to use the systematics that we have lodged in the database.
Only at the end of the data recording do we allow prose, i.e. a subjective, written diagnosis. A typical example that you would find in every anamnesis, such as ‘the slight suspicion of atypical, mild chest pain’, does not help us with our analysis, which is why this type of information is being reduced to the absolute minimum. This allows us to collate around 80-90% of all data analysed in a systematic way and to store it in a database. We have around 45 modules - for example, cardiac examination, clinical examination, or the module stress electrocardiogram, left heart catheterisation or pacemaker implantations. All workstations are connected to this system, i.e. when a pacemaker is implanted, the details of the pacemaker, such as serial number and model, are fed into the system, then I add my medical data. When an examination is finished I can generate a report, which is transcribed into a text document.
This is sent to the patient’s general practitioner (GP) – all GPs are also connected to the database. Via our interface with our hospital server, we can copy patients’ master files and scanned documents generated by GP surgeries, and these are cleaned up in an intermediate step, to guarantee data are stored correctly. Unfortunately we have found that master files – until now only used for administrative purposes (e.g. invoice issuing) contain quite a few errors; for example, duplicates where a patient named Müller is spelt with an ü in one place and with ue in another. When you try to link medical results with this file you run into problems. That’s how we realised that master files must put a lot of effort into cleaning up master files, to ensure we do not generate false medical diagnoses. That process is now standard. Everyone who deals with a patient, for example ensures that the address matches.
All alphanumerical information is stored on our server. ECGs are stored on separate servers and each time somebody does an ECG using one of the machines connected to the network, the system creates a log that says we carried out an ECG on, say, Mr Müller. When we next go into the system, we can generate a PDF file of that format. Unfortunately, this is not yet possible with angiography images, nor with MRI, because we are waiting for our PACS system. We expect this will store a log with an MRI image in our system, so then we will have access to those images via a link.
So we are building a motorway between cardiology and radiology, which flows both ways and additionally frees up space on our server. We are already connected to a RIS system. When a left or right cardiac catheterisation is carried out, the X-ray machine copies all the data from our system and we no longer have to retype the data from one machine into another. We have a few different interfaces of this kind and therefore access to a large number of different systems and servers. We basically have a fully electronic anamnesis. Hand-written admission letters are put through a mass scanner then electronically stored, so that effectively we have complete electronic patient files.
Scientifically the database helps because we have fast access to all our patients, but you always have to carry out a separate data collection for each scientific study. You can, for example, copy left or right cardiac catheterisation data we already have, but, when prospective, each study protocol is written in such a specific way that data must be collated separately. The same goes for statistics. If I want to do a prospective examination study tomorrow I must plan it as such, because each database is only as good as its user, who regularly cleans up the data and inputs them completely - and, if someone does not complete all the fields, you are left with an empty line here, an empty line there.
We have no secretarial staff to write reports, of which we generate around 700 - 800 daily. So, everyone, even our head of department enters his own data and report. We must compromise between how much we’d like and what we can leave up to the individual doctor, so that in the end we are left with a useable data file. Another form of quality control is to look at our users, i.e. to find out who never completes files. Or we cross-correlate data by grading Angina pectoris I to IV, then look at the respective catheterisation results. If we then separate this result according to the different examiners, and assume that the head of department and senior consultant have more experience than a student, then there must be a correlation.
Should the database show something different, we’d assume it probably doesn’t understand a fact correctly. However, if you realise that the hit rate averages around 95%, then you must speak to those who differ, because they probably haven’t understood the system. But if you realise that even the most experienced examiners keep achieving bad hits then you can assume that the category itself is the problem.
Of course there is a certain amount of effort if you want to evaluate data statistically. Because we have predefined many categories, it takes five minutes to write a report. It may sound complex, but the advantage is that everything is available electronically and there is no need for unnecessary telephone calls, as our periphery is also connected to all our data. The Internal Medicine Department takes the reports directly from our server, so they don’t have to ask our secretary or head of department for information.
GPs receive reports by mail. Doctors connected to our network have online access and also can register patients electronically. As soon as the registration is electronically processed and an appointment allocated, an e-mail is sent to the GP. Following an examination, both the appointment and result is available within the network, to which the GP has access. This does not completely replace dialogue with GPs, but now we can concentrate on a factual dialogue instead of administrative issues.
As yet, we have no electronic lodgement of resources, so the system does not recognise that, say, patients A and B cannot have an ECG on the same day. So this is still done manually. We have a precisely measured number of slots; when these have been used then we have to switch, because the system wouldn’t accept our request, which is the way it was planned. The problem is that in this way we cannot realise our volume. As soon as the resources become scarce and you tell the system to block any further requests after eight catheterisations, you then cannot treat the two emergency cases. And if you have another three cases in the dermatology department, and another must be referred to the surgical ward, you should still be able to plan this in the system. That’s why a coordinator does it all manually. We are always working to improve planning, because almost 50% of cases are emergencies. If we automatically limit our resources we hinder ourselves.
The system we have developed is ideal for us. Its power lies in its 100% open platform, connected in all directions, which gives a great overview of what happens with patients. If, on the surgical ward, I’m called to see a patient whom I’ve never met, I can use the database to gain an initial overview, to establish a qualitative, preliminary assessment - a great help when assessing a patient in person.
However, the power of the system only comes into its own if all data and information is entered. If they are not, because, for example, the surgical ward uses a different ECG system, then this power is diminished because some of the patient’s data is missing, so we cannot form a complete opinion. In other words, the system is only good when we ensure that it can communicate with other systems and is aligned with these.
01.07.2006
