4 level cross-classified model

[obesityboy]

I am analysing anthropometric data collected from pupils within schools, with this data collection varying between PCTs. This is a simple 3 level model: level 1 = pupil, level 2 = schools, level 3 = PCTs. I now want to incorporate measures assigned to Super Output Areas (SOAs). As SOAs are not embedded in schools or PCTs there is no neat hierarchical structure to the data so SOAs should not be included as another level within this structure. A cross-classified model allows SOAs to be included as a level but not to be embedded in either schools or PCTs. I have set up this cross-classified model with pupils as classification 1, SOA as classification 2, schools classification 3 and PCTs classification 4 (following the number of each) and then used MCMC to set it up as a cross-classified model. However, what I would like is to retain the 3 level model of pupils, schools and PCTs and then introduce SOAs as a cross-classified level. How can I assure I am doing this using MCMC and not forming a cross-classified model with all levels?

Many thanks for any help!

[Lydia]

When you ask for levels to be treated as cross classified, this will apply to all levels; there is no way to specify that the cross classification should apply to just certain pairs of levels. However, MLwiN will of course look at your actual data, and if there is no cross classification present in the data between certain pairs of levels, then treating those levels as cross classified is actually the same thing as treating them as hierarchical (provided that you have set up the IDs properly, as I'll describe in more detail in a minute).

When you do not treat levels as cross classified, identification of which higher level units a level 1 unit belongs to relies heavily on the arrangement of the data (which is why the data must be properly sorted). So suppose you have the following structure:

Code: Select all

ID       SOA      School

1         1          1
2         1          1
3         2          1
4         2          1
5         1          2
6         1          2
7         2          2
8         2          2

If you have not asked MLwiN to treat this as cross classified, then MLwiN will see 4 SOAs here: SOA 1 for School 1, SOA 2 for School 1, SOA 1 for School 2, and SOA 2 for School 2. This is because students from different SOAs cannot belong to the same school. This means that if we have sorted by students within SOAs within schools, then whenever we have a new school we must also have a new SOA. In fact, the way MLwiN works is that every time we have an SOA ID number that is different to the one on the line above, we have a new SOA - even if the ID number is the same as one we had earlier in the dataset. This is the case whether the two SOA IDs that are the same are in different schools or the same school. If they are in different schools then as we have already said, they could not refer to the same SOA since we have a hierarchical model. If they are in the same school, then they could refer to the same SOA as far as the model is concerned, but MLwiN will treat them as different because in this non-cross-classified mode it doesn't have the capability to compare the SOA IDs to those on any line except the one immediately before, and this is why it is important that the data are properly sorted (so that all the IDs that refer to the same SOA are on consecutive lines).

However if you ask MLwiN to treat this data as cross classified, MLwiN will see just 2 SOAs, SOA 1 and SOA 2. In this mode, MLwiN can compare SOA IDs on all different lines of the dataset and will take any IDs that are the same as referring to the same SOA. So the difference between asking to treat the data as cross classified and not asking to treat the data as cross classified is just the difference between asking MLwiN to treat the same ID code as always referring to the same SOA, and asking MLwiN to regard an ID code as referring to a new SOA every time the code is different to that on the line before (or the school code is different to that on the line before). All you are doing is making sure that the same u_j is applied to every individual belonging to the same SOA, instead of having a different u_j depending on what school the individual belongs to.

So what about a structure that has some cross classified elements and some hierarchical elements? Well, let's take an example:

Code: Select all

ID       SOA     School      PCT
1         1         1         1
2         1         1         1
3         2         1         1
4         2         1         1
5         1         2         1
6         1         2         1
7         3         2         1
8         3         2         1
9         1         3         2
10        1         3         2
11        3         3         2
12        3         3         2
13        2         4         2
14        2         4         2
15        3         4         2
16        3         4         2  

In this case, as for your data, students are nested within schools which are nested within PCTs, and students are nested within SOAs, while SOAs are cross classified with schools (and with PCTs). If we specify that MLwiN should treat the levels as cross classified, then it will see 3 SOAs, while if we do not ask for the levels to be treated as cross classified then it will see 8. So treating the levels as cross classified will give the correct behaviour for the SOAs. But what about the other levels, which form a hierarchical structure? Well, if we don't treat them as cross classified, MLwiN will see 16 students in 4 schools in 2 PCTs. We have School 1 in PCT 1, School 2 in PCT 1, School 3 in PCT 2, and School 4 in PCT 2. That's what we want. If we do treat them as cross classified, MLwiN will still see 16 students in 4 schools in 2 PCTs. We will still have School 1 (which is in PCT 1), School 2 (which is in PCT 1), School 3 (which is in PCT 2), and School 4 (which is in PCT 2). So treating the levels as cross classified doesn't make any difference to this hierarchical structure. There wasn't any cross classification between these levels in the data, so we don't see any when we treat them as cross classified.

One word of warning, coming back to the point about getting the numbering of the IDs right. Suppose we had exactly the same data as above, but we'd chosen a different numbering scheme for our school IDs:

Code: Select all

ID       SOA     School      PCT
1         1         1         1
2         1         1         1
3         2         1         1
4         2         1         1
5         1         2         1
6         1         2         1
7         3         2         1
8         3         2         1
9         1         1         2
10        1         1         2
11        3         1         2
12        3         1         2
13        2         2         2
14        2         2         2
15        3         2         2
16        3         2         2  

If we were not treating our data as cross classified, we would now have School 1 in PCT 1, School 2 in PCT 1, School 1 in PCT 2, and School 2 in PCT 2. This comes to the same thing as what we had before: School 1 in PCT 1, School 2 in PCT 1, School 3 in PCT 2, and School 4 in PCT 2. So this would be fine. However, if we are treating the levels as cross classified, then we would now have just 2 schools, School 1 and School 2, and schools would be cross classified with PCTs. Thus this choice of numbering scheme is perfectly adequate if we are not going to treat the levels as cross classified, but very wrong if we are going to treat them as cross classified. To avoid this problem, you need to make sure that whenever you have used the same ID number in any of the classifications it refers to the same unit of that classification. Here we have used the number 1 to refer to two different schools, and also the number 2 to refer to two different schools, which is why we get unwanted behaviour when we treat as cross classified.

[obesityboy]

Brilliant, thank you, particularly for the speed of your reply!