Tipos de Interface hombre máquina

Perhaps one of the greatest benefits of computing in radiotherapy is the reduction of transcription errors (by only storing information in one place). The radiotherapy pre-treatment process involves many different groups of staff adding new information and modifying existing information on the patient’s treatment plan. If one is to carry this out manually, then an accurate patient treatment relies on all staff concerned transcribing important information with no errors from one piece of paper to another. This can be particularly troublesome with numbers and decimal places!

If one can generate the information for patient treatment on the planning system and then save it on a server that all other staff, and the linac, can access, then there is no need for anyone to copy any important data. But how do we store all this information electronically in a way that is safe and accurate? We use software called adatabasedatabase .

5.5.1

_{DatabasesDatabases}

Don’t give up at this point just because of the title! Databases are quite simple beasts if we don’t get too technical. The main aim here is to store information in an orderly

PUTTING THE IT IN RT 52

manner (so you can find it again!) with no repetition. The best way to accurately keep a record of a piece of information and be able to update it is if there is only one copy of it. At a basic level, a database is a way of storing large amounts of related data in the simplest way possible. There is lots of complex maths behind this, but let’s not go there. If we consider the information required to treat a patient with radiotherapy, this should all be self-explanatory.

In a patient’s paper notes (if you still have them!) every piece of paper should have a patient ID sticker on it. This will contain information unique to the patient: first name, surname, ID number, address. This is a sensible approach, for if an important piece of paper (e.g. prescription card) is dropped from the patient folder it will be instantly identifiable and easily reunited with the patient notes. However, what if we discover that the patient’s ID number on the ID sticker is incorrect (due to a data entry problem)? There may be tens (or hundreds) of stickers on the notes, treatment plan, images etc. and we’ll have to manually correct every one of them!

However, if this information is stored in a database, then it can contain all the infor- mation in the notes, but organized to store each unique piece of information in one place only. As such, in its storage form, it would not make much sense. However, the database is a bit clever.

If we consider the patient’s ID sticker. We would store the information to generate unique patient IDs using the following identifiers:.

◆ Unique identifiers (that cannot be changed) e.g. name, date of birth, NHS number

and hospital number. We store this information together in a ‘demographi c table’.

◆ Identifiers that can be changed by the patient e.g. telephone number and address.

We store these in an ‘address table’.

We then link these together e.g. the demographic table can have many address tables.

We are saying that whilst a patient can only have one copy of the demographic table (therefore only one DoB, name etc.) they can have many copies of the ‘address

Patient Demographics First Name Surname DoB NHS Number Address 2 Address 1 Fig. 5.4

SUMMARY 53

table’. Therefore, more than one address, phone number etc. These two tables are joined together and the join knows this rule. This rule is a relation, which makes

arelational databaserelational database (albeit a very simple one). This concept can be easily expanded

to include the course of treatment (patients can have many courses, unfortunately), each course can have many phases etc.

By storing the patient’s data in this way we only have to store (or change) information in one place. So, if we enter Marjory Bloggs particulars into this database and you are about to authorize a completed electronic treatment plan, but, oops, you notice we’ve spelt her name wrong! You can change it in one place and all the multiple plans, images etc. will now be linked to this new name you have entered. This is an improvement on changing thirty ID labels in the paper example. Press print and any paper reports will come out correctly too.

The possibilities, from this simple start, are almost endless. At a press of a button you can retrospectively gather all kinds of information from clinical trial data to workload figures. However, it is important to stress that if you don’t put the information in at the start, then it won’t be there later.

The cynical among you may be thinking, so very good, you have all the information in one place and once it is stored the patient’s treatment will always be the same day after day. Well, what if it is stored incorrectly? This is a very real problem, computers can ensure consistency, but it is the job of clinical staff to ensure what is stored there is correct from the start. To this end there are many checking procedures that occur in a patient’s route to treatment in radiotherapy. This is the case if the treatment is paper based or electronic.

5.6

SummarySummary

Reading this chapter won’t make you an IT expert, but it should remove some of the fear of dealing with electronic issues in a radiotherapy department. The central message is that whilst IT has enabled radiotherapy to be immeasurably more sophisticated it is not always as turnkey as one would desire.

Chapter 6