How to Extract Data From Medical Records

To extract data from medical records reliably, define the fields first, split the record into its separate documents, pull each value along with the page it came from, score how sure you are of each one, send the uncertain values to a person, and export only what has been checked. Then spot-check a sample and keep the log.

Step one: define the medical record fields before you start

Defining the medical record fields means writing down, before anyone opens a chart, every value you want, what type it is, where in the record it usually lives, and what to record when the record is silent. A field list written after extraction starts gets rewritten halfway through, and the early records have to be done again.

Start from the use, not from the record. A billing team checking encounter dates needs a handful of fields. A clinic moving outside records into its own chart needs problem lists, allergies, medications and recent results. A quality audit needs whatever its policy asks about. Write the question each field answers next to the field name. If no question needs a field, drop it.

Published standards are a good place to borrow names. The ONC USCDI page groups the data that standards-based exchange is built around into classes such as Patient Demographics, Problems, Medications, Allergies and Intolerances, Vital Signs and Encounter Information. Borrowing those names makes later mapping to another system easier.

Each field needs four things written down: a name, a type (date, text, number, yes or no, code), a preferred source document, and a missing value such as "not documented". Leave out any of the four and two people will fill the field differently.

The six-step checklist

Example: for a fictional patient, Marcus Bellweather, record EX-209318, step 1 might list eight fields, and step 6 might check two of them against the original pages.

Step two: split and sort the medical record pages

Splitting and sorting the medical record pages means turning one long file into its separate documents, then labelling each with a type such as H&P, progress note, operative report, lab report or discharge summary. Extraction rules depend on document type, so a page has to be identified before its values can be read.

Records from another facility often arrive as a single PDF of several hundred pages. Inside it sit dozens of documents in no reliable order. The boundary between two documents is usually marked by a new header, a new date, a new author or a new title line. Record the first and last page of each document, and keep the original page numbers, so every later value can point back to the right page of the file you received.

Document types are fairly standard. The HL7 Consolidated CDA implementation guide names a set of clinical document types, including Consultation Note, Continuity of Care Document, Discharge Summary, History and Physical, Operative Note, Procedure Note, Progress Note, Referral Note and Transfer Summary. A label set close to that list is easy to explain to anyone who works with clinical documents.

Three mistakes show up again and again at this step:

• Dropping pages. Cover sheets, blank pages and fax headers get deleted, and the page numbers shift. Keep them, labelled as non-clinical, so the original numbering survives.
• Merging two documents. A progress note that runs straight into a consult note on the same page gets one label. Split at the new header, even mid-page.
• Mixing patients. A records release can include a page from another patient. Check the name and record number on every document, not only on the first page of the file.

What each type contains, and which fields are worth pulling from it, is covered in the guide to clinical document extraction by document type.

Dates add a second sort. Within a type, order documents by the date that belongs to the encounter, not the date the page was printed or faxed. Which date counts on each page, and how to sort a long record by type, is set out in the post on sorting a long medical record by document type.

Step three: extract each field with its page location

Extracting each field with its page location means storing, for every value, the page number and the spot on that page where the value was read. A value without a location cannot be checked without rereading the whole record. A value with one can be checked in seconds by anyone who opens the page.

A record of one extracted value should hold more than the value. A minimal shape:

All values here are fictional examples. Keeping the printed text beside the normalized value matters. If someone later questions why "SULFA" became "Sulfa drugs", the original wording is right there.

Some fields need a judgment the layout cannot supply. A form field labelled "Allergies" is easy. A sentence in a narrative note is harder, because words like "denies" or "family history of" change what a phrase means for the field. That problem has its own treatment in the post on negation and context in unstructured clinical text, and the wider topic of free-text notes is covered in unstructured healthcare data extraction.

When the same field appears in several documents, extract each occurrence, not only the first. A medication list in the H&P and another in the discharge summary are two facts from two moments. Your field definition from step one decides which one wins, and keeping both lets a reviewer see the conflict.

How do you decide which extracted medical record fields need review?

Extracted medical record fields need review when the software's confidence in them falls below a threshold you set. A confidence score is a number attached to each value that estimates how likely it is to be right. Values above the threshold pass. Values below it go to a review queue for a person to check.

The threshold is a business choice, and it can differ by field. A misread patient name or date of birth puts a value in the wrong chart, so many teams set a high bar there. A misread free-text note field may matter less. Start with one threshold for everything, look at what lands in the queue, then raise or lower it per field.

A few rules cover most cases:

• Always review identity fields at first. Patient name, date of birth and record number decide where every other value goes.
• Review conflicts even when each value scores well. Two different allergy lists are a question for a person.
• Review empty required fields. A blank where the record should have an answer is as suspicious as a low score.
• Track the queue. If one field lands in review far more than others, its definition or its source may be the problem.

The reviewer should see the value and the highlighted spot on the original page side by side, then approve or correct it. The threshold demo on a fictional sample shows how moving the confidence bar changes which fields skip review. For the broader question of when people should check machine output, see the human review category.

Step five: export abstracted medical record data

Exporting abstracted medical record data means sending only checked values to where they will be used: an EHR, a registry tool, a spreadsheet for an audit, or a billing system. The export carries each value, its field name, the patient and document it belongs to, and ideally a reference back to its source page.

Match the receiving system's format before the first export, not after. Field names, date formats and code systems must line up. A date written 03/05/2026 means March in one system and May in another. Pick one format, usually year-month-day, and convert at the edge.

Check three things on every export:

• Row counts. The number of rows sent equals the number of records approved.
• Identifiers. Every row carries the right patient identifier, and no row was matched to the wrong patient.
• Rejected rows. Anything the receiving system refuses is logged and sent back to review, not dropped.

Then do step six. Pull a small sample of exported rows each week, open the source page for each, and compare. Keep the review log: who approved each value, who corrected it, and when. Schema Care keeps that trail for every approval and correction, and puts doubtful fields in front of a reviewer before anything goes out.

When does manual medical record extraction beat automation?

Manual medical record extraction beats automation when volume is low, the field list changes often, or every value needs clinical judgment anyway. Setting up software, defining thresholds and checking a pilot all take time. For a one-off project of a few dozen records, a careful person with a good form can finish first.

Some signs that manual work is the better choice:

• Small, one-time projects. Fifty charts for a single audit rarely repay setup.
• Unsettled fields. If the field list is still being argued over, automating it fixes the wrong thing in place.
• Judgment-heavy fields. If nearly every value needs a person's reading of a narrative note, review time will dominate anyway.
• Very poor scans. Pages so faint or skewed that a person struggles will also produce low confidence scores, and most values will go to review.

Automation starts to pay when the same fields are pulled from the same kinds of documents every week, and a person's time is better spent checking than typing. A middle path works for many teams: automate the steady fields, such as dates, names and medication lines, and keep a person on the narrative ones. Whatever the mix, keep the six steps. They work the same with a pen and paper form as with software.