[Revised Mar 02]
There are five causes of data disappearing, changing unexpectedly, or reverting to what it was before;
In order of frequency they are;
1. The data has not in fact changed, just appears to have done so, or
2. A power cut (or deliberate switch off) has occurred and some data has been lost, or
3. A staff member has changed the data, either accidentally or deliberately, or
4. An old backup has been 'restored', restoring the records to a previous state, or
5. A computer fault of some kind has occurred.
These causes have different characteristics.
The examples given below are actual examples from our help-desk, all of which were initially reported as spontaneous data change.
1. Data has not in fact changed.
What was done was correct, but is not what the operator thought they were doing. Examples below should be considered as they are a typical selection of many thousands of possible mistakes;
Example 1. Caller says, "Help! I did a script for 'Angus McDonald' and it has disappeared!" On investigation, patient was actually dispensed as 'Angus MacDonald' and is still there.
Closely related is 'McDonald Angus" entered, where the surname appears to be 'Angus' and the first name 'McDonald'. A variation on this is where there are two records for Angus, a comment is put on one record and later appears to have disappeared when the user looks at the other record.
Example 2. Caller reported that, "Patient name was edited from 'Freddy' to 'Johnny' but has spontaneously reverted...". On investigation the operator chose to <escape> and abandon after editing rather than record.
Example 3. "Stock of Benadryl 100ml was corrected but has reverted to old figure...". The item changed was actually Benadryl 125ml and it is the 100ml card that is being viewed now.
Example 4 Caller reports, "When I untick the 'script owing' in bulk, they reappear later as ticked...". The caller was actually resetting the script number, misunderstanding the meaning of the function.
This type of problem is responsible for most cases of apparently reverted data.
2. Power cut
A power cut (or deliberate turning off of the power without shutting down) in the middle of a job, can cause loss of some data, typically a small block of scripts. When missing numbers are re-used, the data will be different and so appear to have changed spontaneously. 'RxOne' is much more robust in handling power cuts than other Windows programs, but the last few scripts could be vulnerable... check the last few after a power cut.
3. Manual change to data.
A common cause of changed data is that someone has changed it, either accidentally or intentionally. Look in the audit trail to see if any change is recorded, as some modifications to data are recorded there.
Common examples are;
Repricing. If editing the drug, quantity or patient category, or something else that will affect pricing and the user <enters> down through all the fields to 'Finish' it will be repriced under new conditions (as is usually wanted), however someone looking at this script later can think that the data has spontaneously changed, or that the price is wrong especially if the patient has become exempt meanwhile and a previously non-exempt script has been repriced under exempt rules.
Markup and dispensing fee changes. A pricing policy decision is made, and the markup and dispensing fee changed. Another staff member sees a 'wrong' price and changes it back. The first person sees that the prices have 'spontaneously' reverted to the old prices.
Sigs One person adds their own favourite or changes the meaning of a 'sig'. Then a different staff member uses it and finds that it has the 'wrong' meaning, so changes it again. They play tag with it for some time, both becoming increasingly annoyed that the computer is spontaneously forgetting their changes.
Drugs moved to wrong patient Someone finds that scripts have been dispensed for the wrong patient, and moves them. But, either they move them to a different wrong person, or the person turns out not to be wrong after all.
Shrinkage including shoplifting and staff theft. The SoH figures will not match the physical stock. This is the usual cause of large and consistent discrepancies between the expected and actual SoH. Management is often reluctant to believe it especially if very large losses are appearing or the items concerned are not accessible to customers. Most businesses lose from 1% to 2% of turnover; in a busy shop this is 20 items per day, 100/week, 400/month which makes the computer appear unreliable. But it is doing its job by revealing the extent of the losses. Experience has shown that there is NO level of shrinkage so high as to be impossible.
Incoming stock has arrived. Eg, there are 3 in stock, 2 are sold, and 2 come in. The SoH figure was 3 before the sale and correctly remains at 3 despite an audit trail entry showing that 2 were sold.
** MTD will increment but SoH remain unchanged.
Returned stock. Eg, There are 3 in stock, 2 are sold, but later returned. The SoH correctly remain at `3' despite an audit trail entry showing 2 were sold, and dockets showing 2 sold. The audit trail entry for the items being returned may be in a different machine or a different day.
** Both SoH & MTD will stay the same.
Stocktaking. Stocktaking may have been done, so that the item was correctly taken off the card and later the SoH put back to what it was because an error was detected in the stock levels. E.g. there are 3 in stock, 1 is sold reducing the SoH to 2, but them a rolling stocktake detects that the stock is really 3 (it was really 4 before the sale) and changes it back.
** MTD will increment but SoH remain unchanged.
SALES; Two different items. The stock level of one item might be checked and a sale done for a different item. Or the correct item might be sold but the `before' and `after' items checked are different. This is easy to do and surprisingly common especially on items with several sizes or colours.
** Both SoH & MTD could be apparently wrong.
DEBTORS: Two different debtors. The transactions were for one debtor and the check is being made on another with a similar name. Or sometimes the one debtor has two different accounts with slightly different codes.
** Transactions could be apparently wrong.
Wrong sticker. An item has the wrong sticker attached so that one colour/size is sold and the sale credited to another. This is most common during early setup period.
** Both SoH & MTD could be apparently wrong.
Wrong PLU/PDE code. An item has another item's PLU number on its stock card and sticker, so that one item is sold and the sale credited to another. The effects of this persist until the last of the incorrectly labelled stock items has been sold. This is most common during the initial setup period.
** Both SoH & MTD are affected.
Infinite possibilities. There are an infinite number of these situations, and they are very common cause of reported computer 'fault'. It is often impossible to know for sure what has been done, but in those cases where it has been possible to trace the operator actions this kind of event accounts around 90% of 'spontaneously reverted data'. Do not lightly dismiss this situation, and do not think, "No one else but me would know how to change this..." ... in Windows, most people can handle any function.
4. Restoring from backup
This cause is less common, but still common enough to cause problems. 'Restoring' restores everything to the state that existed at time of the backup. Although 'RxOne' has roll forward data recovery and is able to recover for itself scripts dispensed since the backup was made (including the stock-on-hand changes), it does not re-enter changes to Sigs, Drugs, Doctors or other less important changes so these are lost. If someone adds a new 'sig' code, then after they are off work someone else crashes the database and restores with the roll forward data recovery, all scripts will be there but the change to the 'sig' will be lost, apparently without cause. This kind of problem is moderately common during the first few weeks of a new system when many changes are being made and everyone is inexperienced on the computer.
The situations above are classics described by; "The computer did what I asked, not what I wanted.".
5. Slave switched to `Master' on its switchboard. This causes the Slave to process its own sales instead of transferring them to the real Master. The Slave/Master switch is necessary to allow operation to continue in event of a major malfunction on the Master, but a Slave should never be switched to a Master for any other reason.
** Both SoH and MTD remain unchanged on real Master (and on phantom Master after switching back.).
6. Computer error.
Although power surges, computer hardware faults etc can cause corrupted data it is rare in Windows programs for these to reach the user. There are internal checks in the Access database structure which will detect corruption on startup and advise, "Database corrupt .. restore from backup." In addition, 'RxOne' itself has double redundancy checks on critical data such as the links between the scripts and the patient. As a cause of spontaneously reverted data, computer hardware fault is very rare. But if all other possibilities have been checked, try 'repairing' the DB. If that fails try 'compacting' and if even that fails to make a script edit-able, reenter the item with notes in case of later audit.
DIAGNOSIS
Illogical changes. Any truly spontaneous change will illogical, such as a Patient Name of "X4b%7/we9". Or a change of patient instruction from "Take TWO at night" to a patient instruction of "Take Mrs Smith 123 Brown St". Since the computer does not understand the data itself, any text is as reasonable as any other to the computer.
'Reasonable' changes where the new data could be correct, are highly characteristic of human error. Ie, change of a patient instruction from "Take one tablet three times daily" to another reasonable instruction such as "Take TWO at night".
General Comment.
Every effort should be made to impress on staff the need for care, as garbage in = garbage out'. However, especially on PoS it is not possible for retail sales staff to achieve complete accuracy under the difficult working conditions of a retail shop, so the program is designed to cope with a significant level of operator error while still producing good results.
Retrospectively it is not possible to explain discrepancies as there is no way of knowing with certainty who has done what, when, and why. Apart from the above known conditions there may well be other similar circumstances that can cause unexpected figures. Because of this unexpected SoH or MTD levels should not be taken to indicate transfer problems unless they can be reproduced under known conditions; the distributors/agents will not attempt to explaining discrepancies without a set of steps which, if followed, will demonstrate that a fault exists. Use an incident log to isolate these steps for investigation.
Related topics