Schema Care

Medical Record Review Software: Features That Matter

By Schema CarePublished Updated

Medical record review software reads long sets of patient records and helps a reviewer find, organize and verify what matters in them. The features that matter most are full-text search, a link from every extracted fact to its source page, duplicate detection, indexing by date and type, and exports. Test each one on your own records before you buy.

Features that matter in medical record review software

The features that matter in medical record review software are the ones that save a reviewer time without hiding where a fact came from: search across every page, a source page link for each extracted fact, duplicate page detection, indexing by date, provider and document type, and exports a reviewer can work from. Everything else is secondary.

Search. A reviewer needs to find every mention of a term across thousands of pages, including scanned pages. Search only works on scanned pages after they have been through text recognition, so ask how the tool handles faint faxes and handwriting, and whether it shows you pages where recognition failed.

Source page links. Each extracted date, diagnosis or value should open the page it came from. This feature has its own section below, because it decides whether the output can be trusted.

Deduplication. Records gathered from several sources repeat pages. Software should flag exact and near duplicates and let a person decide which copy to keep. Which copy to keep is a judgment covered in the guide to which duplicate page you should keep.

Indexing. The tool should sort pages by encounter date, provider, facility and document type, so a reviewer can jump to "all imaging reports" or "everything from March". An index is only as good as its dates, so test it on records with undated pages.

Exports. Reviewers rarely finish inside the tool. They need to take a chronology, an index or a set of flagged pages into a report. Ask what you can export and whether each exported fact keeps its page reference.

A feature checklist for your trial

The table below lists each feature, why it matters and a test you can run in a trial. The test values are examples.

FeatureWhy it mattersHow to test it in a trial
Full-text search on scanned pagesFinds facts buried in faxes and old chartsSearch for a term you know appears on a faxed page, such as a medication name; check that it is found
Source page link for every factLets a reviewer verify in one clickClick 20 extracted facts at random; count how many open the right page and spot
Confidence score per fieldShows which values the tool is unsure ofFind a blurred value; check that it scores lower than a clear one
Review queue for uncertain fieldsSends doubtful values to a personSet a threshold; confirm low-scoring fields land in a queue, not in the output
Duplicate page detectionRemoves repeated pages without losing evidenceInclude the same note twice, once faxed; check both are flagged and both remain available
Indexing by date and document typeLets a reviewer navigate by encounterInclude an undated page; see how the tool labels it
Correction logShows who changed a value and whenCorrect a field; check the log names you and the time
Export with page referencesKeeps facts traceable outside the toolExport a list; confirm each row carries its page number

A tool that passes every row on clean, typed records may still fail on the messy pages that make up a real record set. Build the test set to include both.

Does review software replace a human medical record reviewer?

No. Medical record review software speeds up finding and organizing facts, but a person still decides what the record means and confirms any value the software is unsure of. Good software makes that split explicit by scoring its confidence in each field and sending the uncertain ones to a reviewer instead of passing them through.

The reason is the cost of a wrong value. An encounter date read as 03/08 instead of 08/03 can move a visit into the wrong part of a chronology. A dosage read wrongly can change how a case is understood. Software that reports every value with equal certainty hides those risks.

A confidence score is the software's estimate of how likely a value is to be right. The reviewer, or the team, sets a threshold. Values above it go straight into the output. Values below it go to a review queue, where a person sees the value next to the page and approves or corrects it. How to set those thresholds and run the queue is covered in the human review category.

What the reviewer brings is judgment the software does not have. A reviewer notices that two notes from the same day contradict each other, that a prior history matters, or that a page belongs to a different patient. Those are the findings a report depends on.

A source page link is a pointer from each extracted fact in medical record review software to the page, and ideally the spot on the page, where the fact appears. It lets a reviewer verify a value in one click instead of searching a thousand-page file, and it lets anyone reading the output check it later.

Source links matter for three reasons.

Verification. A reviewer cannot confirm a value without seeing it in context. A date pulled from a fax header means something different from the same date in a note's body. The link shows which it was.

Citation. Work products built from records, such as a chronology for a legal case, cite pages. If the software keeps page references for every fact, the citations come for free. The method for building one is in the guide to building a medical chronology for a personal injury case.

Correction. When a reviewer finds an error, the link shows whether the software misread the page or the page itself is wrong. Those are different problems with different fixes.

Test this feature hard. Pick facts at random, not the ones the vendor's demo highlights. Check that the link goes to the right page, not just the right document, and that it still works after you export.

Schema Care is built around this idea for the medical records it reads: each encounter date, problem list entry, allergy and vital sign comes back with a confidence score and a link to where it sits on the page, and fields below the customer's threshold go to a person. It reads records you already have and does not retrieve them from providers.

How do you trial review software on your own records?

To trial review software on your own records, start with a de-identified sample set that reflects your real files, build a known answer set for it by hand, then run the tool and compare its output with your answers field by field. This shows where the tool is right, where it is unsure and where it is wrong without guessing.

Start de-identified. Whether real patient records can go to a vendor before a business associate agreement is signed is a question for your privacy officer, so a trial usually starts without them. The HIPAA Privacy Rule's de-identification standard, in 45 CFR 164.514 on the eCFR, paragraphs (a) and (b), describes when health information no longer identifies an individual, either by expert determination or by removing a listed set of identifiers such as names and geographic subdivisions. Your privacy officer should decide which method applies.

Pick realistic pages. Include typed EHR printouts, faxes, handwritten notes, outside records and duplicates. A set of 50 to 100 pages from several sources is enough to show patterns. Keep the mix close to what you actually receive.

Build the answer set. For each page, write down the facts you expect the tool to find: dates, providers, diagnoses, values. Have a second person check it. This is the yardstick for every tool you test.

Compare field by field. Count the facts the tool found correctly, found wrongly, missed and flagged as uncertain. Wrong values the tool was confident about are the most serious result, because they would skip review.

Time the reviewer. Measure how long a reviewer takes to finish the set with the tool, including review of flagged fields, against doing it by hand.

Trial mistakes to avoid

A few habits make a trial look better than the tool will perform later.

Testing on the vendor's samples. Demo files are chosen because they work. Your own faxes and outside records are the real test.

Counting only what was found. A tool that finds 95 of 100 facts but invents five more is worse than one that finds 90 and flags the other ten as uncertain. Count wrong values separately from missed ones.

Skipping the edge cases. Include an undated page, a page from a different patient filed in the wrong set, and a note with a correction written in the margin. These are the pages that cause real errors.

Letting one person judge. Have two reviewers use the tool on the same set. If they reach different results, the tool's output is not as clear as it looked.

Some tools let you start on de-identified sample documents at no cost and sign a BAA only when you move to paid use, so check each vendor's plans before you plan the trial. One example is the Free plan in Schema Care's plans and pricing.

When medical record review software is overkill

Medical record review software is overkill when your record sets are small and infrequent: a few short files a month that one person can read in an hour. In that case the setup, training and subscription cost more than the time saved, and a good PDF reader with search may be enough.

A few signs point toward not buying yet.

Low volume. If you review a handful of records a month and each is under 100 pages, a reviewer with a checklist works well.

Mostly typed, single-source records. Records printed from one EHR are already searchable and ordered. The features that justify software, such as deduplication and indexing across sources, add little.

No repeatable output. Software pays off when the same kind of output, such as a chronology or a summary table, is produced again and again. One-off questions do not need a system.

Retrieval is the real bottleneck. If the delay is getting records from providers in the first place, review software does not solve it. That process is explained in the guide to medical records retrieval.

Revisit the decision when volume grows, when records start arriving from many sources, or when a second reviewer joins and you need to see who changed what.

All posts in Records Retrieval and Review