Getting data out of eClinicalWorks is not one task. It is a choice among seven routes, and each returns a different dataset in a different format on a different clock.
Some routes are self-service. Some begin with a support case. One needs a licence. And two of them work a little differently from how you would expect: the billing data and the clinical data can arrive by different routes, and the population export comes as a wider database backup rather than the tidy dataset the format documentation describes.
If you want an ongoing integration you want the API route, and if you want reports you want the reporting module.
What eClinicalWorks data migration means
Migration runs in three directions, and they are not the same project.
Into eClinicalWorks. A practice leaves a legacy system and moves onto the platform.
Out of eClinicalWorks. A practice leaves the platform and moves somewhere else.
Archive and switch off. The practice stops using the system but keeps a regulated copy of the record.
This page covers the second one. An eClinicalWorks export data request is also the direction where the mechanics are least documented and the cost is least understood.
The reader this is written for is the practice owner, the practice manager or the biller who has been told to get the data out, and who needs to know which door to knock on.
The seven routes out
eClinicalWorks data extraction is the term most people search for, and it covers all seven of these routes. That is exactly why it helps to plan them separately, because the routes serve different datasets and a full move usually needs more than one. A clinical export data request and a billing export request are separate asks on separate clocks.
The table below is the decision. Everything after it is the detail.
| # | Route | Comes back as | Who runs it | How it is charged |
| 1 | Single-patient EHI Export | CSV, delivered as a ZIP to a local computer | You, using the EHI Export Utility on a machine connected to the EHR | Stated at no cost |
| 2 | Patient-population EHI Export | A ZIP that is part of a database backup, carrying more than the documented export format | eClinicalWorks, after you open a support case | Not published; ask for the quote |
| 3 | C-CDA export | C-CDA clinical summary documents, one patient or many | You, self-service | Stated at no cost |
| 4 | Billing and RCM data | A separate ZIP, downloaded separately from the clinical export | eClinicalWorks | Not published; ask for the quote |
| 5 | Focused data extraction | Human-readable extracted files | eClinicalWorks, after you open a support case | Stated as fees apply |
| 6 | FHIR R4 APIs | Live structured data: Patients, Encounters, Observations | Your developer, after activation | No charge for the interface |
| 7 | Business Optimization (eBO) | Scheduled extracts and custom report output from a separate analytics warehouse | You, once the module is licensed | Requires separate licensing |
Route 1 — one patient at a time, and you can do it yourself
The EHI Export Utility comes from the Microsoft app store, and it has one precondition worth knowing in advance. It must be installed on a computer connected to the EHR, so it will not run from a laptop at home. Output is CSV, delivered as a ZIP.
Two details from the vendor’s schema page make the single-patient export straightforward to handle well. Scanned documents arrive in a separate folder alongside the database tables, which is useful to know when you tally the export, and blank date fields come out reading 1900-01-01 or 0000-00-00. The vendor is explicit that these are database defaults for empty fields and carry no clinical meaning, so knowing the pattern lets you filter them cleanly on import rather than carrying a placeholder date forward into the new chart.
Access to the utility is set at user level, and that is worth arranging before you need it. Reaching the export and administrative tools requires the right security settings on your user profile, and a quick check with whoever administers your account will normally have them in place in minutes.
Route 2 — the whole population is a support case, not a button
A patient population export cannot be started from inside the application. It must be initiated by opening a support case, and the case is filed on the customer portal.
That is not a vendor quirk; it is how the route is defined. The certification rule is specific: the single-patient export must be user-executed at any time the user chooses and without subsequent developer assistance, while the full-population export may require support from the developer. The two routes are different by design, which is why one is a download and the other is a ticket.
How to open the case so it does not stall. Ask for four things in the first message rather than one at a time:
The full population export, stated as such
The datasets you need, named, rather than “all our data”
The format you will receive, and whether it is the documented export format or the wider database backup
an itemised quote, before the work starts
Name the destination system as well, because the receiving platform’s import specification determines what you need. A case that opens with “we are leaving, please send our data” gets a generic answer; a case that opens with a dataset list and a format requirement gets a queued job.
Then diarise a follow-up. The reported lead time on this route is measured in weeks, and a case that goes quiet is the most common way a cutover date slips.
This route also arrives as part of a database backup, which means it contains more than the documented export format describes. That is useful and awkward at once. You receive more than the specification promises, and you cannot rely on the specification to predict what lands.
This is the route with the lead time. Open it first.
Route 3 — clinical summaries, and the one that costs nothing
C-CDA export is self-service, works for a single patient or a batch, and is stated at no cost.
C-CDA is document-oriented. It is the right shape for a clinical record moving between systems and a document format rather than a row-by-row one, so it works best for what it is good at rather than as the whole migration.
Route 4 — the route nobody budgets for
If the practice bills through eClinicalWorks, the billing data does not necessarily arrive with the clinical export. The vendor’s own disclosure states that RCM customers perform a separate export for RCM data, downloaded as a separate ZIP.
That sentence decides cutover dates. A project can move every chart perfectly and still have nothing to bill from.
And the picture is more complicated than a clean split, because the export schema documents a substantial body of billing and administrative data inside the export itself. Claims, payments, adjustments, refunds, statements, payer data and fee schedules all appear there. So the honest position is not that billing data is excluded; it is that the two documents do not say the same thing, and no public source reconciles them.
The practical answer is to ask, in writing, before committing to a date:
Of the billing, claims, EDI, payment, adjustment, refund and account balance tables in the export schema, which will be delivered in the population export, and in which file?
It is worth confirming in writing rather than assuming either way, and getting the answer before the freeze window, because this is the route that sets the timeline for any practice moving to a platform with its own practice management.
While that question is open, the claims, denials and balances already sitting in the system still have to be worked. Practices that want that handled by a team already working inside the platform use eclinicalWorks medical billing services so the revenue side keeps running while the rest is decided.
Route 5 — human-readable extraction
Focused data extraction returns files in a human-readable format, which makes it useful for a specific dataset, a reporting need or a targeted move rather than a full history. It runs through a support case, and the vendor states that fees apply.
Route 6 — the API route, and its precondition
FHIR R4 APIs support SMART on FHIR and OAuth 2.0, and give structured access to resources including Patients, Encounters and Observations.
The barrier is rarely technical. It is a configuration step that is often simply not yet enabled; the practice needs the Patient Portal and Interoperability Hub FHIR-enabled from Product Activation. If that activation does not exist on the account, the API conversation begins with an administrative task rather than a development one.
Route 7 — the licensed reporting route
Business Optimization (eBO) is the reporting and analytics module, covering dashboards, benchmarking, and standard and custom reports.
It requires separate licensing and permissions. If the option does not appear under Reports, the module is not licensed on that account, and the answer usually comes from the account manager rather than the menu.
One timing detail is worth knowing before two reports disagree in a meeting. eBO draws from a separate analytics warehouse rather than the live database, so its figures can lag behind the numbers the practice sees during the day. Custom extracts can reach data available in the practice’s database, and reports can be scheduled and exported to a file.
For quality programmes, periodic extracts and reporting rather than a one-time move, this is the route built for the job.
Direct database access, and who can actually use it
Assistants and forum threads often present three routes as if all three were open to everyone: FHIR APIs, direct database queries, and administrative exports. In practice the middle one depends on your contract rather than your software, and a minute spent confirming it will save a longer conversation later.
Where the practice holds a licensed, self-hosted deployment, direct database queries and custom extracts are genuinely available. Where the vendor hosts the database, under the cloud subscription model, the database and host servers are not reachable natively, and custom reporting on those accounts runs through the reporting module instead.
The hosting model is therefore the first question rather than the last, because it decides which of the three options the practice actually has. Ask which deployment you have before pricing an extraction.
What actually comes out
The vendor publishes the schema of the Electronic Health Information export. It is public, needs no login, and was reviewed on 4 September 2026.
It documents every table in the export and every column within every table, in plain English. As of that review date, it lists 1,491 tables.
Around 180 of those tables cover the practice’s financial life: billing, claims, EDI transactions, payments, adjustments, refunds, remittance, account balances, collections, statements, payment plans, payer data and fee schedules. That number is a count of table names rather than a category the vendor publishes, and a narrower keyword set lands nearer 160, so treat it as an order of magnitude rather than a figure to quote back at anyone. Either way, roughly one table in eight is financial, which is good news if a billing migration is part of the plan, because that detail is documented in the same public schema as the clinical detail.
The clinical families sit alongside them: clinical records, notes and documents, patient and guarantor demographics, appointments and scheduling, and the specialty modules a practice may be running, from surgical centres, behavioural health and chronic care management through to dental, vision, inpatient and rehab, occupational medicine, kiosk and telehealth. Naming the modules your practice actually uses is what makes the plan complete, since each one arrives with its own set of tables.
And it is documented down to the individual column. The patient table defines its primary key, the system-generated account number, and the employer name, address, city, state, ZIP and telephone fields, one line each. A practice can read exactly what it will receive before it receives it, rather than discovering it during validation.
Two further details on that page are worth knowing before you run the export.
The extract contains Social Security Numbers, and the vendor’s own guidance is that it must be reviewed and excluded before it is shared with anyone outside the practice. Plan that handling before the file exists rather than after.
The extract also carries third-party licensed code sets, including CPT, together with the terms that come with them. They cover commercial reuse of the code dictionaries themselves, and they are simply part of the download. Worth a glance, so you know what applies if the extract is later reused for reporting or analytics.
What it costs
What is free, and what is charged
Start with the structure, because it is published and it is current.
Vendors of certified EHR software are required by rule to publish a description of the costs a user may be required to pay, and the rule is specific about what must be disclosed: fixed fees, recurring fees and transaction-based fees, including fees charged by third parties. That requirement is set out in the certification rules rather than being a matter of goodwill, and it is worth knowing the disclosure exists before you go looking for it.
eClinicalWorks publishes its version inside its certification disclosures, in a table, in a long regulatory document written to be compliant rather than to be read. Three lines in it answer most of the question:
- C-CDA export: stated at no cost.
- Focused data extraction: stated as fees apply.
- The reporting module: requires separate licensing.
Everything else on the list above is quoted on request.
So when a practice asks what it costs to get its data out, part of the answer is already published, and the rest of it is a number you have to ask for. Ask for it itemised against the routes, because a single figure tells a practice nothing about which route it is buying.
The figures that have circulated
Reporting from 2018, covering the options the vendor quoted to customers at that time, carries three figures:
a one-time database backup including scanned documents, around $500
continued read-only access, around $200 per month, per provider
full-service extraction, around $1,500 per provider, plus around $500 for the drive
The same reporting describes a timeline of four to five weeks.
These are eight years old. Pricing moves, and nobody should treat a 2018 figure as a current quote. They are here because they show the shape of the cost: the backup option is a few hundred, the extraction service is a few thousand, and the ongoing access option is a monthly per-provider line rather than a one-off. That is genuinely useful for budgeting a line, and it is not useful for anything else.
The number that matters is the one on your own quote.
What governs what you are charged
Two things: the contract in front of you, and what the vendor quotes you now.
Read the agreement’s data extraction, termination and data return clauses before the conversation about cost starts. Then ask for the itemised quote against the routes and compare it to the structure above. A quote that does not break down into export, delivery, access and service is not a quote anyone can check.
How long it takes
The reported window is four to five weeks from when the support case is raised, rather than from when the decision is made, and that figure carries the same 2018 caveat as the prices above: treat it as the shape of the wait rather than a schedule.
The two clocks are separate. Clinical export and billing export are separate requests with separate timelines, and raising them together is the difference between a clean cutover and a month of running two systems.
The cutover window is the one to plan around, and it is easier once you map it. Data does not stop being created on the day of the final export. Everything entered between the last full export and the moment the old system stops being the source of truth has to be carried across separately, in a final run that captures only what arrived in that gap.
Decide who owns that window and how short it can be. A short window with someone watching it is manageable; a long window nobody owns is how a practice ends up running two systems and trusting neither.
Four things to plan for
One patient and one population are different mechanisms. A single-patient export and a population export look like the same job at different scales, and testing one is a good way to learn what to expect from the other. They are different by design: one is self-service and immediate, the other is a support case and a database backup.
Billing data and clinical data can travel separately. The vendor documents a separate export for RCM data and also documents billing tables inside the export schema, so it is worth confirming which route carries which before you set a date.
The population export arrives as a database backup. It carries more than the documented format, which is why validating what arrived is worth the time rather than assuming its shape.
The analytics route is licensed, and direct database access depends on your deployment. The reporting module is not switched on by default, and hosted accounts are reached through the reporting tools rather than the database. Both are easy to confirm early, and knowing which applies keeps the quote accurate from the first request.
Does the export route survive regulatory change?
Worth knowing if you are planning far enough out that the rules might move.
The certification criterion that requires this export is in force and unchanged. A proposed federal rule would trim around half of the certification programme’s criteria, and it deliberately keeps the electronic health information export criterion in place.
The rule is proposed, not final, so it should be described that way. But the direction of travel is toward removing requirements rather than adding them, and this one is explicitly held. A practice can plan a migration without wondering whether the exit route will still exist when it needs it.
Does eClinicalWorks have an API?
Yes. FHIR APIs are documented on the vendor’s developer portal and support structured access to clinical resources.
The precondition is administrative: the practice must have the Patient Portal and Interoperability Hub FHIR-enabled from Product Activation.
It is worth separating two things that get conflated. An API is an integration route, not a migration. It keeps two systems talking; it does not carry a decade of history across, which is what the export routes are for.
How to validate what arrives
Validation is where a migration succeeds or quietly fails.
Count at three points. Source, export, target. Three numbers per dataset. A mismatch is investigated rather than accepted, and the counts are the evidence that something was actually moved.
But counts are the floor, not the test. Three matching numbers will not by themselves catch a diagnosis code that needs remapping, a truncated field, a document whose patient match needs checking, or a scanned folder left unopened. A practice can reconcile perfectly and still import a chart full of 1900-01-01 dates.
So build an exception list alongside the counts. Missing identifiers, unmatched documents, unmapped codes, duplicate patients, and every default value that arrived where a real date should be. A short list of named exceptions is more useful than a rounded completion figure, and it is the only version anyone can act on.
Weigh the exceptions properly. A single misfiled clinical document can matter more than a thousand clean demographic rows. Say that out loud before someone decides that 99.9% is good enough.
Clinical information is best moved as it stands. Where something in the record looks like a candidate for correction, moving it unchanged and raising it separately keeps the clinical meaning intact and gives the change a review and an audit trail of its own.
Run the test load before the real one, and validate it before you rely on it. The pattern that works is the same one above: plan what has to move, map it, name the risks in advance, involve the people who will actually use the data after go-live, and check the result against the source.
Migrate, or archive?
Not every historical record has to be rebuilt inside the new system.
Many practices move the active data — the patients being seen, the medications, the allergies, the open problems — and keep a compliant read-only archive for the rest. It is a legitimate strategy, and it is often the one that gets a practice live on time.
Weigh it honestly rather than treating it as a shortcut. An archive carries a real ongoing cost, and the read-only access option above is a monthly per-provider figure rather than a one-off. But forcing a decade of history into a new platform has its own cost, paid in mapping effort and in the quality of what arrives.
One caution that outlives the project: keep the archive readable for as long as the record retention rules require, which is usually longer than the migration feels. A practice that cancels access once the new system is running can find itself unable to produce records it is obliged to keep, and the saving is small against that exposure.
The question to ask is not “can we move everything” but “what does the new system need on day one to treat patients safely, and what can wait behind a read-only door”.
Conclusion
Seven routes, seven different answers, and the choice between them is made before the first file is requested.
Decide the destination’s import specification first, because it determines what format you need. Open the population support case early, because it carries the lead time. Request the billing and RCM export in the same breath, because it is separate and nobody remembers to ask. Validate with three counts per dataset and an exception list beside them, rather than a glance at a sample.
One part of a switch works a little differently from the rest. The outstanding claims, denials and aged balances in the old system keep running on their own timetable, on whichever platform the practice lands on. A medical billing company that already runs eClinicalWorks billing can look after the open claims and denials, which keeps the revenue side moving while the data is settled and keeps the cutover date comfortably on schedule.
