For years, leaving an EHR meant negotiating with the vendor for a data extract, paying whatever it cost, and receiving whatever format the vendor chose. The Office of the National Coordinator for Health IT (ONC) addressed that with a certification criterion that requires certified health IT to export electronic health information on demand. It is one of the least-discussed and most useful guarantees a practice holds, and it is worth understanding before you need it.
What the EHI export criterion requires
The criterion, listed in the certification regulations as 170.315(b)(10), requires certified health IT to do two things. First, it must let a user, without developer assistance, export all electronic health information the system produces and electronically manages for a single patient, in a timely manner. Second, it must be able to export the full set of electronic health information for all patients, which the developer may perform on the provider's behalf. The format is the developer's choice, but it must be computable, meaning machine-readable, and the developer must publish documentation of the format publicly so that the export can be understood and used by others.
Electronic health information is defined broadly. It is the electronic protected health information in a designated record set, excluding psychotherapy notes and information compiled for legal proceedings. In practice that means clinical data, billing and payment records, and anything else used to make decisions about the patient, not just the structured summary a patient can download from a portal.
Why it exists
The criterion came from the 21st Century Cures Act final rule, which also established the information blocking regulations. Both are aimed at the same problem: data held in a system should be accessible to the patient and to the provider who cares for them, and technical or contractual barriers should not stand in the way. The EHI export criterion gives the provider a guaranteed path to its own data, which supports switching vendors, responding to patient access requests, supplying records to a successor, and meeting legal obligations, all without depending on the vendor's goodwill.
Compliance dates: Developers were required to have the criterion in place for certified products by the end of 2023. If a vendor tells you its certified product cannot perform an EHI export, ask which certified edition you are running and confirm the claim against the ONC Certified Health IT Product List.
Single-patient vs. population export
| Aspect | Single patient | All patients |
|---|---|---|
| Who initiates | A user at the practice, without vendor help | The practice requests; the developer may perform it |
| Timing | Timely; intended for routine use | Reasonable timeline agreed with the developer |
| Typical use | Patient access requests, transfers, legal requests | Vendor transition, merger, data warehouse load |
| Cost | Should be part of normal system operation | May carry a fee; information blocking rules limit unreasonable fees |
What the export looks like
Because the format is developer-defined, exports differ. Some vendors produce a package of FHIR resources, some produce a set of CSV files with a published data dictionary, and some produce a mix of structured files and rendered documents such as PDFs of scanned material. The requirement is that the format be documented publicly, so a practice can review the specification before choosing a vendor. A well-designed export keeps identifiers consistent across files, so a lab result can be tied to the encounter and the patient it belongs to, and includes metadata about who recorded what and when.
Two things are worth checking in the documentation. Does the export include attachments and scanned documents, or only structured data? And does it include audit and provenance information, which matters for legal holds and for reconstructing a record's history after a migration?
When a practice would use it
- Switching EHRs: The population export is the source of truth for the migration. The successor vendor will still map and convert, but the practice controls the input.
- Merger or acquisition: Consolidating records from an acquired practice into one system.
- Patient access requests: A patient who asks for "everything" is entitled to the designated record set, and the single-patient export is the fastest way to produce it in electronic form.
- Legal and regulatory requests: Subpoenas and investigations often require a complete, dated snapshot of a record.
- Backup of last resort: A periodic population export stored securely offline is insurance against a vendor failure or a dispute.
Putting it in the contract
Certification establishes the capability; the contract establishes the terms. Before signing, confirm in writing the format of the export with a reference to the vendor's published documentation, the turnaround time for a population export, the fee if any, and the practice's right to run single-patient exports without a service request. Add language that these terms survive termination, since the moment the practice most needs the export is when it is leaving. The information blocking rules provide a backstop against unreasonable fees and delays, but a clear contract clause is faster than a complaint.
Common questions
Is the EHI export the same as the patient summary I can download from the portal?
No. The portal summary is typically a standardized clinical document covering a defined set of data classes. The EHI export covers all electronic health information in the designated record set, which is much broader and includes billing records and unstructured content.
Can the vendor charge for an EHI export?
Certification requires the capability, and the information blocking rules limit fees that are unreasonable or that interfere with access. Single-patient exports are expected to be part of normal operation. Population exports may carry a documented, reasonable fee, which should be stated in the contract.
What format will the export be in?
The developer chooses, but the format must be computable and publicly documented. Common approaches include FHIR resource bundles, CSV files with a data dictionary, or a mix of structured data and document files. Review the documentation before selecting a vendor.
Does the export include scanned documents and images?
It should include electronic health information the system manages, which generally includes scanned documents in the record. Whether large imaging files stored in a separate system are included depends on where they live. Check the vendor's documentation and ask directly.