Data Type Validation

The core mechanism that verifies a data value matches its declared primitive type—integer, float, string, boolean, date, or datetime. In clinical systems, this prevents a patient's age from being stored as a text string or a lab result from containing alphabetic characters.

• Integer checks: Reject decimal values in fields like heart_rate or length_of_stay
• String validation: Enforce character set restrictions (e.g., alphanumeric-only for MRNs)
• Date parsing: Validate ISO 8601 compliance and reject impossible dates like February 30th
• Boolean strictness: Accept only true/false or 1/0, rejecting ambiguous values like 'Y' or 'yes'

Beyond basic type checking, validation engines apply regular expressions and format masks to ensure values adhere to expected structural patterns. This is critical for identifiers that have strict syntactic rules.

• LOINC codes: Must match \d{1,5}-\d{1} pattern before semantic validation
• ICD-10-CM codes: Validated against [A-Z]\d{2}\.\d{1,4} structure
• NPI numbers: Verified using the Luhn check digit algorithm embedded in the 10-digit format
• Email addresses: Validated per RFC 5322 for patient portal communications

A critical characteristic that defines how the validation engine treats absent data versus empty data. In clinical contexts, a missing lab result has different implications than a result of zero.

• NULL vs. empty string: NULL indicates 'not collected,' while '' may indicate 'collected but blank'
• Required field gates: Reject records where mandatory fields like patient_id are absent
• Sentinel values: Flag placeholder values like 9999-12-31 that indicate unknown dates
• Optionality metadata: Each field carries a cardinality constraint (0..1, 1..1, 0..*) enforced at the type level

The engine's policy for implicit type conversion versus explicit casting. Healthcare data often arrives as strings from HL7 v2 messages and must be safely converted to native types.

• Safe casting: "37.2" → 37.2 (float) for temperature values, with precision preservation
• Lossy conversion detection: Flag when casting float to integer would truncate clinically significant decimals
• Encoding-aware parsing: Handle UTF-8, ASCII, and legacy EBCDIC encodings from mainframe systems
• Locale-independent parsing: Treat "1,234.56" and "1.234,56" according to declared locale metadata

Type validation often couples with domain-specific range checks that define valid boundaries for numeric and temporal types. This prevents physiologically impossible values from entering clinical databases.

• Numeric bounds: Systolic blood pressure must be an integer between 0-300 mmHg
• Date boundaries: Date of birth cannot be in the future and must be within 0-120 years of encounter date
• Enumeration constraints: Gender/sex values restricted to defined code sets (e.g., M, F, U per HL7 v3)
• Precision limits: Lab results cannot exceed the instrument's documented significant figures

The validation engine's ability to categorize failures by severity and produce actionable error messages. Not all type violations are equal—some halt processing while others generate warnings.

• Fatal errors: Block record ingestion (e.g., non-numeric value in a numeric primary key)
• Warning-level: Allow processing but flag for review (e.g., unexpected but parseable date format)
• Error codes: Standardized codes like DT-001 for date format violations enable automated remediation
• Lineage tracking: Each error links to the source field, raw input value, and transformation step that failed