Diagnosing Problems

If something unexpected happens, there are a number of possible causes:

• A program bug (fault),

• Operator misunderstanding,

• Hardware fault,

• Environmental problem,

• a virus, or

• Windows fault

 To track down cause of problems

This requires assistance of the operators, since they are the ones on the spot and able to see what happens.

 Incident log

Keep a piece of paper under the keyboard, noting the following points whenever the problem occurs;

• Time and date

• Operator

• Task (E.g. Dispensing a repeat, Deleting an item from an order, Printing a report)

• Characteristics of the task (external repeat, deleting a Revlon item from an order, Printing a report of 16 pages in A5)

• Any unusual operator actions ('edited the last item half way through dispensing this item', 'entered it wrong and had to back up to fix the sig' etc)

• Anything unusual seen ('strange error message' [what was the message?] )

• Any 'gut feelings' on the cause? These, from an experienced operator, are often correct.

• If appropriate, any printed output that shows a fault.

 Frequently, once there are four or five incidents, it is obvious what the common factor is... the problem only occurs when Freddy is dispensing (so watch what he does), or only occurs when an external repeat is edited part way though (so try one for a test patient and identify the exact keystrokes that let it be demonstrated on demand).

Even if you cannot see a common factor, we might... so email the incident log to us and we'll put a team onto it.

Once you have found the keystrokes that will demonstrate a problem, the problem is 90% solved, so email it to us. If the problem involves repeating an existing script, or some action where the existing data is likely to be significant, make a backup before reproducing it and noting the keystrokes, and send this with the keystrokes. This way we can test on your data in the same state as when you were able to reproduce the problem.

Examples of typical incidents from the past,  and their resolution

Duplicating script numbers

The script numbers were resetting to zero every week or so, resulting in the same numbers being used over again.

Incident log revealed that this only happened after a particular staff member had been on duty.

Action. The person was observed, and seen to select the 'Reset script number' button and reset it to zero. When asked why, they said that they wanted to cancel all Script Owings, which they thought was done by 'Reset script number'.

Problem solved; By telling the staff member not to reset the script number to zero.

Modem sometimes not connecting to wholesaler

Incident log showed that this occurred once a week, usually on Tuesdays.

Action Discussion with staff suggested that the only unusual characteristic of Tuesdays was that this was the day that modem communication with the bank for data exchange took place. Testing showed that after talking to the Bank,  the modem would not work for wholesaler order without the computer being shut down and restarted.

Problem solved. Computer was reset after bank connection.

Lost 'real cost' values after update

Some stock had its 'Real cost' figures reset to zero after the monthly update. Tests on the monthly update showed that this did not happen when it was tried again.

Incident log revealed that it was not happening after the monthly update as at first assumed, but rather happening to items that were manually added to a blank order.

Action Keystrokes were noted that would cause the problem to occur, and revealed a bug in the latest order module.

Problem solved The site was reverted by phone to the previous version, which immediately solved the problem, and the bug passed to the programmers for urgent correction.

 Wrong C&A label

Incident log showed that this happened if the wrong drug was selected, then changed to the correct drug.

Action Once suspected, this was confirmed by pharmacy staff trying test scripts, and the keystrokes required to reproduce it on demand sent to the support service.

Problem solved The program was modified to prevent the C&A label carrying over, and the fix was sent to all users.

 Scripts not being recorded

Some scripts were not being recorded.

Incident log showed that this mainly happening when the pharmacy was busy, and only on scripts entered by two operators, never a third operator.

Action Operators were observed, and seen to use <esc> to abandon a script. When asked why, this was to save recording time.

Problem solved Operators told that 'abandon' did not record.

Script Owings not being claimed when unticked.

Incident log revealed no obvious pattern, so the user set up a test;

On several items that were 'Script Owing' and so were correctly excluded from the last claim, they were left unticked until immediately before making up the next claim. At this point the user made a backup and labelled it 'before' then unticked the item (taking note of the exact sequence of keystrokes/mouse clicks used) so it should have been claimed at the next opportunity. They then made up the claim and had a look to see if the item was claimed.

• If it was not, they were to then make another backup, label it 'after' and send both to us with a note of the item. We could then set up our test machine with the 'before', follow their keystrokes to untick it, make up the claim and so be able to reproduce their problem and find the cause (which could have been something strange in their system, in the script, in something they were doing, or in the software, or a combination of them). Either way, if we could see it happening we could prevent it.

• If the item was NOT missed, they have confirmed that it does claim correctly, and could repeat this process as often as they want until they catch it going wrong or satisfy themselves that it is not wrong.