There are 5 patient identifiers shared between (SPOT)light and the CMP data: sex, date of birth, NHS number, postcode, and CMP number.

We take each emergency admission reported to the CMP, and look among all your (SPOT)light reports for a perfect (5 out of 5 fields) match. If we can’t find a perfect match then we’ll drop an identifier (e.g. postcode) and try for a 4/5 match, then put that identifer back and drop the next. Perfect matches get flagged as complete, 4/5 matches typically get flagged as presumed, and 3/5 will ask for your help confirming. We then check that the (SPOT)light visit has occurred before the ICU admission since visits after the admission are likely to be follow-ups and ineligible. If the ward visit was more than one week before the ICU admission we’ll also ask you to confirm that the admission was for another unrelated problem.Finally, we then repeat the whole cycle checking admissions to units in other hospitals in case the patient was transferred).

This means that each week the ‘matching procedure’ looks at more than half a million possible checks!

First of all, congratulations!

If you are receiving your ‘heads’ report then this means you have almost completed the entire matching process. We only send out the heads report when the vast majority of the matching has been completed.

This means that working from the Case Mix Programme data you now have told us about all eligible admissions from the ward to critical care during the study. In other words, all the tails are matched.

All that remains are the heads that didn’t match or that somehow don’t quite appear as expected. In other words these are cases reported on the (SPOT)light web portal that, on the basis of the information you have provided, should have matched.

Possibilities are

• MissingMRN – hospital number not provided
• MissingRecord – patient demographics exist but no visit was recorded
• VisitTiming - (SPOT)light visit occurred before your site was open, after it was closed or during a period of suspension – please let us know what you wish to do with these patients
• Eligibility – a visit has been generated for a patient who does not appear to be eligible according to the CMP data
• Matching – you have provided us either with a CMP admission number or indicated an admission to a CMP unit that we have been unable to match
• RetroProtocol – you have reported that you are following the ‘retrospective protocol’ (i.e. reporting all admissions not all referrals) yet a visit has been created for a patient who does not appear to have been admitted
• FollowupVisit – a REPEAT visit has been generated within one week of the first. It is likely that this is a follow-up in which case it is not eligible
• NewIllnessEpisode – a REPEAT visit has been generated more than one week after the first. Please confirm that this indicates a new episode of illness

As before, please complete columns new response code and notes and return the sheet to us. Most corrections will be via the web portal or the tails matching sheets.

Codes for the ‘Heads’ matching have been appended to the list in current use for ‘tails’.

• 9 … where we have matched the correct patient but the incorrect visit
• 10 … where we have matched the incorrect patient
• 11 … where you wish to propose a match that our system has not identified.

Each of these response codes requires some extra detail in the notes column.

If you are telling us that we have the right patient but the wrong visit (code 9) then please enter the correct visit date (in the DD/MM/20YY format e.g. 30/01/2012). Enter just the date and nothing else as we will import the date and use this to correct the match.

if you are telling us that we have the wrong patient (code 10) then please enter the correct hospital number as it appears on the (SPOT)light web portal. Enter just the date and nothing else, and again we will import and rematch using the new information.

Code 11 won’t make any sense until you are doing your heads (not tails) matching which we will provide once the tails are complete. This should be quick as the majority of the work will have been done during the tails matching. However there will be the odd patient who we deemed ineligible and therefore never chased. You will however have reported their admission to critical care, and when we do our final check they will appear as unmatched on the heads report. At this point please propose the correct match.

So a quick resumé of recent developments

• Accruals for (SPOT)light from January have been uploaded
• Heads’n'Tails matching is going well.  We are about to switch over from cycling through using the automated system to manually resolving outstanding differences where these are the only reason we can’t sign the data off.
• A new page has been added to the site report which shows your pattern of ward visits recorded in (SPOT)light by time of day, and day of week (example shown below). Drop me an email if you’d like to see your personal report!

Other updates
- Two bugs in the tails matching reports have been corrected. The issue with a silly error which reported an impossible number of days between (SPOT)light visit and ICU admission has gone. There were also occasions when the matching status was not updating to reflect your latest returns. This too is now fixed.
- I think I have now contacted all sites in person with a copy of your latest matching report. Let me know if you need an update. The last match was run Week 2 2012. The next one is planned for Week 5.
- The DVR has been edited in response to your feedback, and we have been having our first reports completed. Thanks
- … and finally I am away next week so if you have any queries then please drop a line to Rahi or get in contact after the 30th

All the best
Steve

If a month’s data can only be completed by ‘backfilling’ (i.e. pulling notes) then we will flag that as a time period where it is likely that the patients not admitted are a biased sample. Where there is little ‘backfilling’ then we can be more sure that we have not missed patients seen but not admitted.

We will not discard any data but this will permit us to run a sensitivity analysis and makes sure that our conclusions are not affected by months with different levels of data completeness.

- we have made the ‘impossible PaO2 for the reported FiO2′ check confirmable. It still remains impossible to have a PaO2 of 50 if you have only an FiO2 of 0.21 but if this is what is documented then please confirm this. We will of course remove these impossible values before using them in any analysis.

- the high pulse pressure check now will only fire if the difference between systolic and diastolic is >120mmHg rather than 100mmHg

- Isolated measurements of sodium will no longer trigger a request to check for missing values of urea and creatinine. Previously we had assumed that sodium would be most commonly measured with a laboratory U&E request and therefore it would be odd if creatinine was not reported. However since blood gas machines now frequently report sodium then we have removed the check.

                    ICNARC number   Days   Support

                    20110084    0   No, No, No, No, No
                    20110085    0   No, No, No, No, No, No, No
                    20110086    1   No, Yes, No

You’ll note that there are no patient identifiers other than the ICNARC CMP number, and that there are only 3 column headings even though many more than 3 columns are in use.

We’ll work through the other systems and then prepare detailed guidance. Please beware however that may of the automatic export options on the systems include patient identifiers which must be stripped out before sending to us. The only identifier we need (and can accept) is the ICNARC Case Mix Programme number.

Anyhow, I have tried to put together a work around but let me know if things don’t seem quite right.

Steve

March 31 is less than 3 months away hence the countdown. I’ll try and post once a week about progress, and turn around submitted matching reports or DVR queries on a weekly basis.

I had hoped to send a mail shot out alerting everyone to the DVR which is now live, but I  started preparing the first pages of the site report and this took longer than I had planned.

The DVR mail shot should now go out on Monday.  This is not altogether bad as there is one annoying bug on the website at the moment which reports errors (accurately) but does not indicate which field is causing the problem.  The IT team have done a great job in sorting this one out, but it seemed sensible not to push everyone to look at the DVR before this was fixed.

Happy New Year! And I hope you are looking forward to the (SPOT)light results as much as I am!