Tag FAQ

The ‘Heads’ Report

A brief note if you are wondering what the ‘heads’ report is all about.

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

  • Match pending – contemporary CMP data not available. We are waiting for CMP data from this period to be submitted before we can run the match.
  • CMP number is invalid – this might be a typographical error
  • Confirm –  a new episode of illness: this means that a patient has more than one visit on the web portal. We need to be sure that the reported (SPOT)light visit is the first for that episode of illness
  • Unable to match (CMP number won’t match or not reported): here you have indicated the patient was admitted to a Case Mix Programme monitored unit but despite the tails matching we have been unable to find a match.
  • Record incomplete –  please check your DVR. This record appears to fall below the minimum dataset standard
  • Possible match – confirm via tails report. A match has been found but remains unconfirmed. Please confirm using the tails report.

As before, please complete columns Q and R (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’.

 

New codes for incorrect matches

We have introduced two new categories for responses to the tails matching process.

  • 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.

Won’t you be missing data on patients seen but not admitted?

This issue of missing the ‘non-admitted’ patients has been a massive source of anxiety for us. It is only relevant if you are following the ‘all referrals’ or ‘prospective data flow’ approach. In which case, then we have to completely depend on the quality of the initial data capture.

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.

Aaahhh … why is my DVR report so long?

First of all we are very pleased with the data quality for (SPOT)light. We expect around 2-3 errors per record (on average) and the average is around 0.5 (or 1 every two records). However, if you have a large number of records then this still translates into a large number of checks and a lot of work.

So to justify this then here are a few of the most common DVR checks with an explanation to justify why we are asking for your help:

  • Unusual spelling for first names: We will be unable to match to death certificates with the Office of National Statistics if the name spelling is odd. We expect some false positives with unusual names but the system should learn as we go along. Unfortunately a decent number of records across the entire study have first and last name reversed, and so despite the false positives this is still an important check.
  • Follow-up or recommended level of care missing. We’ll use this to classify patients  - especially important is the case where treatment limits are in place and we don’t want to consider that patient’s subsequent death outside of ICU as unanticipated.

I’ll add other explanations as they come up.

Please do get in contact if you have any queries.

Steve

Happy New Year … and a DVR explanation

Q: Why are you asking me to confirm a blank field?

A: Nearly all the fields on the web site have a ‘Not available’ checkbox attached, and when you have checked this then we will not be asking you for further information. However, if the field is blank and the box is unchecked then we need to be sure that form is complete and the data is truly unavailable.

The only other time we will ask is where there are also ‘drop-down’ lists since these do not have paired ‘Not available’ checkboxes.  The only way that we can be sure that the data in these fields is truly unavailable is by asking you to confirm this.

Heads’n'Tails matching

So the new Heads’n'Tails matching is ready. Hooray! I will be sending out your individual site sheets over the next few days. Please also have a look at the guidance notes.

What if the baseline CXR is clear?

Question: With the current screening regime, and the screening out if the CXR result is reported clear, you are quite likely to miss a large part of the viral pneumonias I would think. It may be conceivable that a patient indeed is quite unwell, but nonetheless is deemed to have a viral pathology, so antibiotics are stopped. So while he may need respiratory support, and be a candidate for the study in the spirit of the trial, we would have to filter him/her out. Was this intentional and pre-planned or just unavoidable?

Answer: So a clear CXR is not an exclusion (just something we might stratify differently). The CXR can be used to rule out a case if a different diagnosis is confirmed but to use a cliché (sorry) “absence of evidence isn’t …”. However, this leaves us with the sticky problem of exacerbation of COPD. To distinguish an exacerbation of COPD from pneumonia then it will be necessary for the CXR to have pneumonic changes. Sorry this is not 100% consistent but I think it gets at the spirit of the study.

 

Is a tracheostomy a clinical event in (SPOT)id?

Question: One of our SpotID patients had a percutaneous tracheostomy performed – I assume this is an “event” (on the daily CRF sheet) but cannot find a code for it within the coding system.

Answer: One the one hand I probably wouldn’t code this as an event on the ground that assuming it went well it shouldn’t be a cause of major physiological disturbance but if the patient was sedated and this affected the physiological observations then please use the code 1.1.1.x.x. which is Surgery/Respiratory/Upper Airway/x/x … (the ‘x’s meaning that there is no more specific code beyond this level).  If you have written a diagnosis in the free text then we’ll be fine with that.

Hourly urines

On the SpotID CRF the hourly urine output is requested.  For some patients the urine output is not measured hourly – so there may be a recording of, say, 300ml on the observation chart – but this will be for a few hours not one.  Do you want this figure added to the hourly urine box(es) on the CRF?

No.

The number should always be an hourly total. If hourly measurements were not available at the first hour after the start of the time period then please use the 2nd (or 3rd of 4th if necessary). If you are confident that the 300ml accurately summarises the 4 hour observation period then it would be acceptable to divide this by 4 and enter the answer (75). If you are not confident then better just to stick with 24 hour totals.

The platelet count was not available to calculate the Day 4 SOFA score. What should I do?

When you come to estimate the SOFA score on day 4 to decide if the patient should continue under follow-up then please follow the ‘last value carried forward’ principle. This means that you should use the last available value so if the platelet count was not measured on day 4 then you should use the value from day 3, if the day value is not available then the day 2 value and so on.

If the measurement has never been made then you will have to assume the value is normal and assign it a score of zero points.