Problem list extraction from charts means copying each documented condition into its own record: the problem as written, its status (active, resolved or history), any code printed beside it, the date it was noted, and the document and page it came from. You record what the chart says, never what you think it should say.
What belongs on an extracted problem list?
An extracted problem list is a set of records, one per condition, diagnosis or reason for care that a chart documents. Each record names the problem in the chart's own words and adds the facts that let someone use it later: status, dates, any printed code and the exact place in the chart where it was found.
The federal data standard for health records gives a useful starting point. The ONC USCDI Problems data class defines a problem as a "Condition, diagnosis, or reason for seeking medical attention." In the published USCDI v6, that class also lists a Date of Diagnosis, a Date of Onset and a Date of Resolution, and names SNOMED CT and ICD-10-CM as the vocabularies for coding problems.
For extraction work from paper or scanned charts, a practical record has these fields:
| Field | What it holds | Example value (fictional) |
|---|---|---|
| Problem text | The words exactly as charted | "HTN, well controlled" |
| Status | Active, resolved, history or unknown | Active |
| Code | The code printed with the entry, if any | I10 |
| Code system | Which code set the code belongs to | ICD-10-CM |
| Date noted | The date the document gives for the entry | 2024-03-11 |
| Resolution date | The date the chart says it ended, if any | blank |
| Source | Document type, date and page | Office visit note, 2024-03-11, page 2 |
| Qualifier | "History of", "rule out", "suspected" and similar | blank |
Two choices in that table matter more than they look. First, keep the original text even when you also store a code. A reviewer, an auditor or a later project may disagree with a code, and the charted words are the only evidence of what the clinician wrote. Second, keep the qualifier in its own field. A word like "suspected" changes what the entry means, and losing it when the text is shortened is a common source of bad data.
Leave out anything the chart does not state. If a note mentions a prescription that is often linked to a condition, the extracted list still has no entry for that condition unless the chart names it. Inference is clinical work, and problem list extraction is paperwork.
Active, resolved and historical problems in charts
Problem status says whether a documented condition is current, has ended, or is part of the patient's past. Charts show it through a status column, "active" and "resolved" headings, words like "history of", or a resolution date. The extractor records the status the chart gives, and marks it unknown when none is given.
Coded health data uses a fixed set of status values. The HL7 FHIR R4 Condition resource defines a clinical status with the values active, recurrence, relapse, inactive, remission and resolved. It keeps a separate verification status (unconfirmed, provisional, differential, confirmed, refuted and entered-in-error), and a category that separates a problem-list-item from an encounter-diagnosis. You do not need FHIR to use those ideas. They are a good model for the fields a spreadsheet or database should have.
A short status vocabulary works best for chart abstraction:
- Active: the chart lists the problem as current.
- Resolved: the chart says it ended, or gives a resolution date.
- History: the chart labels it as past, for example "history of".
- Unknown: the chart lists the problem with no status at all.
Status changes over time, and a long chart can show the same problem in two states. A problem list printed in 2023 may show a condition as active, and a note from 2025 may call it resolved. Do not overwrite the older entry. Record both, each with its own source and date, so the later reader can see the change. If you must produce a single current list, take the status from the most recent dated document and keep the older entries linked to it.
Dates need the same care. "Onset 2019" on a problem list is a different fact from the date of the visit where it was written. Store the date the chart gives for the problem, and keep the document's own date in the source field.
Where ICD-10 and CPT codes appear in clinical documents
ICD-10 and CPT codes appear in clinical documents wherever a chart is close to billing: printed problem lists, assessment and plan sections, visit summaries, superbills, encounter forms and discharge paperwork. ICD-10-CM codes describe diagnoses and reasons for a visit. CPT codes describe services and procedures, so they rarely belong on a problem list at all.
The two code sets do different jobs. The CDC and CMS ICD-10-CM Official Guidelines for Coding and Reporting describe ICD-10-CM as a classification "for classifying diagnoses and reason for visits in all health care settings." The CMS page on the HCPCS code system describes CPT as a numeric system maintained by the American Medical Association, used primarily to identify medical services and procedures.
That difference gives a simple sorting rule. A code made of a letter, two digits and often a decimal point and more characters, such as I10 or E11.9, is an ICD-10-CM diagnosis code and can sit on a problem list entry. A five-digit numeric code next to a visit or procedure is a CPT code and belongs with the encounter or the service, not with a problem. When a superbill prints both on one page, extract them into separate tables.
You can confirm that a printed diagnosis code exists and read its official title with the NLM Clinical Table Search Service ICD-10-CM lookup. That check catches OCR damage, such as a letter O read as a zero. It does not tell you whether the code was the right choice for the patient, and that judgment is not part of extraction.
How codes are carried onto claim forms, with diagnosis pointers and line items, is covered in the claims and medical bills category.
A worked example: one fictional chart, three documents
The patient is fictional: Dana Okafor, chart number 55-1029 (example). Her chart holds three documents: a printed problem list dated 2023-06-02, an office visit note dated 2025-01-14, and a superbill from the same visit. All values below are invented for this example; the codes and their titles were checked against the NLM lookup.
| Problem text as charted | Status | Code | Source |
|---|---|---|---|
| Essential hypertension | Active | I10 | Problem list, 2023-06-02, page 1 |
| Type 2 diabetes mellitus without complications | Active | E11.9 | Problem list, 2023-06-02, page 1 |
| Asthma | Resolved (per note) | J45.909 on the 2023 list | Problem list, page 1; visit note, 2025-01-14, page 2 |
| Former smoker, quit 2015 | History | Z87.891 | Visit note, 2025-01-14, page 1 |
| GERD | Active | K21.9 | Superbill, 2025-01-14, page 1 |
| Rule out sleep apnea | Not a problem entry; qualifier "rule out" | none | Visit note, 2025-01-14, page 2 |
Each row points to a page. The asthma row shows a status change between two documents, with both sources kept. The last row shows an entry that looks like a problem but is a question the clinician has not yet answered. The superbill also printed a CPT code for the office visit, which went to the encounter table, not here.
Do charted codes always match the problem list text?
Charted codes do not always match the problem list text. A printed code can be less specific than the words, out of date, or attached to the wrong line. The extractor's job is to record both the text and the code as written, and to flag the mismatch for a person.
Mismatches come in a few familiar forms:
- Specificity gaps. The text says "type 2 diabetes with kidney involvement" and the code beside it is the general E11.9, whose official title is "Type 2 diabetes mellitus without complications". The words and the code title disagree.
- Stale codes. A problem list printed years ago may carry a code that was later replaced. The official guidelines are reissued for each fiscal year, so record which year's document a coding check relied on.
- Wrong row. On a dense printed list, OCR or a person keying the page can attach a code to the line above or below.
- Free text only. Many handwritten or dictated notes name problems with no code at all. Leave the code field blank. Do not look one up and add it as if the chart had printed it.
A good extraction workflow never repairs these on its own. It keeps the charted text, the charted code and the official title of that code side by side, and it sends rows where they disagree to review. A coder or clinician can decide what the record should say. The extracted data should show what the chart said.
This is the kind of field where page-level evidence helps most. Schema Care reads problem lists from medical records, attaches each value to the spot on the page it came from, and holds back any field it is unsure of so a reviewer can compare it with the scan, as the list of documents Schema Care reads describes.
Problem list entries that look like diagnoses but are not
Some problem list entries name a condition without stating that the patient has it. "Rule out", "suspected", "probable", "history of", "family history of" and "negative for" all change the meaning of the words that follow. Extracting the condition name without its qualifier turns an open question or a past event into a current diagnosis.
Coding rules show how much these words matter. The outpatient section of the ICD-10-CM Official Guidelines says not to code diagnoses documented as "probable", "suspected," "questionable," "rule out," and similar terms, and to code to the highest degree of certainty for that visit instead. The same document notes that inpatient settings follow a different rule. For extraction, the lesson is simpler: keep the qualifier, and do not decide what it means for coding.
History entries need their own handling. The guidelines say personal history codes "explain a patient's past medical condition that no longer exists and is not receiving any treatment," and family history codes cover a condition in a family member. On an extracted list, "history of" goes into the status or qualifier field, and "family history of" should not be filed as the patient's own problem at all. Put family history in a separate table if the project needs it.
Watch for these patterns as you extract:
- "Rule out": record as a qualifier; the entry is a question.
- "Suspected", "probable" or "possible": record the word as a qualifier and keep the condition text unchanged.
- "History of": record status as history.
- "Family history of" or "mother with": family history, not the patient's problem.
- "Denies" or "negative for": not a problem entry at all.
- Unfamiliar shorthand: keep it exactly as written and flag it. Expand an abbreviation only from a list your project has written down.
Negated statements in narrative notes are harder than labelled lists, because the negation can sit several words away from the condition. The guide to negation and context in unstructured clinical text covers how software handles that. Once the problem list is done, the same chart usually needs its measurements pulled; the walkthrough on vital signs extraction from scanned charts picks up there, and medication orders are covered in extracting drug strength, dose and refills from prescriptions.