FAQ - Electronic AuditResults Problems
Q: Renal check looks rather complicated and can't make out head or tail. Does this mean, microalbuminuria (MA) or dipstick protein or both? Answer: Yes it's certainly complicated. The structure is based on the NICE guidelines for renal care of diabetes - implementing their audit criteria. They introduce this idea of high & low risk albumin excretion. So the analysis is as follows. 1) Take all diabetes - and remove those for whom renal assessment is inappropriate i.e. excluding end stage renal failure, dialysis & transplants as we already know their status and Type 1 <5 yrs from diagnosis (local guideline) to get the target population for renal assessment 2) Then establish the population of known higher risk (ACR >2.5 or 3.5 i.e. microalbuminuria and/or frank proteinuria). This population has to be identified to do the ACE & BP audit on them. 3) This leaves those who have not been assessed or have been assessed as lower risk. We then assess if this group has had their risk assessed appropriately. This is complicated because there are several ways in which a practice may assess risk. ACR, urine albumin assay, microalbuminuria test strips OR macroalbuminuria test strips followed by one of previous list if negative. If the latter test is positive then there is no need for one of the previous because high risk status will have been established. 4) This will give the newly diagnosed high risk group which is added to 2) for the subsequent analysis of the high risk group. (I had hoped that the comments on the sheet would make this clear!) Q: How would I know how many people with dipstick negative protein had microalbuminuria (MA) checked? Answer: Unfortunately it is not possible to work this out from the data because the analysis does not deal with dipstick negative urine separately as there is no need to so in order to arrive at the NICE audit criteria. You get the outcome i.e. the number who have been appropriately assessed. The nearest you can get to it is to subtract the number newly confirmed high risk from the number adequately assessed. This will give the number who were dipstick negative who had MA checked whose result were below 2.3/3.5. The newly confirmed will comprise those who were dipstick positive and so did not have MA done and those who were dipstick negative but were found high risk on MA testing. You would have to do an EMIS search to find the number dipstick positive and so you would then be able to find the number who had MA tested. Q: Are patients on alternatives to aspirin (Clopidogrel & Dipyridamole) included in the PCAG CHD Queries? Answer: The short answer is YES and we deal with contraindications to them! Longer answer is: 1) In the reported data on the PCAG sheet the alternatives are not dealt with, as the PCAG audit only deals with aspirin. However; 2) as people were inevitably going to say (when challenged as to why not all patients on aspirin) 'but some are on other antiplatelet drugs!' I have included this on the main CHD data sheet returned to practices. As follows: Rows 136-139 on the data sheet of the results file deal with - Contraindication (CI) or adverse reaction (AR) to aspirin, those with CI/AR to aspirin AND other antiplatelet agents, those with CI/AR to aspirin who are taking an alternative antiplatelet and those who are not on aspirin but are taking an alternative. Drugs covered are Clopidogrel & Dipyridamole and ticlodipine. Practices can then see how many of those not on aspirin and no CI/AR are taking an alternative Q: We have 123% for BMI advice on the PCAG spreadsheet. Any ideas? Answer: This can happen if people have more than one BMI entry on the same day, as they would be counted twice, but having been to a practice I have noticed this is not the case! Basically its an EMIS-Miquest interpreter bug and I have informed them about it. Two queries count the patients with BMI >25 in different ways
. and come up with different answers - one matching an EMIS search, the other not. Can not be sorted until EMIS correct the bug
.
Q: In the NSF data sheet: the percentage of Recent MI patients on Betablockers in the last year has come up as 167% - any ideas? Answer: Mmm I thought I'd eliminated this error but she's found the one file I appear to have missed! Well spotted - its good to keep feeding back these quirks so we can constantly refine the query set. This problem arises because for a couple of patients a beta blocker prescription has been issued more than once on the same day or two different beta blockers have been issued on the same day. This normally shouldn't happen but sometimes the wrong script gets issued and then the correct one is done without removing the old one or a patient ends up requesting the same drug from 2 different people in the practice on the same day or some such mix up. Anyway I thought I'd re-jigged the files only to pick up one such prescription but I missed the file that generates this data - corrected in future. Also the numbers here are small so the % error looks large when in fact the above problem can only have occurred in 2 patients. I suspect the true figure should be 67% not 167%
Q: The results are showing 127% of CHD had their smoking status recorded in the last year! Is this an inputting error, an interpreting error, a calculation error or what?
Answer: I must admit that this data is odd - almost certainly not a query logic or spreadsheet error because all other practices have used the same system & get sensible results. . Hi, I have been to the practice now and realised its a coding error. When they transferred from another system, their smoking data for non-smokers got transferred as both Cigarette Smokers with a consumption value of 0 (thus contradictory to the Read Coding) and as a Current Non smoker. Both of these codes were dated on the same day and thus some patients were effectively coded as non-smokers who consumed (no) cigarettes. The query could not decide if they were smokers or non-smokers and so counted some patients twice!
Q: A Practice had run an audit and came up with a much lower number than they expected. I checked whether they were all dual-coded and they were. We ran an EMIS query, using dual-coding and got a much higher number (400 compared to 200). I did notice they were using an old query set from January 2002, so explained that this would change the result. However, when we ran an EMIS query for dual-coding, just looking at the dates up to January 2002, there was still a discrepancy of 100 patients. This has stumped me, as surely they should be the same. Any thoughts? Answer: If they have added the dual codes with recent dates e.g. G3 codes with dates in the last few weeks and then run an old query set it will not pick up the patients with recent dates. I guess this accounts for most of the discrepancy. There are also some other catches - if they have dual coded with codes where the date entered is 'Unknown', the system defaults this date to somewhere in the 1800's! and so the query will not pick them up either (the query date range runs for the last 75 years). I guess this would account for most of the problems. Suggest the practice re-run with a new query set and does the housekeeping set too, in order to identify the missed ones.
Q: We have about 250 patients on our CHD register (and did have on 23/11/00), so why were they not included in the audit? I have checked the code - they are coded G3 but not all of them have it as a significant active problem. Is that the cause?
Answer: The reason is almost certainly because not all the patients are dual-coded, as described on the website under audit theory. They need to have G3 AND Either G33 or G30, or one of its sub-codes, to be counted. You could run a housekeeping query to identify the wrongly coded patients.
P.S. its nothing to do with active problem list- Miquest will work wherever the codes are in the record
Q: I have been asked by to re-run the data collection for a specific date. Is it possible to set the Miquest to collect data for a date in the past? If so is it easy to re-program or shall we just make the practice look good?
Answer: There is a big problem with running retrospective searches. One is the difficulty of establishing the previous population from the patients who have left or died, and the new patients, as well as the diagnosis at the time. The other is that retrospectively added data will be included and so not give a picture of the true situation at the time. Difficult to do accurately and our Miquest set won't do it. Anyway - who cares? What's important is the care we're providing now
.
Q. I am confused about the Drugs section of the data sheet in the results file. It appears that a greater number of post-MI patients with LV dysfunction than the overall amount of patients with LV dysfunction?
Answer: The "Number of patients confirmed with LV dysfunction" is concerned with the whole population, but it only looks for the 33BA Read code - this is a positive ECHO test result. However, the "Number of MI patients with LV dysfunction" looks for both the 33BA and the G581 (confirmed LVSD) codes.
The reasoning is historic!! When the CHD audit was set up the only code for LVSD was G581. This is entitled confirmed LVSD and is really based on the GPs opinion, because it is not based on a direct investigation (e.g. an ECHO). Therefore when the 33BA code came in, we decided that this code would be more accurate and so placed it on the template. However, in order to keep the audit consistent, we had to keep the G581 code in the PCAG audit in order to be able to compare to the previous data.
The way round it is that the G581 coded patients need to be rechecked and the 33BA code added if necessary. Really only the patients coded with 33BA are accurate, but it would of made practice's results plummet if he had removed the G581 from the audit.
Q. I am confused because sections 3 & 4 of the NSF data sheet do not seem to tally with the overall PCAG sheet. I seem to be getting a lot of zeros in these sections of the NSF sheet.
Answer: They do tally! The NSF criteria are different from the PCAG criteria! i.e. looking at slightly different things. The explanation is as follows
|