The parts of a lab report for data entry are the header (patient, ordering provider, performing lab), the specimen dates, the result rows (test name, value, unit, reference range, flag), and the notes around them: comments, corrections and signatures. Someone keying a report needs every part, because each one fills a separate field in the receiving system.
Lab report header fields: patient, ordering provider and performing lab
The header of a lab report is the block at the top that says whose results these are, who asked for them and which lab produced them. For data entry, the header decides which patient record the results attach to, so it is the first part to capture and the first part to check.
Federal rules set a floor for what a report carries. Under the Clinical Laboratory Improvement Amendments (CLIA), which CMS describes as the program that regulates laboratory testing performed on humans in the U.S., the test report rule at 42 CFR 493.1291 on the eCFR lists what a report must show. Paragraph (c) names positive patient identification, the name and address of the laboratory location, the date of the report, the test performed, the specimen source when appropriate, the result with units or interpretation where they apply, and the condition and disposition of specimens that did not meet the lab's acceptability criteria.
In practice the header splits into three groups:
- Patient block. Name, date of birth, sex, and one or more identifiers: the lab's own patient or accession number, and often the ordering clinic's medical record number.
- Ordering block. The ordering provider's name, sometimes with an NPI, and the clinic or account the report was sent to.
- Performing lab block. The lab's name and address, and on many reports a CLIA number and a laboratory director's name.
Required fields are usually the ones that match the report to a patient and a lab: patient name, date of birth, the report date, the performing lab and at least one identifier. The ordering provider is required in most clinic workflows because it routes the result to the right inbox. The accession number is worth capturing even where it is optional, because it is the lab's key for the specimen and the reference you quote when you call the lab.
A frequent problem is a header that disagrees with itself. A report can print the patient's legal name in the header and a preferred name in a footer, or carry two different identifiers from the lab and the clinic. Capture what is printed, in the field it belongs to, and leave matching to the step designed for it. The guide to lab report data extraction from received file to approved record covers where patient matching fits.
Which specimen collection date and time fields does a lab report carry?
A lab report usually carries three specimen dates: when the specimen was collected, when the lab received it, and when the result was reported. Each one answers a different question, and the specimen collection date and time fields are the ones most systems treat as the result date, because they mark when the sample was taken from the patient.
The rules and standards support that split. The CLIA test request rule at 42 CFR 493.1241 on the eCFR requires the requisition to include "the date and, if appropriate, time of specimen collection." The report rule requires the date of the report. The HL7 FHIR Specimen resource defines its collected time as the time the specimen "was collected from subject - the physiologically relevant time" and its received time as the time it "was received for processing or testing," according to the HL7 FHIR R4 Specimen resource page.
Labels vary from lab to lab. Here is how common labels map to fields:
| Printed label (examples) | Field | Type | Notes |
|---|---|---|---|
| Collected, Coll date, Drawn | collected_at | date and time | Time is often present; keep it when printed |
| Received, Rec'd, Accessioned | received_at | date and time | Useful for tracing delays, rarely required |
| Reported, Resulted, Final | reported_at | date and time | Changes when a corrected report is issued |
| Printed, Run date | printed_at | date and time | The date the PDF was generated; not a result date |
Keep the time when the report prints one, and keep the time zone if the report states it. A specimen collected late in the evening and received after midnight carries two different calendar dates, and a field that stores the received date by mistake moves the result to the wrong day.
Storing only the reported date is the error that causes the most trouble later. When a lab issues a corrected report, the reported date changes, while the collection date stays the same. A results table keyed on the reported date then shows the same test twice on two days.
The lab result row: test name, value, unit, range and flag
A lab result row is one line of the results table, and it holds five columns that each fill a field: the test name, the result value, the unit, the reference range and the abnormal flag. Data entry reads them left to right and keeps them together, because a value without its unit or range is incomplete as data.
Each column has its own type and its own trap:
- Test name. The lab's own name for the test, such as "Glucose" or "Sodium, serum". Keep it exactly as printed. Mapping it to a standard code is a separate step. The National Library of Medicine describes LOINC as a clinical terminology important for laboratory test orders and results, and that mapping belongs in its own field next to the printed name.
- Value. A number, a number with a sign such as "<0.5", or text such as "Negative". Store it as printed first, then as a parsed number when it is one.
- Unit. The unit printed beside the value, such as mg/dL or mmol/L. The UCUM specification gives a coded form for units, which is useful as a second field. The printed unit stays.
- Reference range. The interval the lab printed for that row, such as "70-99". Ranges come in several printed forms. The post on reference range formats printed on lab reports walks through each one.
- Flag. A letter or symbol the lab printed to mark the row, such as H or L. Record the flag as printed. The guide to abnormal flag codes labs print, from H and L to A lists the codes.
Panels add one more column of context. A basic metabolic panel prints several rows under one panel heading, and each row should keep a reference to that panel so the rows stay grouped after entry.
An annotated fictional lab report
Every name, number and value below is invented for this example.
[1] PERFORMING LAB Example Reference Laboratory, 100 Sample Way, Anytown
CLIA: 00D0000000 (example)
[2] PATIENT Rivera, Casey (fictional) DOB 03/14/1985 Sex F
Lab patient ID: LP-482113 Clinic MRN: 77-0412
[3] ORDERING Dr. Morgan Lee, Northside Family Clinic (example)
[4] ACCESSION A26-0098812
[5] COLLECTED 10/02/2026 07:45 RECEIVED 10/02/2026 11:20
REPORTED 10/02/2026 16:05 STATUS: FINAL
[6] TEST RESULT FLAG UNITS REFERENCE RANGE
Glucose 104 H mg/dL 70-99
Sodium 139 mmol/L 136-145
[7] TEST RESULT REFERENCE
Urine nitrite Negative Negative
[8] COMMENT Specimen received at room temperature.
[9] Electronically signed by: Example Lab Director, MD
Mapping each part to a field
| Part | Field name | Data type | Required |
|---|---|---|---|
| [1] Performing lab | performing_lab_name, performing_lab_address | text | Yes |
| [2] Patient | patient_name, patient_dob, patient_sex, patient_ids | text, date, code, list | Yes |
| [3] Ordering provider | ordering_provider | text | Yes in most workflows |
| [4] Accession | accession_number | text | Recommended |
| [5] Dates and status | collected_at, received_at, reported_at, report_status | date and time, code | collected_at and reported_at yes |
| [6] Numeric row | test_name, value_text, value_number, unit, reference_range, flag | text, text, decimal, text, text, text | test_name and value_text yes |
| [7] Text row | test_name, value_text, reference_text | text | Yes |
| [8] Comment | comment_text, comment_scope | text | Yes when printed |
| [9] Signature | signed_by, signed_at | text, date and time | Recommended |
Are qualitative lab results entered differently from numeric ones?
Qualitative lab results, such as "Negative", "Detected" or "Reactive", are entered as text values, while quantitative results are numbers with units. Both live in the same result row and the same table. What changes is which value field is filled, and whether a unit and a numeric range apply at all.
The HL7 FHIR Observation resource shows the pattern clearly. Its result element can hold a Quantity, a CodeableConcept, a string and several other types, and its reference range has a text element for "when a quantitative range is not appropriate", according to the HL7 FHIR R4 Observation resource page. The same report row can therefore carry either a number with a unit or a word with an expected word.
For keyed data, a practical design uses two value fields:
| Field | Numeric example | Qualitative example |
|---|---|---|
| value_text | 104 | Negative |
| value_number | 104 | (empty) |
| unit | mg/dL | (empty) |
| reference_range | 70-99 | (empty) |
| reference_text | (empty) | Negative |
Always fill value_text with the printed result. Fill value_number only when the printed value is a plain number. This keeps every result readable as printed while still letting a spreadsheet or database sort and filter the numeric ones.
Some results sit between the two. Values such as "<0.5" or ">1000" are numbers with a qualifier. Store the full string in value_text, and either leave value_number empty or store the number with a separate comparator field holding "<" or ">". Dropping the sign and keeping 0.5 creates a value the lab never reported.
Titers such as "1:160" and semi-quantitative grades such as "2+" are another case. They look numeric but are not plain numbers, so keep them as text. Converting "2+" to the number 2 loses the plus sign, and a later reader cannot tell what the lab printed.
Lab report parts that data entry skips by mistake: comments, corrections and signatures
Comments, corrections and signatures are the lab report parts that data entry skips most often, because they sit outside the results grid. Each one changes what a result means as data: a comment can qualify a value, a correction can replace one, and a signature or status line tells you whether the report is final.
Comments. Labs print comments under a single row, under a panel, or at the bottom of the report. A comment such as "Specimen hemolyzed" or "Result verified by repeat analysis" belongs to the row or panel it sits under. Capture the text and its scope. A comment field with no link to its row is hard to use later.
Corrections. The CLIA report rule says that when errors in reported results are found, the lab must issue corrected reports and keep "duplicates of the original report, as well as the corrected report," per 42 CFR 493.1291(k) on the eCFR. A corrected report often prints "CORRECTED" near the status, a new reported date, and sometimes the previous value. FHIR's observation status codes include preliminary, final, amended and corrected, which is a good model for a report_status field. Enter a corrected report as a new version linked to the original. Do not overwrite the earlier entry without a record of it.
Signatures and status. A line such as "Electronically signed by" or a status of PRELIMINARY tells you where the report sits in the lab's process. A preliminary report can be followed by a final one with different values. Capture the status on every report so the final version can replace the preliminary one cleanly.
Pages and footers. Multi-page reports repeat the header on each page and sometimes print the lab's page count in the footer. Check the count, because a missing last page often holds the comments and the signature. Results that continue on the next page also break a table in two. The post on lab report OCR and where it fails covers how page breaks and faint footers affect what software reads.
Keying every part of a report by hand is slow, and the parts outside the grid are the easiest to miss. Schema Care reads test names, results, units, reference ranges and abnormal flags from lab reports, and each field links back to the spot on the page it came from, so a reviewer can check it against the original. You can see how a low-confidence field goes to a person in the human review workflow on the homepage. For other clinical documents and the fields they carry, browse the clinical records category.