Data Element Specifications (Units, Precision, Dimensionality)

Why this matters

A numeric data element is not fully defined until its unit, precision, and dimensionality are explicit. Without these, ranges are meaningless, conversions are guesswork, and analysis becomes fragile. Clear specifications also let you set sensible entry checks, automate conversions, and maintain traceability during reviews, locks, and inspections.

Core concepts & definitions

• Dimensionality The physical nature of what is measured (length, mass, temperature, pressure, time, rate, count, or a concentration such as mass per volume or amount of substance per volume). Declaring it prevents mixing unlike quantities (for example, glucose in mg/dL, a mass per volume, with glucose in mmol/L, an amount of substance per volume).

• Unit The scale used to express the value (for example, centimeter, kilogram, millimeter of mercury). Take units from a controlled list, never free text. UCUM (Unified Code for Units of Measure) is the widely used standard: each unit has one unambiguous code (for example, “mm[Hg]” for millimeter of mercury and “Cel” for degree Celsius). Choose one canonical unit for storage and analysis. When sources report in different units (for example, local labs), store the recorded value and recorded unit exactly as reported, plus a converted value in the canonical unit that the system derives centrally; sites never convert by hand.

• Precision The smallest reportable increment your system accepts or displays (for example, one decimal place, or a step size of 0.1). Set collection precision from the device’s step size or the precision the source reports. Precision must be paired with a rounding rule (for example, round half up) for values the system derives, such as converted or averaged results. Rounding for analysis and reporting is a separate decision, made by the biostatistician in the statistical analysis plan (SAP).

• Allowable range Plausible lower and upper bounds considering human physiology and the measuring device. Decide whether a check is hard (blocks save) or soft (warns, allows override with reason). Keep hard limits for impossible values only; a true but extreme result must still be enterable so the data match the source.

• Collection conditions Context needed to interpret the value (for example, posture for blood pressure, fasting state for glucose, device model and cuff size, body side, time since dose). These are data—not just manual notes.

• Mixed-unit governance If sites use different units, capture (1) the recorded value, (2) the recorded unit (from a controlled list), (3) the converted value (canonical unit), and (4) the conversion algorithm name and version. The system converts centrally with that algorithm; sites never convert by hand. Retain the provenance of every conversion.

• Null flavors / not-done For required measures, include “not done” with a reason (for example, contraindicated, subject refused, device unavailable). “Null flavor” is the HL7 term for such a coded reason why a value is missing; CDASH collects it as a status field (NOT DONE) plus a reason field.

The process, step‑by‑step

1. Define the concept and dimensionality Be precise about what the number represents (for example, “infant crown‑to‑heel length” → dimensionality: length).

2. Choose the canonical unit Use one storage (canonical) unit across the study. If sources report in different units (for example, local labs), collect the value + recorded unit as reported and plan a central conversion (governed, with versioning); sites never convert by hand. Show a single fixed unit at entry only when every source reports in that unit (for example, a study‑supplied device).

3. Set precision and rounding Specify the accepted increment (for example, 0.1 centimeter) and the rounding rule (for example, round half up). Distinguish stored precision from display precision if they differ.

4. Declare allowable ranges and check severity Define physiologic/device bounds and whether out‑of‑range triggers a soft warning or a hard stop. Document justification briefly.

5. Capture collection conditions Add all factors that change interpretation: posture, fasting, device model, calibration date, body side, timepoint relative to dose or visit window.

6. Define “not done + reason” Make the reason a controlled list. This preserves meaning and allows proper analysis of missingness.

7. Document conversion governance (if applicable) Identify conversion library/source and version. Store the original (recorded) value, original (recorded) unit, converted value, target (canonical) unit, algorithm name/version, and timestamp.

8. Write the spec row and build checks Capture all of the above in a single row per element and implement corresponding edit checks and field constraints in your EDC (Electronic Data Capture) system. Typical ownership: the data manager writes and maintains the spec row; clinical or medical experts justify ranges and conditions; the data standards lead assigns controlled terminology, including unit codes; the biostatistician confirms canonical units and sets analysis rounding; EDC programmers build the checks.

What good looks like

A complete spec row per numeric element:

Tip: add a “Provenance” column in your internal spec to capture device calibration date, operator ID (if required), and conversion algorithm/version.

Worked examples

Example 1 — Fixing a vague pediatric length specification

Goal: Turn an ambiguous instruction into an implementable spec.

• Before (vague): “Baby’s crown to heel length; precision ±1.”

• After (spec):

  • Field name: Infant length (INF_LEN)
  • Definition: Crown‑to‑heel length with infant lying flat.
  • Dimensionality: Length
  • Canonical unit: Centimeter
  • Precision and rounding: One decimal place; round half up
  • Allowable range: 30 to 70 soft; 20 to 90 hard
  • Collection conditions: Supine; study stadiometer; measure twice and record the mean; if readings differ by more than 0.5 cm, take a third and record the median of the three
  • Mixed‑unit policy: Not allowed at entry
  • Not‑done: Required; capture reason (contraindicated, subject distress, equipment unavailable)

Why this works: Anyone can now implement the field and its checks without guessing units, decimals, or posture.

Example 2 — Managing multinational glucose units

Context: Some sites report glucose in mg/dL; others use mmol/L. These are different dimensions (mass per volume vs. amount of substance per volume), and converting between them needs the analyte’s molar mass (glucose: 180.16 g/mol, so 1 mmol/L ≈ 18.0 mg/dL). Each analyte has its own factor (for cholesterol, 1 mmol/L ≈ 38.7 mg/dL), which is why the factor belongs in the governed, versioned algorithm.

• Policy: Store canonical mg/dL. Sites enter the value and unit exactly as the local lab reports them (mg/dL or mmol/L) and never convert by hand.

• EDC fields:

  • GLU_ORIG_VALUE (as entered)
  • GLU_ORIG_UNIT (coded list: mg/dL, mmol/L)
  • GLU_CANON_VALUE (converted to mg/dL)
  • GLU_CANON_UNIT (fixed: mg/dL)
  • GLU_CONV_ALGO (for example, “UnitConvLib”)
  • GLU_CONV_VERSION (for example, “v2.1”)

• Checks:

  • Range checks run on GLU_CANON_VALUE.
  • If unit is mmol/L, system applies versioned conversion automatically.
  • Audit trail records original value, unit, converted value, algorithm, and version.

• Conditions: Capture fasting status (fasting, non‑fasting, unknown) and time since last meal in minutes.

Outcome: Values are comparable at analysis, and every conversion is traceable.

Example 3 — Blood pressure with context that changes interpretation

Problem: BP without posture or cuff size is hard to interpret and triggers avoidable queries.

• Spec:

  • BP_SYS / BP_DIA units: mmHg; integer precision
  • Allowable ranges: SYS 60–220 soft, 40–260 hard; DIA 30–140 soft, 20–160 hard
  • Conditions captured: Seated at least 5 minutes; arm (right/left); cuff size from a small controlled list; device model; repeat if irregular pulse indicated
  • Entry rule: Device auto‑transfers preferred; manual entry allowed with device ID
  • Not‑done: Allowed; reason required

Payoff: Fewer clarification queries and more defensible outlier handling.

Example 4 — Temperature where some sites use Fahrenheit

Risk: Analysts misinterpret values if units are not explicit.

• Policy: Canonical unit is Celsius. Sites may enter Celsius or Fahrenheit.
• System behavior: When Fahrenheit is entered, the system converts to Celsius using a standard, versioned algorithm and stores both.
• Display: Show the recorded value and unit; display canonical value in parentheses to reinforce the standard.
• Range checks: Run on canonical Celsius.
• Conditions: Capture the route (oral, axillary, tympanic, temporal), because it changes the normal range.

Result: No ambiguity during listings review or cross‑study pooling.

Pitfalls & misconceptions

• Precision is not accuracy. The number of decimals you accept does not guarantee the device is correct. If accuracy matters, capture device model and calibration date, or require certification evidence.
• “Obvious” units are not obvious. Never rely on context to imply units; capture the unit with every value, or show it as a fixed label when every source reports in that unit.
• Mixed units without governance. Allowing multiple units but failing to store original unit, conversion method, and version breaks traceability.
• Ignoring device step size. If a scale reports in 0.1 increments, do not allow two or more decimals at entry; you invite false precision.
• Ranges with no rationale. Bounds should align with physiology and the device. Document your sources or reasoning briefly.
• Underspecified rounding. Different rounding modes can change derived values and flags. State it.
• Conditions left in manuals. If posture, fasting, or device changes the meaning, capture it in data fields—not only in instructions.

Practice in the wild (checklist)

• For every numeric field: dimensionality, canonical unit, precision, rounding, range (soft/hard), collection conditions, and not‑done reasons are specified.
• If mixed units are allowed: store original value, original unit (coded), converted value, canonical unit, algorithm name, and algorithm version.
• Edit checks implemented: range checks on canonical values; conditional checks (for example, fasting status required if glucose entered).
• Device metadata captured where it changes interpretation (device model, cuff size, calibration date, body side).
• Display vs. storage precision reviewed to prevent false precision on screens and exports.
• Audit trail confirms conversions and rounding steps.
• Null flavors configured (“not done” + reason list) for required measures.

Key points to remember

• A numeric field is only fully defined when its concept/dimensionality, canonical unit, precision, rounding rule, allowable range (soft/hard), collection conditions, and not‑done handling are captured in one spec row.
• Prefer one canonical unit for storage/analysis. When sources report in different units, always store the recorded value & unit as reported, convert centrally to the canonical unit (sites never convert by hand), and record the conversion algorithm + version and timestamp; run range checks on the canonical value.
• Precision = smallest reportable increment; tie it to the device’s step size and specify the rounding mode. Distinguish stored vs display precision to prevent false precision.
• Allowable ranges should be physiologic/device‑based and justified; choose which limits are soft warnings and which are hard stops (hard stops only for impossible values).
• Treat collection conditions (posture, fasting state, body side, cuff size, device model, calibration date, timing vs dose/meal) as data fields—not just instructions—because they change interpretation.
• Implement not‑done + reason with a controlled list so missingness is analyzable.
• Build edit checks that use canonical values and enforce conditional logic (e.g., if glucose is entered, fasting status must be present).
• Preserve provenance: retain original value/unit, converted value/unit, conversion algorithm/version, and the rounding/conversion steps in the audit trail.
• Remember accuracy ≠ precision: decimals don’t guarantee correctness; device selection, calibration, and method are part of the specification.
• Avoid anti‑patterns: implied or inconsistent units; unversioned conversions; accepting more decimals than devices produce; ranges without rationale; context left only in manuals.