athenaOne Data View already lives in Snowflake, so you are not moving data into Snowflake so much as choosing where you work with it. With athenahealth's managed setup you query a read-only Snowflake account that athenahealth runs, then export what you need. With the Customer Managed setup, athenahealth copies your data into your own Snowflake account every day, where you can join it with other systems and model it directly. Either way, the data refreshes once a day and runs about one business day behind athenaOne.
What is Data View?
Data View is athenahealth's read-only, SQL-based analytics database, built on Snowflake and refreshed daily from your athenaOne account. Where athenaOne's reports let you change how a report looks, Data View gives you the rows underneath: clinical records, billing transactions, appointments and quality data.
The Data View datasheet describes "almost 400 tables" and three ways to use them: a browser-based SQL editor, a business intelligence (BI) tool, or a pipeline into an enterprise data warehouse through standard connectors such as Open Database Connectivity (ODBC), Java Database Connectivity (JDBC) and Python. athenahealth also ships QuickStart SQL templates that match common athenaOne reports.
Data View does not write anything back to athenaOne. For real-time reads or write-back, athenahealth points you to its application programming interfaces (APIs) instead, and many organizations use both.
Which setup do you need?
athenahealth offers two ways to host Data View and three service tiers on the managed side. The choice decides where your warehouse lives.
| athenaHealth Managed | Customer Managed | |
|---|---|---|
| Who runs Snowflake | athenahealth | You |
| Setup effort | Low: athenahealth gives you a Snowflake URL | Higher: your own Snowflake contract, Business-Critical Edition, US-hosted, HIPAA-enabled |
| Load your own tables | No, the account is read-only | Yes |
| Combine with other systems | Export first, then combine in your BI tool or warehouse | Directly in your account |
| User access, MFA, IP allow-listing | athenahealth | You |
| Snowflake platform support | athenahealth | You, under your Snowflake contract |
On the managed side, Essential, Plus and Advanced differ in data coverage and compute. Plus and Advanced add pre-built financial and operational datasets and Custom Views; Advanced adds the largest warehouse size and opt-in Multiple Daily Refreshes. athenahealth also offers a 40-hour Advisory Services enablement engagement, with Professional Services fees.
A plain rule of thumb from how we scope this work:
- Reporting only, one practice, a BI tool on top. Managed Plus is usually enough. Connect Power BI or Tableau straight to it (we compare the two in Power BI vs Tableau for a medical practice).
- You need athenaOne joined with payroll, a payer file or another EHR. Either export from the managed account into a warehouse you own, or move to Customer Managed so the join happens in one Snowflake account.
- You already run Snowflake. Customer Managed is the shortest path, provided your account meets athenahealth's edition and HIPAA requirements.
If your team is new to Snowflake terms: Snowflake's own Secure Data Sharing and reader accounts are general product features. athenahealth's documentation describes its delivery as a hosted read-only account or a copy into your account, so confirm the mechanics with your Customer Success Manager before you design around a share.
How fresh is the data?
Data View refreshes once a day. The cutoff is 11:59 p.m. Eastern, and athenahealth says Data View is always about one business day behind live athenaOne.
Timing differs by setup. In the managed account, tables load continuously from midnight with a target of 7:00 a.m. Eastern for the core ATHENAONE, FINANCIALS and SCHEDULING datasets. Customer Managed accounts receive tables at fixed checkpoints, for example 7:30 a.m., 3:30 p.m. and 11:30 p.m. Eastern, and a table that misses one checkpoint waits for the next. athenahealth says none of these times are guaranteed.
Two consequences for operations leaders. First, a "today" dashboard is really a "yesterday" dashboard, so build daily huddles around that. Second, if you run clinics in the West, athenahealth notes that data entered after 9:00 p.m. Pacific misses the cutoff until the next morning.
How should you model it in a warehouse?
Data View tables are close to athenaOne's own structure, which is right for completeness and wrong for a leadership dashboard. We build in three layers:
- Raw. Land Data View tables as they are, one schema per source, with the load time recorded. Keep the athenaOne identifiers.
- Cleaned. Standardize dates and time zones (Data View datetimes are Eastern, except the refresh log, which is UTC), resolve providers, departments and payers to one row each, and remove test or voided records by a written rule.
- Metrics. Build the measures people actually discuss, such as visits, charges, days in accounts receivable or care gaps, each defined once with its numerator, denominator and exclusions.
The tables most reporting starts from are the ones athenahealth itself uses in examples: appointments, claims and billing transactions. Its customer examples include a daily missing-charge query that joins the appointment and claim tables, and multi-site groups that consolidate days in accounts receivable and rejection rates across several tablespaces into one dashboard. Our practice KPI scorecard shows what to put on that layer.
For multi-site or MSO groups, carry the tablespace or context identifier on every row from the raw layer up. It is much harder to add later.
What are the common pitfalls?
Most problems we see come from treating a daily batch like a live system.
- Loading before the refresh finishes. Tables finish at different times. athenahealth recommends checking METADATA.TABLEUPDATES and only running your pipeline once the tables you need show today's date.
- Joining tables mid-refresh. athenahealth names a known case: during the refresh window, TRANSACTION rows can reference CLAIM IDs that have not loaded yet. Wait for both before joining.
- Trusting row timestamps for incremental loads. Every row has a LASTUPDATED column, but adding a new column does not give existing rows a new timestamp. Re-pull a table in full when its columns change.
- Mixing time zones. The refresh log is in UTC and everything else is Eastern. Convert once, in the cleaned layer.
- Waiting for an alert. Data View does not send proactive notices when a refresh is late. Build the check into your pipeline and alert your own team.
- Defining metrics in the BI tool. If each dashboard calculates its own version of a measure, two leaders will bring two numbers to the same meeting. Define it once in the warehouse.
How we approach this
Ben Miller built a first analytics data warehouse from athenahealth Data View, integrating 150+ healthcare metrics into one source of truth for operational, clinical and quality reporting. The lesson that carries over to every practice is the order of work: agree on the metric definitions, then build the layers, then build dashboards. Our analytics and BI architecture service follows that order, and the result sits in your own accounts.
Where to start
Ask your athenahealth Customer Success Manager which Data View package and account type you have today, and pull the last week of METADATA.TABLEUPDATES to see when your tables actually finish. With those two facts you can decide whether managed export or Customer Managed fits, and when your morning reports can safely run. If you want a second opinion on the design, book a free strategic assessment through our contact page.