Tutorials › Regression Analysis (Undergraduate) › Building Cluster Identifiers from Study Design

Grouped Data and Dependence Awareness · Tutorial 868 of 991

Building Cluster Identifiers from Study Design

Learn to build and audit identifiers from the study design, keeping clusters, observational units, and repeated occasions distinct.

Advanced 10 min read

What You'll Learn

  • Distinguish an observational unit from a cluster and from a repeated measurement occasion.
  • Use sampling, assignment, and data-collection records to choose the identifier for the intended grouping.
  • Construct identifiers that remain unique when local codes are reused at different sites.
  • Check cluster membership, repeated-record keys, and expected counts against the design.
  • Recognize why a technically consistent ID can still represent the wrong grouping.

Why Identifiers Must Come From the Design

A regression data set often has one row per measurement, but a row alone does not tell you which records belong together. Several people may come from the same clinic, or one person may contribute measurements at several visits. Before any analysis that depends on how observations were collected, the records need identifiers that preserve those relationships.

An identifier is not simply a convenient label added to a spreadsheet. It is a way to encode a relationship described by the study design or data-collection process. To build one correctly, first establish what one row represents, which units were sampled or assigned together, and whether a unit appears in more than one row. Then verify that the resulting labels agree with the original records.

Definition: An observational unit is the unit about which one recorded outcome or measurement is made. A cluster, for the grouping being represented, is a set of observational units linked by the sampling, assignment, or data-collection design. A cluster identifier is a categorical label that assigns each relevant row to its intended cluster. A repeated-measure identifier identifies the unit measured more than once; an occasion or time label distinguishes that unit's separate measurements.

These roles can involve different levels of the data. If patients are measured at multiple visits, a row may represent one patient-visit measurement, the patient identifier links visits from the same person, and a clinic identifier may mark the clinic where the patient was enrolled. The row, patient, and clinic are not interchangeable. Which grouping is relevant depends on the question about the study's design; there is not one universally correct cluster column for every analysis.

Building Identifiers From Study Records

Useful sources include a sampling frame, enrollment roster, randomization or assignment log, visit schedule, and data-entry audit trail. A person's name or a row number is rarely enough: names can be duplicated or changed, and row order can change when records are sorted. Prefer stable codes from the design records, and combine them when a code is only unique within a site or another larger unit.

A practical construction starts by writing down the intended record structure. For each row, answer: What was measured? Which person, object, or unit supplied the measurement? What sampling or assignment group is relevant? If the same unit was measured repeatedly, what identifies its occasion? These questions suggest distinct columns rather than one overloaded ID.

1
Define the row.
State in words what one row represents, such as one patient's blood-pressure measurement at one visit.
2
Trace the design relationship.
Use the sampling, assignment, or collection records to determine which rows share the grouping of interest.
3
Create separate keys.
Keep cluster, observational-unit, and occasion identifiers in separate fields when they describe different relationships. Combine parent and local codes if a local code is not globally unique.
4
Audit the mapping.
Compare the data extract with the source records, check expected counts and uniqueness, and investigate every missing or conflicting assignment.

Worked Example: Assigning Clinic Cluster IDs

Suppose a hypothetical study enrolls two patients at each of three clinics. The enrollment register records each patient's clinic code and a patient code that is unique across the study. Each patient contributes one measurement. Here the observational unit is the patient, and the grouping to record is the clinic.

Patient codeClinic in registerCluster ID in data
P101NorthCL01
P102NorthCL01
P201CentralCL02
P202CentralCL02
P301SouthCL03
P302SouthCL03

The mapping is North to CL01, Central to CL02, and South to CL03. It gives six patient rows and three distinct clinic IDs, with two rows under each ID. These counts agree with the enrollment design: \(3 \times 2 = 6\) patients. The patient code identifies the observational unit; the cluster ID identifies the clinic group. A patient code should not be substituted for the clinic ID, because each patient would then appear to define a different group.

The codes CL01–CL03 are labels, not measurements. In particular, their numerical suffixes do not express distance, order, or size. The important property is that all patients from the same clinic receive the same clinic label and patients from different clinics receive different labels.

Repeated Measurements Need More Than One Identifier

With repeated measurements, multiple rows can belong to one observational unit. A unit ID identifies whose measurements they are; an occasion ID tells which measurement is represented by a row. If the unit is also part of a larger cluster, retain that cluster ID as another field. The combination of unit and occasion should identify a particular measurement record uniquely, unless the design explicitly permits more than one record at that occasion.

Worked Example: Linking Patients Across Visits

In a hypothetical clinic study, two clinics each enroll two patients, and each patient is measured at visits 1, 2, and 3. There are \(2 \times 2 = 4\) patients and \(4 \times 3 = 12\) patient-visit records. The row represents one measurement at one visit. Clinic is the cluster identifier for this example, patient is the repeated-measure unit, and visit is the occasion.

Clinic IDPatient IDVisitRecord key
CL01CL01-P011CL01-P01-V1
CL01CL01-P012CL01-P01-V2
CL01CL01-P013CL01-P01-V3
CL01CL01-P021CL01-P02-V1
CL01CL01-P022CL01-P02-V2
CL01CL01-P023CL01-P02-V3
CL02CL02-P011CL02-P01-V1
CL02CL02-P012CL02-P01-V2
CL02CL02-P013CL02-P01-V3
CL02CL02-P021CL02-P02-V1
CL02CL02-P022CL02-P02-V2
CL02CL02-P023CL02-P02-V3

For each patient, there are three rows with the same patient ID and visits 1, 2, and 3. There are four unique patient IDs, and each patient belongs to one of the two clinics. The record key is formed by joining patient and visit information; including the clinic in this key makes the components easy to inspect. Across all 12 rows, no patient-visit pair occurs twice. This is the expected uniqueness check for this design.

The patient code includes the clinic code because local patient numbers might otherwise be reused. If both clinics used the local code P01, the value P01 alone would not uniquely identify a person across the study. The combined labels CL01-P01 and CL02-P01 avoid that collision. If the study's source system already supplies globally unique patient codes, adding the clinic prefix is optional for uniqueness, though the clinic still belongs in its own field.

Check the Hierarchy and the Mapping

A study can have more than one meaningful level. For example, students may be recorded within classrooms, and classrooms within schools. If the intended group is the school, use a school identifier. If the intended group is the classroom, a classroom code that is only unique within a school must be combined with its school code. The identifiers should preserve the hierarchy rather than flattening distinct classrooms that happen to share a local number.

Worked Example: Making Classroom Codes Unique

A hypothetical survey records one outcome for each student in two schools. Each school has classrooms numbered 1 and 2, and each classroom has two students. Thus there are \(2 \times 2 = 4\) classrooms and \(4 \times 2 = 8\) student rows. Suppose the grouping of interest is classroom. The source roster provides the school, classroom number, and a student number unique within its classroom.

SchoolLocal classroomStudentClassroom ID
S0111S01-C1
S0112S01-C1
S0121S01-C2
S0122S01-C2
S0211S02-C1
S0212S02-C1
S0221S02-C2
S0222S02-C2

There are four distinct classroom IDs, with two student rows for each, for a total of eight rows. Using only the local classroom number would incorrectly combine S01 classroom 1 with S02 classroom 1. The school prefix prevents that collision. If the grouping of interest were school instead, the school column would be the cluster identifier, with two distinct values and four student rows under each.

Why the mapping check works: Let \(g(r)\) be the intended cluster label for row \(r\), derived from the design records. Every row must have one defined label. If two rows represent units in the same intended cluster, they must receive the same label; if they represent units in different intended clusters, they must receive different labels. Checking these two conditions against the source records tests whether the encoded grouping preserves the design. It does not, by itself, establish that the chosen grouping is the right one for every analysis.

Common Identifier Errors

A clean-looking ID column can still be wrong. The most useful checks compare the data extract with the source design, rather than relying only on whether the labels look tidy.

  • Using the row number as a cluster ID. Row numbers identify positions in one file, not design groups. Sorting or appending data may change them. Use a stable code linked to the sampling or collection records.
  • Using a local code without its parent. Classroom 1 can occur in several schools; patient 01 can occur in several clinics. Combine the local code with the parent code when needed to make it unique.
  • Confusing the measured unit with its cluster. In a clinic study, a patient ID does not tell which clinic enrolled that patient. Keep both fields when both relationships matter.
  • Treating each repeated row as a new person. Separate visit rows from the same patient need the same patient ID and different occasion labels.
  • Trusting a label despite conflicting records. If a roster assigns one patient to CL01 but the data extract assigns that patient to CL02, do not silently choose one. Investigate the source records and document how the discrepancy is resolved.
  • Assuming that successful coding proves the design choice. A consistent school ID cannot answer whether school or classroom is the grouping relevant to a particular analysis. The intended relationship must be stated first.

A final audit should count distinct IDs and compare them with design records, check for missing cluster or unit labels, and look for impossible or duplicated combinations. For repeated measurements, verify that each expected unit-occasion combination appears the intended number of times. For nested identifiers, confirm that each lower-level unit maps to the correct parent. These checks catch data-management errors before they are mistaken for features of the study.

Check Your Understanding

Use the study design, not the row order, to reason through each question.

  1. A study enrolls five patients at each of four clinics, with one measurement per patient. What does one row represent, and which fields would distinguish patient from clinic?
  2. Two hospitals both use the local patient number 17. How can the data manager construct a patient identifier that is unique across both hospitals?
  3. Each of 30 people is measured at baseline and at two follow-up visits. What fields identify the person and distinguish the three measurement occasions?
  4. Why would classroom number alone be an unsafe identifier if every school numbers its own classrooms starting at 1?
  5. A patient has two rows labeled with the same patient ID and the same visit, although the design allows one measurement per patient at each visit. What should be checked before analysis?