Healthcare data extraction turns a medical document into named fields: a patient's date of birth, a diagnosis code, a billed amount. Each field should come back with its value, its data type, the spot on the page where it was found and a confidence score. Those four parts are what make extracted data safe to load into another system.
What does healthcare data extraction return for each field?
Healthcare data extraction returns a record for every field it reads, and a useful record holds more than the value. It names the field, gives the value in a defined type, points to the page and position the value came from, and scores how sure the software is. Without all four, nobody can check the result.
Take one field from a claim form, the patient's birth date. A bare extraction returns the text "03/14/1962". A complete field record looks more like this, with every value fictional:
- Field name: patient_birth_date
- Value: 1962-03-14
- Data type: date
- Source: page 1, the item 3 box, with the rectangle's position on the page
- Raw text: 03 14 1962
- Confidence: 0.97
Each part has a job. The field name ties the value to a column in the system that will receive it. The data type tells that system how to store and compare it. The source lets a reviewer jump to the exact spot on the scan. The raw text shows what the page actually said before any cleanup. The confidence score decides whether a person looks at the field before it moves on.
Medical document extraction differs from general text recognition in that last step. Text recognition, often called OCR, produces characters. Extraction decides which characters answer which question. The difference between a page of text and a set of typed fields is covered in the explainer on what counts as structured healthcare data.
Extraction also assumes it knows what kind of document it is reading. A birth date on an intake form and a birth date on a claim form sit in different places and follow different rules. That is why extraction usually runs after medical document classification has labeled each page.
Choosing which medical data fields to extract first
Medical data extraction should start with the fields someone re-types today. Every field you add needs a definition, a normalization rule, a review path and a place to land in another system. Fields that nobody keys by hand rarely repay that work, so scope the first project to the data entry staff already do.
A short exercise finds those fields. Sit with the person who keys EOBs, claims or intake forms and list every value they type from paper into a screen. Mark the ones they type for every document, the ones they type only sometimes, and the ones they look at but never type. The first group is the starting scope.
Three questions then trim the list:
- Does a downstream system have a field for it? A value with nowhere to go creates storage and review work with no payoff.
- Can a person check it against the page? A field that needs outside knowledge to verify, such as whether a code is clinically right, is not a paperwork field and does not belong in an extraction spec.
- What happens if it is wrong? A wrong amount on a patient account costs more than a wrong fax number on a referral. High-impact fields get stricter thresholds and more review.
Header and identity fields come first on most documents, because every later field hangs off them: patient name, date of birth, member ID, claim number and dates of service. Line-level detail, such as each service line's code and amounts, comes next. Free-text fields such as narrative notes come last, because they are hardest to define and check.
Documents with several patients or several forms in one file add a step before any of this. A packet has to be cut into single documents before fields can be assigned to the right one, as the guide on how to split a multi document medical PDF explains.
Normalizing extracted healthcare data: dates, names, codes and amounts
Normalizing extracted healthcare data means converting raw text into one consistent format per field, so that "3/14/62", "03-14-1962" and "14 Mar 1962" all become the same date. Normalization rules are written per field, applied after extraction, and always keep the raw text alongside the cleaned value.
Dates are the most common case. Even within one form the rules vary. The CMS Medicare Claims Processing Manual, Chapter 26 tells Medicare billers to enter the patient's birth date on the CMS-1500 as an 8-digit date, and each date of service as a 6-digit or 8-digit date. A normalizer has to accept both lengths and turn two-digit years into four-digit years by a stated rule.
Codes need care with punctuation. The same Chapter 26 instructions say not to insert a period in ICD-10-CM codes on the claim form, while the same code is often printed with a period on clinical documents. ICD-10-CM is the code set that, according to the CDC page on ICD-10-CM, "is used to code and classify medical diagnoses" and is maintained in the United States by the National Center for Health Statistics. Pick one stored format and convert to it.
Identifiers should be checked for shape. The CMS page on the National Provider Identifier standard describes the NPI as "a 10-position, intelligence-free numeric identifier". A value with nine digits, or with a letter in it, is a misread, not an NPI, and should go to review instead of being padded or trimmed.
An extraction spec, with six fictional fields
The table below is a sample spec. Every raw and normalized value is made up for the example.
| Field name | Data type | Normalization rule | Raw value on page | Normalized value |
|---|---|---|---|---|
| patient_birth_date | date | Accept 6 or 8 digits; output YYYY-MM-DD | 03 14 1962 | 1962-03-14 |
| patient_name | text | Split last, first; trim spaces; keep original case in raw | WHITFIELD, DANA M | last: Whitfield; first: Dana; middle: M |
| member_id | text | Remove spaces; keep letters and leading zeros | XGH 004 1187 | XGH0041187 |
| diagnosis_code_1 | code | Remove the period; uppercase | e11.9 | E119 |
| rendering_npi | identifier | Exactly 10 digits or send to review | 1234567893 | 1234567893 |
| line_1_charge | money | Strip $ and commas; two decimals | $1,250.0 | 1250.00 |
Two rules in that table deserve a note. Member IDs keep leading zeros, so they must be stored as text, never as numbers. Names keep the raw text, because the split into last, first and middle is a guess that a reviewer may need to undo.
Why should every extracted medical data field link to its source page?
Every extracted medical data field should link to its source page so that a reviewer, an auditor or a billing specialist can see where the value came from in one step. A value without a source can only be trusted or re-keyed. A value with a source can be checked in seconds.
Traceability matters at three moments. During review, a person approving a low-confidence field needs to see the original text, not the cleaned value alone. During a dispute, such as a payer questioning an amount, staff need to show the page the amount came from. During an audit, the office needs to show who approved or corrected each value and what the page said at the time.
A source link should carry enough to find the value again without searching: the document's identifier, the page number and the position of the value on that page. If the document was split from a larger packet, the link should also record the original packet and page, so the trail survives the split.
A source reference for one fictional field
Suppose a fictional EOB, stored as example document EX-DOC-5521, shows a plan payment of $96.00 for example patient Dana Whitfield. Its source reference might read: document EX-DOC-5521, page 2, rectangle starting 61% across and 38% down the page, cut from example packet EX-PKT-0907, page 6. Positions given as a share of the page width and height still work if the image is later resized. A reviewer who opens that reference sees the exact line on the scan, and an auditor two years later sees the same thing.
Schema Care is built around that idea: each field it returns carries a link to the spot where it appears, and a reviewer approving or correcting a field sees it highlighted on the original page. The homepage lists the medical documents Schema Care reads and the fields it pulls from each.
The confidence score and the source work together. The score decides which fields a person looks at, and the source makes that look fast. Setting thresholds and running a review queue is its own subject, covered in the human review category.
Data extraction in healthcare mistakes that corrupt downstream systems
Data extraction in healthcare goes wrong most often in quiet ways: a value that looks right, has the right format and lands in the wrong place. Billing systems and EHRs accept those values without complaint, and the error surfaces weeks later as a denied claim, a misposted payment or a chart with the wrong date.
These are the mistakes that do the most damage:
- Dropping the raw text. Once only the normalized value is stored, nobody can tell whether a strange value came from the page or from the cleanup rule.
- Storing identifiers as numbers. A spreadsheet or database that treats a member ID as a number strips its leading zeros, and the ID no longer matches the payer's records.
- Guessing to fill a gap. A rule that pads a nine-digit NPI to ten digits, or assumes a century for a two-digit year without saying so, turns a visible error into a hidden one.
- Skipping total checks. Line amounts should add up to claim totals, and claim totals to the payment. A check that fails is often the only sign that one field was read into the wrong box.
- Loading low-confidence fields straight in. A score is only useful if fields below the threshold are held for a person before anything downstream changes.
- Changing a field's meaning silently. If "service_date" means the first date of a span on one document type and the last date on another, every report built on it is wrong.
Most of these mistakes come from treating extraction output as finished data instead of as a proposal that still needs checking. Fixed-position extraction and model-based extraction both make them, which the comparison of template based vs AI medical document extraction discusses from the method side.
Field definitions also need to be written down somewhere a developer can use them. Teams that send extracted data into other systems often describe each field in a JSON schema, a topic the developer integration category covers in detail.