Version: 1.1
Date: 7th November 2002
See associated solutions.
Loosely based on a question from the 2002 examination paper for MC106 Software Engineering and Professional Practice. The question concerned the following scenario.
Charnwood NHS Health Trust has about 40 healthcare workers, based at regional clinics, who look after patients living in the local community. These workers are constantly on the move and often have little opportunity to keep in touch with the clinic whilst visiting their patients. To prepare for a visit, a worker will need access to the patient's records, and may also need to refer to NHS guidelines and healthcare manuals. They therefore tend to carry a large quantity of paper and books around with them. During a visit, the worker may record an assessment of the patient, log any treatments, and make further appointments. They may also decide to refer the patient to a specialist or consultant, in which case they make a note to request it. After the visit, the patient's records will be sent back to the local clinic where they are examined and approved. The Trust has around 9,000 patients receiving care and an individual worker may see up to 50 patients a week. Periodically, the Trust will decide to do a health survey. When this happens, questionnaire forms are printed out and distributed to all the healthcare workers, who fill them out during their visits. The forms are returned to the clinic along with the patient records and forwarded to the Trust's headquarters for anaylsis.
The Trust has decided to invest in a new computer system in order to improve the efficiency of communication between its healthcare workers, the clinics, and its headquarters. The idea is to supply each worker with a mobile computing device, probably a handheld PC such as the Compaq iPAQ 3660 or Hewlett Packard Journada 680. These typically have 8MB of storage once software has been installed. They cost £350-400, weigh about 300g, and run for about 2.5 hours continous usage before the battery needs to be recharged. A worker will be able to download patient records and associated information from a central repository held at the headquaters. This could be done by using a docking cradle attached to a PC at a local clinic (110kb/s). An average record might be 20kB of data. Manuals and other documents could easily require 2MB of storage. During a visit, the worker will make additions to the patient's records, notes, appointments as necessary on their handheld PC (amounting to 5-10 minutes usage). Periodically, the worker will synchonize their handheld PC with the central repository so that any additions or changes to the patient records are uploaded or downloaded, as appropriate. An e-mail facility should be included in the system so that workers can keep in touch and liase with other NHS departments.
Data accuracy is a key issue in any NHS system. Healthcare workers need to have correct and up-to-date information while they are visiting patients. A recent audit revealed about 5 errors per 100 patient records. This rate should at least be halved by designing a good graphical user interface for the handheld PCs to make data entry easy. Different workers may often be involved in the same case so any changes to patient records need to be passed on quickly, within a week at least. The frequency of data transfer could be further improved by allowing daily remote access to the central repository using a mobile phone with an infra-red link and a modem (28 kb/s). In this case, security would become an issue because mobile phone calls can be intercepted. 128 bit encryption should be used for all confidential data.
The Trust want the new system to deliver management information, for example, whether health targets are being met; and to reduce administration costs, which are currently 20% of budget, by at least 1/5. It should also make it quicker to mount health surveys. The questionnaires could be distributed as electronic forms and the data could be retrieved by uploading. Currently, it can take up to 3 weeks for the forms to be printed and distributed and a further 4 weeks for the data to be entered for analysis.
The healthcare workers are broadly enthusiastic about the new system. Their main concern is that it should be quick and easy to use, so that they have more time to spend with patients. They don't want to wait more than 10 minutes for a download, or have to recharge their handheld PC more than once a day. In the past they have also expressed a reluctance to carry laptops which could weight up to 2.5kg.
A local company called GoSoft, which specializes in mobile computing, has won the contract to supply the software and hardware for the new system at a price of £150,000. They have 12 months to develop the system although they plan to deliver it in 8 months.
The Trust has about 9000 patients. Current records should be immediately available on the system. Past records presumably need to be kept indefinitely so some archiving system may be necessary (ask).
Importance: high
Data accuracy is a key issue. The Trust cannot afford to have records which are inaccurate or not kept sufficiently up-to-date.
There is an obvious difficulty in measurement here: an audit will detect records which are inconsistent or obviously incomplete, but it will not detect all forms of error. To know that data is inaccurate we need to have something to compare. An alternative would be to have a mechanism for reporting errors and measure the rate at which they are reported.
Scale: Errors per 100 records.
Test: Audit of a sample.
Figure | Justification | |
Current | 5 | - |
Worst | 2.5 | - |
Plan | 1 | - |
Scale: Updates per week.
Figure | Justification | |
Worst | 1 | If careworkers synchronize with HQ once per week (see Clinic.Synchronization and Careworker.RemoteSync). |
Plan | 5 | If careworkers synchronize with HQ once per working day. |
This needs further elicitation. What statistics need to be collected? What analysis is to be done?
This includes the time to prepare and distribute questionnaires and for any data entry, but excludes time taken to actually conduct the survey.
Scale: Weeks.
Figure | Justification | |
Current | 7weeks | As stated. |
Worst | 2weeks | No time for printing. Distribution of questionnaires and collection of results could be done electronically during synchronization, one week for each (see Clinic.Synchronization and Careworker.RemoteSync). |
Plan | 2weeks | This would be a reasonable improvement over the current level. |
Scale: percent
Figure | Justification | |
Current | 20% | - |
Worst | 16% | Reduction of current level by 1/5. |
Plan | 16% | Is it feasible to aim any higher? Find out where the administration costs arise. |
Being able to synchronize the data held on a mobile device with that held at HQ is central to the operation of the system.
A careworker may need to access patient records several days in advance so that they can prepare for a visit. It may be convenient to have the records for the whole week in one go.
Scale: Thousand bits per second (kb/s).
Figure | Justification | |
Worst | 56kb/s | Speed of an ordinary telephone modem. Would expect 1MB of data (= 50 patient records) to be transfered in 5 minutes, dependent on network traffic. |
Plan | 110kb/s | Would expect 1MB of data to be transfered in 2.5 minutes. |
This needs further elicitation. Who does this? When does it happen? Must the records be approved before they go to HQ, or can they be marked as pending approval?
Each careworker will be issued with a mobile computing device. During a visit, the careworker should have access to all the information that they need (as if back in the clinic) and be able to make changes, notes, etc. as appropriate.
Presumably this will include symptoms that the patient displays and any diagnosis of these (ask what details are relevant).
Scale: Minutes on average per patient.
Figure | Justification | |
Worst | 10 | Data entry should not be a limiting factor when conducting a patient interview or visit. The careworker should not be spending time to fiddle with the computer rather than talking to the patient. |
Plan | 5 | Comparable to taking notes on paper. |
Scale: Seconds per question.
Scale: Mega-bytes (MB).
Figure | Justification | |
Worst | 3MB | Sufficient for 2MB of documents and manuals, plus room for 50 patient records at 20kb each (the caseload for 1 week). |
Plan | 8MB | To allow room for expansion. |
The mobile computer needs to be as light and easy to carry as possible. The careworkers do not want to be heavily encumbered as they travel about.
Scale: grammes (g).
Figure | Justification | |
Current | ?? | The weight of books and paper that a careworker typically carries now. |
Worst | 600g | The weight of a note-book computer? |
Plan | 300g | The weight of a pocket PC. |
A change made on one careworker's mobile device is not reflected on another's until the first has uploaded the change to HQ and the second has downloaded it.
Scale: Days.
Figure | Justification | |
Worst | 7 | As stated. |
Plan | 2 | Feasible if all careworkers synchronize their records with HQ daily. |
Scale: Number of times per day.
Figure | Justification | |
Worst | 1 | It may not be possible to recharge between visits. |
Plan | 1 | Reasonable to assume that device can be recharged overnight. |
Scale: Thousand bits per second (kb/s).
Figure | Justification | |
Worst | 28kb/s | The speed of a slow telephone modem. |
The level of encryption used is just one aspect of system security. In general it is very difficult to measure `security'. It may be wise to consult an expert to find out what other factors need to be considered.
Scale: Bits.
Figure | Justification | |
Worst | 128 | As stated. |
Plan | 128 | - |
Scale: Months.
Figure | Justification | |
Worst | 12month | As stated. |
Plan | 8month | To allow for slippage. |
Scale: Pounds.
Figure | Justification | |
Worst | £150,000 | In which case, the company has covered its overheads but has not made any profit. |
Plan | £110,000 | A reasonable margin of profit. |
This document was prepared using XML for Structured Requirements © University of Leicester 2002. Please send any comments and bug reports to S.Ambler@mcs.le.ac.uk.