Open alexwalkerepi opened 4 years ago
To summarise where to find definitions for each of these variables:
Exposure | Issue | |
---|---|---|
1 | Lung cancer | #32 |
2 | Haematological cancer | #32 |
3 | Other malignant cancer | #32 |
4 | Bone marrow transplant | #32 |
5 | Aplastic anaemia | #36 |
6 | Chemotherapy/radiotherapy | #32 |
7 | Dysplenia | #13 |
8 | Sickle cell disease | #13 |
9 | HIV | #36 |
10 | Organ transplant | #31 |
11 | Genetic conditions that increase risk of infections | #36 |
12 | Other immunosuppression | #36 |
13 | Oral steroids | #25 |
14 | Biologics | tbc |
15 | Other immunosuppressants (DMARDS) | #23 |
From @krishnanbhaskaran :
hi Helen,
Thanks for thinking so much about this.
From an epi perspective always good to have the finest breakdown so that we can then combine in a flexible way (esp as guidance may change).. but I guess it comes down to practicalities for the programmers? Some of the data quality of these items will be poor (e.g. hiv, chemo, in primary care records) – likely woeful sensitivity but should at least be specific. I don’t know of any decent source of cancer immunotherapy/targeted therapy, and suspect cancer site would be a poor proxy. A decent proportion of haematological may get? But again best we can do regarding likelihood of active treatment would probably be having a recent diagnosis.
Note that we’ll need a date for some of these, e.g. date of first mention of a cancer, in order to identify how long ago the cancer was, for (a) identifying cancers in the last X months/year and (b) investigating the role of cancer by recency of diagnosis more generally. With cancer as discussed I would also say pull the actual Read code so that we can map to site in future – we have a mapping from Read 2 to cancer site (encoded in icd).
I for one get muddled between the shielding criteria and the broader “should be particularly careful with social distancing” criteria, so in case others the same, the relevant lists are here:
shielding: https://digital.nhs.uk/coronavirus/shielded-patient-list
best wishes, Krishnan
from @StatsFizz
I agree that if possible we should keep the codelists separate with a view to doing more granular analyses in future. It’s really easy to combine codelists to define bigger conditions, but not really feasible to go the other way, once we’ve extracted the data!
However, I guess it depends on the immediate time investment. It may be more time efficient, in the short term, to extract the closest thing to what we want immediately and subsequently do more detailed codelists for more granular conditions. But the neatest way would be to start with the more granular versions. I guess that’s one for Alex and Caroline.
Also, I have a workflow question. I’m a bit unsure about whether the timing forms a part of the codelist definition or not. E.g. if we want “cancer in the last 5 years” and also “cancer ever”, does that get stored as two separate codelists? Or do we have a codelist plus a time definition which forms the data extract? Sorry, I know this is probably a dumb question for those of you used to this workflow…
Fizz
from @krishnanbhaskaran
Question of timing is important I think for things like cancer. The issue with specific variables like “cancer last 5y”, “cancer ever” is they are inflexible – so if we want to look at different time windows (6m, 1y, 10y?) we’ve lost the relevant info.. ideally for me it’s better to have date of first mention of cancer, from which any study-specific variable based on time windows from the index date can be derived.
So if separating haematological, lung and “other” out as suggested, we could have 5 variables in total:
date of first haematological malignancy (code as missing if none present)
Read code of first haematological malignancy (so that exact type can be determined later, if needed)
date of first lung cancer (code as missing if none present)
date of first other cancer (code as missing if none present)
Read code of first other cancer (so that site can be determined later, if needed)
Krishnan
Hi all, for most of the conditions Helen listed we’ve started separate issues for already, and returning a separate column for each codelist should be fine programmatically. I’ve summarised the issues that each one is in here, but I’m still working on the definitions for most of them. https://github.com/ebmdatalab/tpp-sql-notebook/issues/58#issuecomment-608335613
Regarding dates, at this point it might be simplest to say that the default is to take the date of the first code in each codelist, unless there are any specific exceptions. Then each analysis can further specify the definition as needed.
For cancer, it makes sense to me to take the date of the first code for each sub-list. But I don't know if that's a sensible generic rule across all conditions. Might there be other instances where our "X ever" "X in last 5 years" would be about any instance of "X" in the last 5 years, so we'd want the most recent date? Looking through Helen's list, I'm not sure if this applies to any of them though....
Yes I think with cancer anything after the first is hard to interpret (very hard to distinguish new cancers, secondaries, repeat codes still referring to the original cancer, etc.). There may be other types of condition that are more sporadic in nature where the most recent date would be of interest (though as you say, not obviously for the clinical conditions in Helen's shielding-based list [or indeed for the general high-risk clinical conditions which (pregnancy aside!) I think are all chronic in nature]).
From @hmcd by email: