The lab export has 40,000 result rows.
LOINC codes, result values, units, reference ranges, collection dates, specimen types. The LIS export worked correctly. The import into the EHR rejected 12,000 rows.
Meanwhile, the research team wants a subset of the same file for an outcomes study. But the CSV includes patient name, DOB, and MRN in each row — and the free-text result comments mention the ordering provider and clinic name by reference.
Same file. Two distinct problems. Two different fixes.
Lab results CSVs are unique in healthcare data management because they carry both a format problem and a PHI problem simultaneously. Systems that import lab data are strict about LOINC codes, units of measure, result value formats, and reference range structure. And every row of lab data ties a result back to a patient — which makes the same file a PHI handling challenge for any downstream use beyond clinical care.
PHI note: Lab result CSVs contain patient identifiers (name, DOB, MRN) and health information (results, diagnoses by implication). Handle locally. Do not upload to cloud-based formatting or validation services.
TL;DR
Lab results CSVs fail import into LIS and EHR systems primarily due to LOINC code formatting issues, result values combined with units in a single column, reference range format inconsistency, and missing required fields. For research and analytics sharing, the same file contains PHI in structured fields and potentially in free-text result comments — requiring de-identification before external release. This guide covers both paths: format fixing for system import and PHI handling for data sharing.
For the complete Safe Harbor workflow across all 18 identifiers, see our complete Safe Harbor de-identification guide.
⚖️ NOT LEGAL ADVICE — This post covers HIPAA Safe Harbor lab results and de-identification for informational purposes only. Whether your specific data and process satisfy Safe Harbor depends on your data, use case, and organizational context. Consult qualified legal and compliance counsel before making de-identification or sharing decisions for regulated data.
Table of Contents
- Two Paths for Lab Results CSV Data
- What LOINC Is and Why It Matters for CSV Import
- Cause and Fix: Common Lab Results CSV Format Failures
- Reality: What a Lab Results CSV Looks Like Before and After Fixes
- PHI in Lab Result Data: Structured and Free-Text
- Path 1: Fix Format for LIS/EHR Import
- Path 2: De-Identify for Research or Analytics Sharing
- Limitations
- FAQ
- Conclusion
Two Paths for Lab Results CSV Data
Path 1 — Import into LIS or EHR: The file needs strict format compliance. LOINC codes must be valid and correctly formatted. Result values and units must be in separate columns. Reference ranges must match the import schema. Required fields must be present. This path does not require de-identification — the data stays within the covered entity's systems.
Path 2 — Share for research or analytics: The file needs de-identification. Patient identifiers in structured fields (name, DOB, MRN, contact) must be removed or transformed. Free-text result comments must be scanned for embedded PHI. The resulting de-identified dataset can be shared without authorization requirements under HIPAA (if Safe Harbor is satisfied).
Both paths can apply to the same source file. Many organizations need to fix the format for clinical import and then generate a de-identified version for research — typically in that order.
What LOINC Is and Why It Matters for CSV Import
LOINC (Logical Observation Identifiers Names and Codes) is the international standard for identifying laboratory tests, clinical measurements, and observations. Published and maintained by the Regenstrief Institute, LOINC provides a universal vocabulary for lab data exchange — a LOINC code for serum sodium identifies the test consistently regardless of what the ordering laboratory calls it internally.
LOINC code format: A LOINC code consists of a numeric part followed by a check digit, separated by a hyphen (e.g., 2951-2 for serum sodium, 2160-0 for serum creatinine). The numeric part can be 1–7 digits; the check digit is always a single digit or X.
Why LOINC code format matters for CSV import:
- Missing check digit:
2951instead of2951-2— most LIS/EHR systems reject the truncated format - Extra leading zeros:
02951-2instead of2951-2— inconsistent with the LOINC identifier format - Internal lab codes instead of LOINC: Some legacy LIS systems export proprietary lab codes; EHRs expecting LOINC will reject these entirely
- Local test codes in the LOINC column: Mixed columns where some rows have LOINC and others have internal codes are the hardest to fix — requires a LOINC mapping table
Verify LOINC codes against the LOINC database maintained by the Regenstrief Institute. Do not assume internal lab codes are LOINC codes — they typically are not.
Cause and Fix: Common Lab Results CSV Format Failures
| Error Symptom | Common Cause | Fix |
|---|---|---|
| LOINC code rejected | Missing check digit, wrong format, or internal lab code | Verify code against LOINC database; add check digit or map internal codes to LOINC |
| Result value rejected | Value and unit combined in one field ("95 mg/dL") | Split into result_value (numeric only) and result_unit columns |
| Reference range rejected | Inconsistent format ("65-100" vs separate low/high) | Separate into reference_low and reference_high numeric columns |
| Decimal separator error | Comma used as decimal separator (locale issue) | Normalize to period as decimal separator |
| Result status code rejected | Inconsistent values ("Final", "F", "1") | Normalize to the target system's accepted status codes |
| Date/time format rejected | Collection timestamp format mismatch | Reformat to ISO 8601 (YYYY-MM-DDTHH:MM:SS) or target-system format |
| Result value type mismatch | Text values in numeric result column | Identify text-result tests (qualitative results like "Positive/Negative"); route to separate handling |
| Required field absent | LIS export omits a field the EHR requires (specimen type, ordering provider NPI) | Add missing columns; populate from companion source data if available |
Reality: What a Lab Results CSV Looks Like Before and After Fixes
Source export from legacy LIS — before formatting:
PatientMRN,PatientName,PatientDOB,TestCode,TestName,Result,ReferenceRange,Units,CollectionDate,Status,ResultComment
MRN-10041,Johnson Patricia,08/23/1955,LAB-SOD,Sodium,138 mEq/L,136-145,mEq/L,2024-10-15,Final,Normal range. Ordered by Dr. Martinez per clinic protocol
MRN-10042,Torres Miguel,01/15/1983,2160-0,Creatinine,1.2,0.7 to 1.3 mg/dL,mg/dL,10/16/2024,F,Slightly elevated - repeat in 3 months per Dr. Chen UCSF Nephrology
MRN-10043,Williams Sandra,11/07/1931,2951-2,Sodium,142,136-145,mEq/L,2024-10-17,1,
Problems:
PatientNameandPatientDOBare structured PHITestCode: row 1 has a proprietary lab code (LAB-SOD), not LOINCResult: row 1 has value and unit combined (138 mEq/L); rows 2-3 are numeric onlyReferenceRange: row 2 has a different format with unit embedded (0.7 to 1.3 mg/dL)CollectionDate: inconsistent formats (2024-10-15vs10/16/2024)Status: three different values for "Final" (Final,F,1)ResultComment: contains provider names and institution names (PHI in free text)
After format fixing for LIS/EHR import:
patient_mrn,loinc_code,result_value,result_unit,reference_low,reference_high,collection_date,result_status
MRN-10041,2951-2,138,mEq/L,136,145,2024-10-15,F
MRN-10042,2160-0,1.2,mg/dL,0.7,1.3,2024-10-16,F
MRN-10043,2951-2,142,mEq/L,136,145,2024-10-17,F
- LOINC code mapped for
LAB-SOD→2951-2 - Result value separated from unit
- Reference range separated into low/high numeric values
- Collection date unified to ISO date
- Status unified to
F - Patient name and DOB retained (within-system import — PHI acceptable)
- Result comment removed for import (free text not needed for result record)
After de-identification for research sharing:
patient_token,loinc_code,result_value,result_unit,reference_low,reference_high,collection_year,result_status
TKN-A7291,2951-2,138,mEq/L,136,145,2024,F
TKN-B4482,2160-0,1.2,mg/dL,0.7,1.3,2024,F
TKN-C0317,2951-2,142,mEq/L,136,145,2024,F
- Patient name: removed
- Patient MRN: replaced with randomly generated token
- Patient DOB: collection year retained; DOB column removed (patient is 90+ per Sandra Williams row — birth date cannot be retained)
- Result comments: removed (contained provider names and institutional references)
- All other clinical data retained
PHI in Lab Result Data: Structured and Free-Text
Structured PHI in lab result CSVs:
Every row in a lab result export typically links to a patient. Common structured PHI columns:
- Patient name (first name, last name, or combined)
- Date of birth
- Medical record number (MRN)
- Ordering provider name or NPI
- Contact information
- Insurance identifiers
These are Safe Harbor identifier elements and must be removed or transformed for external release.
Free-text PHI in result comments:
Result comment columns (result_comment, interpretation, notes) frequently contain PHI in prose form:
- Ordering provider names: "per Dr. Martinez's order," "follow-up with Dr. Chen at UCSF Nephrology"
- Clinic or institution references: "per Valley Medical protocol," "results sent to UCSF for review"
- Patient descriptions in comments: "patient is a 45-year-old female with..." (combined with result data, this is quasi-identifying)
- Geographic references: "patient resides in rural area per chart"
Automated scanning catches common patterns; manual review is recommended for result comments before external release. See De-Identify Free-Text PHI in Patient CSV Notes for the scanning approach.
Path 1: Fix Format for LIS/EHR Import
1. Validate the file locally
Open SplitForge Data Validator with your lab results CSV. Processing is local.
2. Check LOINC code format
For each test code column: verify codes match the LOINC format (numeric part + hyphen + check digit). Flag proprietary or internal lab codes that need LOINC mapping. Check the LOINC database for the correct code for each test.
3. Separate combined result-unit columns
If result values include units (e.g., 138 mEq/L), split into separate result_value and result_unit columns. Numeric result values should be purely numeric.
4. Normalize reference ranges
Separate range strings into reference_low and reference_high numeric columns. Remove units from range strings if they duplicate the unit column.
5. Normalize dates and status codes
Reformat collection dates to the target system's expected format. Map status codes (Final, F, 1) to the target system's accepted status value.
6. Handle qualitative results
Some lab tests produce text results (Positive/Negative, Reactive/Non-reactive). These need separate handling from numeric results — route to a result_text column or a separate file depending on the import schema.
Path 2: De-Identify for Research or Analytics Sharing
1. Remove or replace structured patient identifiers
Apply Safe Harbor de-identification to all 18 identifier elements in the lab result file. For patient-linked lab data, this typically means: remove name, replace MRN with a pseudonymous token, truncate DOB to year-only (with 90+ rule applied), remove ordering provider name or NPI, remove contact and insurance data.
2. Apply date rules to collection dates
Collection dates are dates directly related to the individual — strip to year-only per §164.514(b)(2)(i)(C). See HIPAA Safe Harbor Date De-Identification.
3. Scan result comment columns for free-text PHI
Result comments are high-risk for free-text PHI (provider names, institution names). Scan for patterns, review flagged rows, redact identified terms. For most research use cases, removing the comment column entirely is the safest option if the comment content is not required for the study.
4. Validate output
Confirm no structured PHI remains. Confirm collection dates are year-only. Confirm no provider names appear in any column. Verify that the LOINC codes and result values are intact (de-identification should not alter clinical data).
Limitations
LOINC code mapping requires external verification. Translating internal lab codes to LOINC codes requires a mapping table built against the LOINC database. SplitForge validates field format — it does not perform LOINC code translation or validate clinical accuracy of existing codes.
Qualitative and semi-quantitative results need separate handling. Lab tests with text results, titer values, and interpreted results (culture sensitivities) require format-specific handling not covered by the general result_value/result_unit split.
De-identification does not preserve research utility in all cases. Removing or generalizing collection dates to year-only may affect longitudinal analyses that depend on the exact timing of test results. For research requiring precise collection timing, date-shifting may be more appropriate than year-only truncation. See De-Identify Patient Data for Research.
FAQ
Conclusion
Lab results CSVs present two problems that need separate fixes — usually in the same workflow.
Format failures (LOINC codes, combined result/unit columns, inconsistent reference ranges) block system import. These are structural issues with no privacy dimension — fix them, validate, import.
PHI exposure (patient identifiers in structured fields, provider names in result comments) blocks legitimate external data sharing. This is a de-identification problem, not a format problem — it requires applying Safe Harbor rules to structured columns and scanning free-text for embedded identifiers.
The two fixes don't interfere with each other. Fix the format for the import copy. Apply de-identification to the research copy. Both can be generated from the same source file.
LOINC code verification is non-negotiable for either path. Don't guess, don't assume internal codes are LOINC, don't use a code that looks close. Verify at loinc.org before import.
Next: Patient List CSV Import Errors → | De-Identify Free-Text PHI in Notes →