Structured healthcare data sits in named fields with a set type and meaning, such as a date of service, a member ID or a diagnosis code, so software can sort, total and check it. Unstructured healthcare data is free text: notes, letters and scanned pages that a person can read but a system cannot use until values are pulled out.
What counts as structured healthcare data?
Structured healthcare data is any value stored with three things attached: a field name, a data type and a fixed meaning. "Date of service: 2026-03-14" is structured because the name says what it is, the type says it is a date, and every record uses that field the same way.
The field name tells software where to look. A billing system does not search a page for something that resembles a charge; it reads the field called charge. The data type says what kind of value is allowed: a date, an amount in dollars, a whole number of units, a code from a list, or a yes or no. The fixed meaning means two records can be compared, because "allowed amount" on one claim is the same idea as "allowed amount" on the next.
Code sets add a fourth layer. A diagnosis written as a code from ICD-10-CM, which the CMS ICD-10 page describes as the diagnosis code set maintained by the CDC, a lab test identified by a LOINC code, or a drug named in RxNorm form has a meaning that other systems share. The NLM page on LOINC calls it a clinical terminology important for laboratory test orders and results. The NLM RxNorm overview describes normalized drug names built from ingredient, strength and dose form.
Exchange standards are built on the same idea. The HL7 FHIR overview says the basic building block in FHIR is a resource, and that all exchangeable content is defined as one. Each resource is a set of named, typed elements, which is structured data by design.
Where unstructured healthcare data hides in a medical office
Unstructured healthcare data in a medical office is mostly text written for people. Visit notes, referral letters, discharge summaries, faxed records requests, patient emails and scanned PDFs all carry facts inside sentences or images. The facts are there, but no field holds them, so a system cannot find or check them without help.
Some of it is born digital. A provider types a progress note into a free-text box in the EHR, and the note is stored as one long paragraph. The diagnosis, the medication change and the follow-up date are all in there, yet none is a field.
Much of it arrives on paper or by fax. A scanned page is less structured than a typed note, because it is only an image until OCR turns it into text. The steps that make that text, from cleaning the image to recognizing characters, are covered in the medical OCR recognition steps from pixels to characters.
Attachments are the easiest to miss. A payer letter saved to a patient's chart, a photo of an insurance card, or a PDF lab report filed as a document all look like records in the system. They are stored, but their contents are not searchable as fields.
What does structured data mean for medical paperwork?
Structured data means a billing or EHR system can act on a value instead of storing it. A system can add up structured charges, compare a structured allowed amount with a fee schedule, flag a missing member ID, or sort claims by date of service. None of that works on a sentence, however clearly it is written.
The side-by-side table shows one fictional encounter both ways. The patient, ID and values are examples only.
| Unstructured note (example) | Field name | Value | Data type |
|---|---|---|---|
| "Jane Example, seen 3/14/26 for follow-up..." | patient_name | Jane Example | text |
| "...seen 3/14/26..." | encounter_date | 2026-03-14 | date |
| "...member ID ABC123456789 on file..." | member_id | ABC123456789 | identifier |
| "...BP 128/82 today..." | blood_pressure | 128/82 | measurement |
| "...allergic to penicillin..." | allergy | penicillin | text from a list |
| "...return in 6 weeks." | follow_up_interval | 6 weeks | duration |
The note on the left is complete and easy for a colleague to read. The fields on the right are what let a system answer questions like "which patients are due for follow-up next month" or "which encounters lack a member ID".
Paperwork teams feel the difference most when they re-type. Every value a person keys from a letter into a field is a conversion from unstructured to structured data, done by hand. Records teams that file clinical documents will find more on this in the clinical records category.
How NLP pulls structured fields out of unstructured medical records
Natural language processing (NLP) is software that reads sentences and finds the facts in them. In medical records, NLP takes text that OCR or an EHR has already produced and identifies things like drug names, doses, dates, diagnoses and allergies, then places each one in a named field.
NLP usually works in stages. It splits text into sentences and words, tags each word with its role, recognizes named items such as a medication or a body part, and then links related items. In "metformin 500 mg twice daily", it should tie the strength and frequency to the drug rather than treat them as three loose facts.
Negation and context are the hard part of NLP medical records work. "No history of diabetes" and "family history of diabetes" both contain the word diabetes, yet neither says the patient has it. A system that misses the "no" or the "family" creates a wrong field from a correct sentence.
Codes come last. Once NLP has found a drug or a test, a separate step may map it to a code set, such as RxNorm for drugs or LOINC for lab tests. Getting dates, names, codes and amounts into one consistent format is a topic of its own, covered in normalizing extracted healthcare data.
The semi-structured edge case: medical forms between the two kinds of data
Semi-structured healthcare data sits between the two kinds. Claim forms, EOBs, lab reports and intake forms have labels, boxes and tables, so each value has an expected place. On paper or as a scan, though, those values are still pixels, and every payer and lab arranges the page a little differently.
A claim form is the cleanest example. The Medicare Claims Processing Manual chapter on Form CMS-1500 assigns each item a meaning: item 1a holds the patient's Medicare beneficiary identifier, item 21 holds up to 12 diagnosis codes on lines A to L, and item 24F holds the charge for each service. The structure exists on the form, but a scanned copy has to be read to recover it.
EOBs are looser. The CMS guide to the explanation of benefits lists common parts such as provider charges, allowed charges, paid by insurer and remark codes, yet each plan prints them in its own layout and with its own labels.
Semi-structured documents are often the best place to start automating, because their fields are known in advance. Schema Care reads several of them, including EOBs, CMS-1500 and UB-04 claims, lab reports and intake forms; the full list and the fields it reads from each are on the supported documents list. To see how these forms move from the inbox through review into a system, read the guide to healthcare document processing from inbox to clean data, and for where OCR fits by team, the overview of OCR in healthcare.