Medical record abstraction is the work of reading a patient chart and recording a fixed set of facts from it onto a form, one defined field at a time. A written data dictionary says what each field means and where to look. The result is a dataset many charts feed in the same shape, ready to count and audit.
What is medical record abstraction?
Medical record abstraction is a structured reading of a chart against a list of questions decided in advance. An abstractor opens the record, finds the answer to each question, and writes it into a form field. The output is one row per patient or per encounter, with the same columns for every chart in the project.
The questions come first, and the chart second. A project might ask for an admission date, a discharge date, the type of procedure performed, and whether a given document is present in the record. Each question has an allowed set of answers. A date field takes a date. A yes or no field takes yes, no or "not documented". A code field takes a value from a named code list.
That fixed shape is what separates an abstracted dataset from a pile of notes. Two hundred charts abstracted with the same form produce two hundred rows that can be sorted, counted and checked. Two hundred free-text summaries of the same charts cannot be added up without reading each one again.
Abstraction is also selective. A chart for a three-day hospital stay can run to hundreds of pages. A typical abstraction form uses a small fraction of what is on those pages and ignores the rest on purpose. The form decides what matters for the project. Everything else stays in the chart, where it belongs.
The people who do this work are usually called abstractors or chart abstractors. What their day looks like, and what training the role asks for, is covered in the post on what a medical record abstractor does each day.
Clinical data abstraction versus plain chart data entry
Clinical data abstraction differs from plain chart data entry in one way that matters: abstraction requires a judgment about which value answers the question, while data entry copies a value from a known spot. A clerk keying an intake form types what is in each box. An abstractor decides which of several dates is the right one.
Consider a field called "admission date". On a short outpatient record, one date appears and the answer is obvious. On an inpatient chart, the same patient may have an emergency department arrival time, an order to admit, a registration time and a date on the first nursing note. The data dictionary for the project says which of those counts. Without that rule, two careful people can record two different dates and both believe they are right.
Data entry has its own place. Copying the member ID from an insurance card into a billing system needs accuracy, but it does not need a definition document, because the card has one box labelled member ID. Abstraction needs definitions because charts are written by many people for clinical purposes, and the fact the project wants is often spread across several documents.
A short way to tell the two apart:
| Task | Typical source | What the person decides |
|---|---|---|
| Data entry | A form with labelled boxes | Only whether the value was read correctly |
| Abstraction | A chart of many documents | Which document answers the question, and which value in it counts |
Most real projects mix both. Patient name, date of birth and record number are plain copying. "Was the required consent form signed before the procedure?" is abstraction, because the abstractor has to find the consent, find the procedure time and compare them.
Who uses abstracted chart data, and for what?
Abstracted chart data is used by any team that needs the same facts from many records: quality reporting staff, disease registries, research study teams and internal auditors. Each one asks a different set of questions of the chart, so each one has its own form, its own fields and its own preferred source documents.
Quality reporting is the most familiar use in hospitals. CMS runs reporting programs in which some measures are built from chart review. The CMS page on ICD-10 and quality measures refers to "chart-abstracted measures" in the Hospital Outpatient Quality Reporting Program and points to the specification manuals that hold the code lists for inpatient measures.
Disease registries are the second large user. The CDC National Program of Cancer Registries overview explains that hospitals, doctors' offices and pathology labs send cancer case information to central registries, and that trained registrars transfer information from the patient's medical record into registry software. That transfer is abstraction under another name. The rules registries use to define each field get their own treatment in the post on how registry data dictionaries define each abstraction field.
Research studies and internal audits round out the list. A study team abstracts charts to build a dataset for a question its protocol defines. An audit team abstracts a sample of charts to check whether its own documentation matches its own policies.
Abstraction purposes, fields and sources
This table is illustrative. The fields are typical examples of what each kind of project asks for, not a list from any one program.
| Purpose | Typical fields (examples) | Source documents it draws on |
|---|---|---|
| Quality measure | Arrival time, discharge date, discharge disposition, whether a listed step was documented, exclusion reasons | ED record, orders, nursing notes, discharge summary |
| Registry | Date of diagnosis, primary site, histology text, first course of treatment, treating facility | Pathology report, H&P, operative report, oncology notes |
| Research study | Eligibility criteria met (yes or no), baseline values, study visit dates, outcome events | Clinic notes, lab reports, problem list, imaging reports |
| Internal audit | Signed consent present, signature dates, H&P timing, discharge summary completed | Consent forms, H&P, operative report, discharge summary |
The same chart can feed all four. A single surgical stay might supply a registry row, a quality measure row and an audit row, each built from a different form.
Abstraction forms and data dictionaries
An abstraction form is the list of fields a project collects, and a data dictionary is the document that defines each of those fields. Together they decide what gets pulled. The form says "discharge disposition". The dictionary says what values are allowed, where in the chart to find the answer, and what to do when two documents disagree.
A useful data dictionary entry has the same parts every time:
- Field name, short and fixed, such as
discharge_date. - Definition, one or two sentences in plain words.
- Allowed values, a type (date, yes or no, number, code) and, for coded fields, the code list.
- Source priority, the order in which documents are checked. For example: discharge summary first, then the physician discharge order, then the nursing discharge note.
- Conflict rule, what to record when two sources give different answers.
- Missing rule, the value to record when nothing in the chart answers the question, such as "not documented".
- Examples, one easy case and one hard case, with the right answer for each.
Here is one entry, written for a fictional internal audit:
| Part | Example entry |
|---|---|
| Field name | hp_before_procedure |
| Definition | Was a history and physical documented in the chart before the start time of the first procedure requiring anesthesia? |
| Allowed values | Yes, No, Not applicable (no such procedure) |
| Source priority | H&P document, then H&P update note, then pre-procedure assessment |
| Conflict rule | Use the signed time on the H&P, not the dictation time |
| Missing rule | No |
That entry has a real rule behind it. The federal hospital conditions of participation in 42 CFR 482.24 on medical record services require a medical history and physical examination documented no more than 30 days before or 24 hours after admission, and before surgery or a procedure requiring anesthesia. An audit form turns that requirement into a field a person can answer chart by chart.
A completed form for one fictional chart, with the page behind each value, is worked through in the post on the filled abstraction form for the sample chart.
Medical chart abstraction from paper charts and EHR exports
Medical chart abstraction works differently depending on where the chart lives. A paper chart or a scanned PDF is read page by page, and finding the right document is half the job. An electronic health record lets the abstractor search and filter, but it scatters one fact across screens, notes and tables that a printout would have kept together.
Paper and scanned charts have a fixed order, which helps when the order is good and hurts when it is not. A well-tabbed chart puts the H&P, operative reports, progress notes and discharge summary in predictable places. A chart that arrived as a single 400-page fax has no tabs at all. The abstractor first has to find each document, then read it. Software can help with that first step by sorting pages into document types and recording where each one starts.
EHR charts raise the opposite problem. Every fact is findable, but the same fact can appear in several places with different values. A medication list in a structured table, a medication paragraph in a progress note and a discharge medication list in the summary may not agree, because each was written at a different moment. The data dictionary's source priority rule matters even more here.
EHR exports sit between the two. A printed or PDF export of an electronic chart looks like paper but was generated by software, so its layout is regular. A structured export, such as a summary document built on the HL7 Consolidated CDA templates, carries coded sections that can be read without optical character recognition at all. The ONC USCDI page lists the data classes, such as Problems, Medications and Allergies and Intolerances, that standards-based exchange is built around.
Discharge summaries are among the most common documents an abstractor reads from either source. The fields one yields, and the layouts that cause trouble, are covered in the guide to discharge summary extraction. For the general workflow from defining fields to exporting checked values, see how to extract data from medical records.
Vague abstraction definitions: the costliest error
A vague abstraction definition is the costliest error in a project because it fails silently. Every chart gets a value, the form looks complete, and nobody notices that two abstractors read the same rule two different ways until the dataset is analysed. By then, hundreds of charts may need to be pulled again.
Take a fictional field called discharge_date, defined only as "the date the patient left the hospital". Abstractor A records the date on the physician discharge order. Abstractor B records the date on the nursing note that says the patient left the unit. For most charts the two match. For a patient whose order was written at 11 p.m. on 3 March and who left at 9 a.m. on 4 March, they do not. The dataset now holds two meanings in one column.
The fix is in the dictionary, not in training alone. Spell out the source priority, add a hard example with its right answer, and say what to do with a conflict. Then test the definition before full abstraction starts. Have two people abstract the same small set of charts, compare field by field, and rewrite every definition where they disagreed. Repeat until the disagreements stop clustering on the same fields.
A few patterns produce most vague definitions:
- Undefined time anchors. "Within 24 hours" without saying 24 hours of what.
- Missing "not documented" value. Abstractors guess instead of recording that the chart is silent.
- Free-text answers. A field that accepts any text cannot be counted later.
- Unstated source priority. Two documents disagree and the rule does not say which wins.
Checking agreement and recording who changed what are both part of keeping a dataset trustworthy. Schema Care is built around that idea for paperwork: each field it reads from a medical record comes back with a link to its spot on the page, uncertain fields wait in a review queue, and every correction is logged with who made it and when, as shown in the human review workflow. Projects that pull records from outside facilities before abstraction start can find more in the records retrieval and review category.