Building an OCR and Scoring Pipeline for Home Sleep Test Reports: Device Formats, AHI Extraction, and Physician Review Queues

The Bottleneck in Sleep Diagnostics

Home sleep tests (HSTs) were designed to move sleep apnea diagnosis out of expensive lab facilities and into patients' bedrooms. The hardware is good. The workflow around the hardware is not. A typical manual workflow looks like this: patient returns the device, a tech downloads data from the SD card, runs it through vendor-specific desktop software to produce a report PDF, prints the PDF, puts it in the physician's paper queue, the physician hand-scores the study, dictates an interpretation, and a transcriptionist types it up. Turnaround time in this workflow is commonly 3-4 weeks.

Most of those steps are either data transformation (device data to report PDF, report PDF to structured score, structured score to narrative interpretation) or queue management (waiting for the physician, waiting for the transcriptionist). Both are good candidates for automation. The steps that genuinely require clinical judgment -- reviewing anomalous patterns, adjusting severity classification in borderline cases -- are a small fraction of the total time but cannot be automated away. The goal was to automate the data transformation and queue management, then present the physician with a pre-processed study they can review and sign in minutes.

Why Turnaround Time Matters

A 3-4 week gap between test and results creates a practical problem: patients disengage. If someone takes a sleep test and does not hear back for a month, a significant percentage never return for the follow-up visit. They moved on, forgot, or assumed no news meant no problem. Shortening turnaround to a few days keeps patients in the diagnostic pipeline long enough to reach treatment, which is the whole point.

OCR Pipeline for Sleep Study Reports

The first challenge was historical data. The practice had years of sleep study reports stored as PDFs generated by three different device manufacturers. These PDFs contain the diagnostic data (AHI, oxygen desaturation index, sleep staging summaries) but in completely different layouts, fonts, and table structures. Digitizing this archive was necessary for training the scoring engine and establishing baseline metrics.

Document Classification

Before extracting data from a report, you need to know which vendor produced it. A WatchPAT report puts the AHI in a different location and format than a Nox T3 report. We trained a lightweight CNN (based on EfficientNet-B0 at 512x512 input resolution) to classify the first page of each PDF into one of three vendor categories. The model identifies the report source from visual layout cues -- logo placement, table structure, header formatting -- with about 99% accuracy on our test set. Classification takes about 40ms per page on a GPU.

Once classified, the PDF is routed to a vendor-specific extraction pipeline. Each pipeline defines the expected spatial layout for that vendor's report format: which page the summary table is on, which row and column contains the AHI, where the oxygen desaturation data lives, and so on. We defined extraction templates for 47 data fields across all three report formats.

Tesseract OCR with Custom Training

We used Tesseract 5.x with LSTM-based recognition. Out-of-the-box accuracy on these reports was around 89%, which sounds high until you realize that a single wrong digit in an AHI score (reading "31.4" as "31.9" or "51.4") changes the clinical meaning. We fine-tuned Tesseract on manually transcribed report images specific to each vendor's fonts and table formatting.

After fine-tuning, field-level accuracy reached about 97% overall, with numeric fields (AHI, ODI, SpO2 nadir) slightly higher at around 98%. The errors that remained were concentrated in free-text physician notes and handwritten annotations, which were not needed for the automated scoring pipeline.

Confidence-Based Routing

Not every extraction is equally reliable. We assign a confidence score to each extracted field based on OCR character-level confidence and regex pattern match strength.

• High confidence (>0.95): Accepted automatically. This covers about 89% of all extracted fields.
• Medium confidence (0.80-0.95): Sent to a technician review queue with the extracted value pre-populated and the source image region highlighted. About 8% of fields.
• Low confidence (

This tiered approach concentrates human effort on genuinely ambiguous cases. In practice, technicians spent about 10-15 minutes per day processing the review queue, down from several hours of full manual data entry.

Automated Scoring Engine

The scoring engine takes raw HST device data and produces a preliminary interpretation. It does not replace the physician -- it pre-processes the data so the physician can review and sign quickly instead of scoring from scratch. For Type III and Type IV home sleep tests, the signal processing is well-defined enough that rule-based scoring works. We did not need deep learning for this.

Signal Processing Pipeline

Raw HST data includes airflow (nasal pressure and thermistor), pulse oximetry (SpO2 and pulse rate), respiratory effort (chest and abdominal RIP belts), and body position. Each channel goes through signal conditioning: bandpass filtering to remove out-of-band noise, artifact detection (signal dropout from sensor displacement, motion artifacts), and baseline normalization.

Respiratory event detection follows AASM (American Academy of Sleep Medicine) scoring criteria. Apneas: 90% or greater airflow reduction lasting at least 10 seconds. Hypopneas: 30% or greater airflow reduction with a 3% or greater oxygen desaturation or an arousal. Events are classified as obstructive, central, or mixed based on respiratory effort channel patterns. The AHI is computed as total events divided by total recording time minus artifact periods.

Concordance with Physician Scoring

We validated the engine against 500 studies scored independently by two board-certified sleep physicians. The AHI correlation between automated and physician consensus scores was 0.97 (Pearson). Event-level agreement (apnea vs. hypopnea classification) was about 94%. The engine tended to over-detect hypopneas slightly in patients with low-amplitude baseline breathing. We added a calibration step that estimates the patient's baseline from the first 30 minutes of clean recording, which reduced the over-detection.

Severity classification agreement (normal vs. mild vs. moderate vs. severe) was about 97%. The disagreements were exclusively at the mild-moderate boundary (AHI 14-16 range), which is a known zone of low inter-physician agreement as well. For borderline cases, the engine flags the study for extended physician review rather than committing to a classification.

Physician Review Workflow

Automated scoring does not eliminate the physician from the loop. A signed physician interpretation is required for a valid sleep study diagnosis. The design goal was to make the review process as efficient as possible: present the physician with a complete, pre-populated interpretation that they can approve, modify, or reject.

Pre-Populated Interpretation Templates

The review interface presents a narrative interpretation generated from physician-authored templates with dynamic data injection. For example: "This home sleep test demonstrates [severe] obstructive sleep apnea with an apnea-hypopnea index of [42.3] events per hour. The oxygen desaturation index was [38.1] events per hour with a nadir SpO2 of [78]%. OSA was [significantly worse in the supine position] with a supine AHI of [61.2] compared to a non-supine AHI of [18.4]."

The templates were written by the practice's own sleep physicians. This was important -- the generated text reads like something each physician would actually write because it was derived from their past interpretations. In practice, physicians signed without modification about 73% of the time. The other 27% involved minor edits: adjusting the narrative, adding clinical context, or modifying the severity descriptor in borderline cases.

Anomaly Highlighting

The interface flags patterns that warrant extra attention. Cheyne-Stokes breathing patterns suggest possible central sleep apnea or underlying heart failure. Prolonged desaturations below 80% suggest possible obesity hypoventilation syndrome. These are surfaced as non-blocking alerts -- they do not prevent the physician from signing, but they ensure unusual findings are visible during a rapid review.

• Review time: Dropped from about 25 minutes per study (manual scoring from scratch) to about 4 minutes (review and sign pre-populated interpretation).
• Modification rate: 27% of studies had at least one physician edit, typically to the narrative text.
• Override rate: 1.8% of automated severity classifications were changed by the physician, almost always in the mild-moderate borderline zone.

Device Integration and Data Ingestion

The manual SD card workflow was the biggest time bottleneck. A technician had to collect the device, pull the SD card, launch vendor software, export data, and upload it. This took 15-20 minutes per device and was the reason studies sat in queue for days.

Automated Data Transfer

We implemented automatic data upload for three HST device families. WatchPAT and Nox T3 support Bluetooth, so we built a clinic-side docking station app that detects returned devices and downloads data automatically. SleepView requires USB, so we deployed a lightweight Windows service that monitors USB ports and initiates transfer on device connection. In both cases, the data goes directly into the processing pipeline without manual intervention.

For patients who cannot return devices promptly, we also set up a cellular upload pathway. A cellular gateway attached to the device uploads study data the morning after the test completes. This eliminated the device return step for a subset of tests, reducing time from test completion to processing from several days to a few hours.

Data Normalization Across Vendors

Each vendor uses proprietary data formats. WatchPAT exports EDF+ files with peripheral arterial tone signals. Nox T3 uses its own .ndb binary format. SleepView exports XML summaries with raw signals in a separate binary file. We wrote format-specific parsers that extract standardized signal channels into a common data model, so the scoring engine processes all devices through a single pipeline.

The normalization is not trivial. Sampling rates differ (100 Hz for WatchPAT oximetry vs. 200 Hz for Nox T3). Amplitude scaling varies. Sensor types measure the same physiological signal differently (PAT vs. nasal pressure for airflow detection). We resample to a common 200 Hz rate and normalize amplitudes to physiological reference ranges. For the PAT-based WatchPAT data, we use vendor-published conversion algorithms to derive equivalent airflow metrics.

Referral Pipeline Optimization

Faster scoring is only useful if patients actually move from diagnosis to treatment. The referral pipeline -- from primary care referral through HST completion through diagnosis through CPAP initiation -- has multiple drop-off points. We modeled it as an explicit state machine to make the drop-offs visible and addressable.

Referral State Machine

The state machine has these states: referral_received, patient_contacted, device_shipped, device_delivered, test_completed, data_uploaded, study_scored, physician_reviewed, results_delivered, follow_up_scheduled, treatment_initiated. Each transition has a configurable timeout. If a patient sits in "device_delivered" for more than 7 days without transitioning to "test_completed," the system generates a follow-up task. If "results_delivered" does not transition to "follow_up_scheduled" within 5 days, a scheduling reminder fires.

This model makes the pipeline legible. Before, patients who fell out of the process just disappeared. Now, every patient in the system is in a defined state with a defined expected next action and a timeout. The operations team can see exactly how many patients are in each state, where the bottlenecks are, and which individual patients are stuck.

Automated Transitions and Notifications

The moment a physician signs a study interpretation, the state machine transitions to "results_delivered" and triggers a patient notification (SMS or email) with a link to schedule a follow-up. For patients diagnosed with moderate-to-severe sleep apnea (AHI > 15), the system also pre-schedules a CPAP setup appointment and sends educational materials about what to expect. For treatment initiation, we integrated with DME suppliers to transmit prescriptions electronically rather than by fax.

• Referral-to-test time: Dropped from about 2 weeks (phone scheduling, device pickup) to about 3 days (online scheduling, direct-to-patient shipping).
• Diagnosis-to-treatment time: Dropped from about 5 weeks to about 10 days via automated scheduling and electronic DME ordering.
• Pipeline drop-off rate: Decreased from about 34% (between diagnosis and treatment initiation) to about 10%. Most of the improvement came from making drop-offs visible and actionable rather than from any clever automation.

Outcomes and Operational Impact

The system rolled out across three locations over 6 weeks, with a 2-week parallel-run period where both automated and manual workflows operated simultaneously. This let us validate concordance in production before deprecating the manual process.

• Turnaround time: Dropped from about 4 weeks to about 72 hours for the standard pathway. Studies from cellular-enabled devices averaged about 48 hours.
• Physician time per study: Down from about 25 minutes to about 4 minutes. Across several hundred studies per month, this freed up substantial physician time.
• Technician time for data processing: Down from several hours per day to about 10-15 minutes per day for the confidence review queue.
• Study volume capacity: The automated pipeline removed the processing bottleneck that had previously limited how many studies the practice could handle per month. Volume increased significantly without adding staff.
• Patient retention: The percentage of patients who completed a test but never returned for follow-up dropped from about 18% to about 4-5%. Faster results and automated scheduling kept patients in the pipeline.

Open Problems and Future Work

The scoring engine currently handles Type III and Type IV home sleep tests. Expanding to Type II portable polysomnography would add EEG channels for sleep staging, which is a substantially harder signal processing problem. The current architecture supports additional channels, but the scoring algorithms would need to be extended. We are evaluating temporal convolutional networks for the sleep staging component, though we have not validated this beyond early prototyping.

The OCR pipeline also has room to improve. Some newer report formats use embedded charts and graphs that Tesseract handles poorly. We are experimenting with Vision Transformer-based approaches for these layouts. Early results show a modest accuracy improvement on chart-embedded numeric values, but the processing time cost is significantly higher.