When you choose medical record abstraction software, check four things before price: every value links to its spot on the source page, every value carries a confidence score, uncertain values wait in a review queue, and every approval and correction is logged. Then pilot the software on de-identified or fictional charts before any real record goes in.
What medical record abstraction software should do
Medical record abstraction software reads a chart and pulls named data elements into fields: dates, codes, medications, allergies, vital signs or whatever a data dictionary asks for. Its core functions are finding each element, reading its value, showing where it came from, scoring how sure it is, and routing doubtful values to a person.
Abstraction is the job of turning a chart into answers to set questions. A person who does this by hand is a medical record abstractor; what that role involves day to day is covered in what a medical record abstractor does. Software takes over the reading and the first draft of each answer. A person still owns the final value.
Five functions separate useful abstraction software from a basic OCR tool:
- Element definitions. You can define the fields you need, with a name, a type and a rule for each, such as "encounter date, a date, from the note header."
- Multi-page handling. It can work across a long chart, find the right page for each element, and cope with pages out of order.
- Traceability. Each value links to the page and position it was read from.
- Scoring and routing. Each value has a confidence score, and values under a threshold go to review instead of into your system.
- Logging. Each review decision is recorded with who made it and when.
The software should not interpret clinical content. It records what the chart says, such as "penicillin" on an allergy line. It does not decide whether an entry is significant or what should be done about it.
The buyer checklist
Use this list in every vendor conversation. Each line is a requirement, the question that tests it, and what a clear answer sounds like.
| Requirement | Question to ask the vendor | A clear answer sounds like |
|---|---|---|
| Custom fields | Can we define our own data elements and rules? | "Yes, per document type, without code changes." |
| Source link per value | Does every value open the page with the passage highlighted? | "Every value, including ones a reviewer corrected." |
| Confidence per value | Is there a score on each field, not just each page? | "Each field has its own score." |
| Threshold you set | Who decides the score below which a field goes to review? | "You do, and you can change it." |
| Review queue | What does a reviewer see for each uncertain field? | "The value, the score and the highlighted page." |
| Correction logging | What is recorded when a reviewer changes a value? | "Old value, new value, who and when." |
| Missing elements | How does the software report an element it could not find? | "As an empty field flagged for review." |
| Test on fictional charts | Can we run a trial on de-identified or fictional charts? | "Yes, before any agreement for live data." |
| Business associate agreement | Will you sign a BAA before live charts? | "Yes, before any real patient data." |
| Data export | Can we take every value, link and log with us? | "Yes, in a documented format." |
Source links and confidence scores in abstraction software
Source links and confidence scores are how you check that abstraction software is traceable and honest about doubt. A source link ties each value to the page and position it came from. A confidence score says how sure the software is about that value. Together they decide which values a person checks and how fast.
Test source links directly. Open twenty values at random and click each link. The page should open with the passage highlighted, and the passage should say what the field says. Then try the hard cases: a value the reviewer corrected, a value read from a handwritten page, and a value that combines two parts of a page, such as a date in the header and a time in the body. Each should still link.
Test confidence scores by comparing them with errors. In a trial, list the values the software got wrong and look at their scores. Useful scores put most wrong values at the low end. If wrong values carry high scores as often as right ones, the score cannot be used to decide what skips review, and every value needs checking.
Ask the vendor how the score is defined. A score per page or per document is less useful than a score per field, because one bad field can hide on a page of good ones. Ask whether the score changes when the software has to guess what a number means, such as a bare "120" with no label.
How to set the threshold, and how to adjust it as you learn which fields fail, is covered in depth in the human review category.
Review queues in medical chart review software
A review queue in medical chart review software is the list of fields waiting for a person. Uncertain fields should reach a reviewer with the value, its score and the original page already open at the right spot. The reviewer approves or corrects the field, and the decision is saved before the value reaches your system.
A well-built queue keeps the reviewer on one task at a time. The reviewer should not have to search the chart, switch windows or retype a value that is already correct. The common action, approving a correct value, should be the fastest one.
Questions to ask about the queue:
- Routing. Can fields be sent to different reviewers by document type, field type or skill?
- Holding. Is a field held out of your system until it is approved, or does it flow through and get fixed later?
- Ordering. Can the queue be sorted by due date, chart or field type?
- Counts. Can you see how many fields are waiting, how old they are and who is working them?
- Second review. Can a sample of approved fields go to a second reviewer?
The queue also shapes the medical record review process as a whole. A team that sees the same field corrected often can fix the element definition or raise the threshold for that field. A queue that reports corrections by field type turns review into a source of improvements instead of a fixed cost.
What audit trail should abstraction software keep?
Abstraction software should keep an audit trail that records, for every field, the value the software read, the value that was finally approved, who approved or corrected it, and when. A trail like this lets you answer where any number came from and who signed off on it, months after the chart was processed.
At minimum, each entry should hold:
- the chart and page the value came from, with its position;
- the value the software returned and its confidence score;
- the reviewer's decision: approved, corrected or rejected;
- the corrected value, if any;
- the reviewer's identity and the date and time.
Beyond review decisions, ask what else is logged. Views and exports matter too. The HIPAA Security Rule's audit controls standard, in 45 CFR 164.312(b) on the eCFR, calls for "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." The rule does not prescribe a log format, so ask the vendor what is recorded and how long it is kept.
Ask too whether you can export the audit trail and read it without the vendor's software. A log you cannot take with you is only useful while the contract lasts.
Schema Care logs each approval and correction with who made it and when. Broader access and audit logs covering every view, edit and export are listed as in progress, and an audit log with exports is listed as a Clinic plan feature in the plans and pricing section.
How do you pilot abstraction software without real patient data?
You pilot abstraction software without real patient data by running it on de-identified charts or on fictional charts built for the test. Either way, you need charts whose correct answers you already know, so you can score the software field by field. Real charts wait until a business associate agreement is signed.
De-identification has a specific meaning under HIPAA. One of the two methods in 45 CFR 164.514(b) on the eCFR removes a listed set of identifiers, including names, geographic subdivisions smaller than a state, all elements of dates except the year, medical record numbers and health plan beneficiary numbers. Removing dates matters for abstraction tests, because dates are often the fields you most need to check. Shifted or invented dates in a fictional chart solve that.
A pilot plan in four steps:
- Build the test set. Ten to twenty charts that resemble your work, including long charts, handwritten pages and poor scans. A fictional example: "Chart 7, patient Avery Example, MRN EX-0007, 180 pages, three outside records."
- Write the answer key. Have an experienced abstractor fill in every element for every chart before the software runs.
- Run and review. Process the charts, work the review queue as you would in production, and record the time spent.
- Score. Compare the approved values with the answer key. Count errors that passed review, errors caught in review, missing elements and links that pointed to the wrong place.
Keep the pilot honest by including charts that look like your hardest cases, not only clean ones. A pilot on tidy typed charts tells you little about a stack of faxed handwritten notes.
When abstraction software is the wrong purchase
Abstraction software is the wrong purchase when volume is too low to justify setup, when the data elements change every project, or when nobody on staff can own the review queue. In those cases an outside abstraction service, or a careful manual process with good forms, may cost less and carry less risk.
Software brings fixed costs: defining elements, training reviewers, running a pilot and keeping the setup current as forms change. A team that abstracts a few dozen charts a year may never earn those costs back. A project that needs a new data dictionary every few months pays the setup cost again each time.
Software also assumes someone reviews. If the queue fills and nobody works it, values either wait forever or flow through unchecked. Before buying, name the person who will own the queue and estimate the hours they will spend on it.
Signs a service or manual process fits better:
- the work is a one-off project with a fixed end date;
- the charts are few but very long and complex;
- the team has no spare reviewer time;
- the project's sponsor sets its own rules for who may abstract, and your staff do not meet them.
The costs on each side of that choice, and the contract terms to ask an outside team for, are covered in the guide to outsourced vs in-house chart abstraction costs.