regarding SUBTYPE:

this variable is already contained in tblLAB_RES. The reason it is collected seperately in CASCADE is that sometimes only the subtype, but no other information from tblLAB_RES is recorded. I would suggest to simply use a clearly distinguished SAMP_ID value like -1 and then leave all fields but SUBTYPE empty. This way the information is not recorded redundantly but in the same place as you'd expect it if there actually is resistance information.

regarding EDUCATION:

It may be hard to find a sensible consensus on the actual meaning of primary and secondary education as the school systems differ a lot between the countries, but depending on what this information is used for it doesn't matter too much.

regarding LTALIV_D:

Sara, is there any difference between the version proposed here and the additional variable L_ALIVE in the current HICDEP or did you just overlook it? If yes we should elaborate the description such that the difference becomes clear.

Hello!!!!

SUBTYPE. Seems a good solution.

EDUCATION. I agree. This is a difficult variable to define. We could wait for the survey results and see how education is recorded in the various cohorts.

LTALIV_D. You are right. It is the same as the additional variable L_ALIVE. Please ignore this.

I also think we need a further variable to indicate the date of administrative censoring, ie the date when the cohort was last updated.

Dear Sara

I was asked by CASCADE to look at their data for HICDEP mapping 3 - 4 years ago. Don't have the document at hand. Some of my suggestions now may be different from what I proposed back then, but it looks like that was never considered further.

In general terms: anything that does not seem applicable across a wide range of cohorts I would put in a tblBAS_CASCADE table. We are doing the same for EuroSIDA and also for the tblVIS table to capture more ad-hoc questions that don't really seem to have any use across a wider range of cohorts. This is solely done to make the general format as fixed as possible so that cohorts benefit the most from the format they have set up instead of having to redo this or make special versions for each collaboration. This way the cohort specific stuff can be limited to a few tables.

SEROHOW: We called this SEROCO_M in COHERE, never made it into the draft but has already been put to use in COHERE (list of codes may need to be expanded). Please see the COHERE SOP.

NEGHOW: I would suggest to keep this in LAB_VIRO on the HIV-1 test results, as for the specific info on source I would call this a tblBAS_CASCADE varibale unless other cohorts do have this in broadscale

RECART_D: RECART_Y is already there and should be considered together with the tblART. I'm not a big fan of the RECART_Y variable. This is more an internal consistency check of the cohort than something really used in collaboration. However RECART_D I would put into a tblBAS_CASCADE table if you really think that is useful.

SEROIL_Y: Primarily a CASCADE consistency check field right? : tblBAS_CASCADE

SUBTYPE: yes, tblRES

HCV_GEN: We should really extent the tblRES to also hold other types of vira, such as hepatitis, we did this for one of the COHERE mergers by adding a VIR_TYPE variable to the table. Should not be part of the LAB_VIRO EDUCATION: do we need a tblSOCIAL perhaps? I would say tblBAS_CASCADE

LTALIV_D: makes sense in to have in tblLTFU

CENS_D: This one I think I like Exactly what dates would go into this? Last date the cohort was updated or last date information was received on the specific patient? If the first - this is cohort meta data that currently doesn't have a spot in the HICDEP format (worth considering - although only one row per cohort or just a coversheet) - if the latter it should be in tblBAS.

/Jesper