athenahealth Document Import: From Paper to EHR

athenahealth's document model is one of the more demanding among the major EHRs. The system expects documents to land on a specific patient, with a specific document class, a date, and (often) a routed task for clinical review. A bulk import that does not satisfy those requirements ends up creating a queue of work for the practice rather than retiring it.

This post walks through what a clean athenahealth import actually looks like.

athenahealth's document classification

athenahealth uses a document class taxonomy that includes (varies by practice configuration):

• Clinical Document (with subtypes)
• Lab Result
• Imaging Result
• Prescription
• Referral
• Consent Form
• Patient Correspondence
• Encounter Document
• Administrative

Each class has implications for how the document is routed inside the practice. A document classified as "Clinical Document" may end up on a provider's review queue. A document classified as "Administrative" stays in the chart but does not generate a task.

For a bulk import of historical records, classification matters because the wrong class can flood a provider's review queue with documents from years ago.

The right import target for historical records

For digitization of pre-existing paper archives, the practice should agree in advance:

• Historical records should typically be classified in a way that does not generate a clinical review task. Otherwise the practice will have to wade through years of imported documents.
• The document date should reflect the original document date, not the import date. This matters for chart chronology.
• The patient match must be exact. Documents on the wrong patient are a HIPAA incident waiting to happen.

The right classification is often a custom "Historical Record" class that stays in the chart but does not route to anyone.

What athenahealth's import workflow requires

athenahealth supports document import through:

• The athenaClinicals UI for individual document uploads (slow for bulk).
• API-driven imports via athenahealth's developer tools (the path for any meaningful volume).
• HL7 message-based imports for established integrations.

For a paper digitization project, the practical path is API-driven import. The scanning vendor produces files plus a manifest, and an integration partner (or the vendor directly, if equipped) drives the API import.

What goes in the manifest

A typical athenahealth import manifest needs:

• athenahealth Patient ID (the internal identifier; not the patient name).
• Document class (mapped to athenahealth's class taxonomy).
• Document date (the original date of the paper record).
• Provider association (if applicable; some documents are routed to specific providers).
• Document title (human-readable identifier).
• File path (where the actual PDF or image lives).

Without all six, the import either fails or lands the document in a default state that requires manual intervention.

Patient ID resolution

The hardest part of any athenahealth import is patient ID resolution. Old paper charts identify patients by name, sometimes with DOB, sometimes with an old chart number that no longer matches athenahealth's IDs.

The standard workflow:

1. Extract patient identity from each document (name, DOB, MRN, address, whatever is on the paper).
2. Match against athenahealth's patient database using multiple data points.
3. Score each match based on the strength of the data points that aligned.
4. Auto-import high-confidence matches. Flag medium and low-confidence matches for human review.
5. Resolve flagged matches with a staff member who knows the practice's history.

A scanning vendor that skips the flagging step and auto-imports everything will produce a chart database with documents on wrong patients. This is a critical failure mode.

Verification after import

Before signing off on the project, the practice should:

• Audit a random sample of imported documents to verify they landed on the correct patient and document class.
• Confirm that document dates reflect original document dates, not import dates.
• Confirm that the import did not flood provider review queues.
• Verify the count of imported documents against the count of source PDFs.

If any of these audits fail, the issue should be surfaced and corrected before the project is marked complete.

What ArchiveBridge does about this

ArchiveBridge digitizes medical archives onsite and delivers them in athenahealth-importable form, with patient ID resolution, document class mapping, and a confidence-scored match report. We coordinate with the practice on document classification choices before the import to avoid flooding clinical review queues.

Request a quote and we will scope the project for your athenahealth instance.