Skip to main content
CORE DEVELOPER · FAQ These are the questions we actually get asked, grouped by where they come up. Answers link out to the page that carries the full detail where there is one. If your question isn’t here, email support@elationhealth.com.
01 — PRICING AND CONTRACTS

​
What it costs and what’s in the package

It depends on who is building.If your practice or a consultant you hire is building a custom integration that your practice owns, you need Core Developer on your subscription before production credentials are issued. That covers REST API 2.0 read and write access, Webhooks, and the Hosted Database.If you are adopting an integration a vendor already built, you do not need Core Developer. That vendor’s partner agreement with Elation governs access, and their credentials cannot be reused for a custom build of your own. Before you scope anything, check whether Elation already integrates with the partner you have in mind. See Submitting an integration request.Not sure which side of the line you are on? See Pricing and add-ons to understand which path fits your situation.
No. Core Developer is an all-in add-on. The fee applies to every provider with an active EHR seat. Staff accounts are exempt.The reason is structural: clinical data from every provider in the practice flows into the Hosted Database and is reachable through the API. There is no way to carve one provider’s data out, so there is no partial seat count to bill. See how provider seats are counted.
Yes. Elation does not distinguish between part-time and full-time providers for Core Developer. Any provider account with an active EHR subscription counts as a seat.
No. Core Developer is sold as one package, with no API-only or Hosted-Database-only SKU.
No. Elation Analyst (Beta) is included in Core Developer at no additional charge, and there is nothing separate to buy. It runs inside your Hosted Database rather than as its own product.It is still in Beta, though, so it is not switched on for every account yet. Confirm with Support that it is enabled for your practice before you plan reporting around it.How you get it depends on your access model. On an Elation-managed Reader Account it arrives pre-installed, and you should not run the installation script. On a Direct Share into your own Snowflake account, you install it yourself and point it at your own warehouse, which also means the compute it uses is billed to you rather than to Elation. See who pays for Snowflake compute.See Elation Analyst for what it can and cannot answer.
No. There are no per-call, per-record, or egress charges, and no overage invoices. Provider count is what drives your cost. Full detail on Pricing and add-ons.A few capabilities sit outside the base subscription and may carry their own cost, including the Document Signing API, the Care Gaps API, and additional daily Hosted Database refreshes. Those are requested through Support, and they are priced up front rather than metered.
02 — ACCESS AND CREDENTIALS

​
Getting keys and keeping them working

In the sandbox, practice admins create their own credentials from Settings > API Access. No ticket needed.In production, self-service credential management is available on request. Contact Support to have it enabled for your practice. Until then, Elation issues production credentials for you, over a secure channel.See Self-Service API Credential Management for the walkthrough, and Get started for what has to be true before any production credential is issued.
Yes. Issue or request the replacement first, deploy it, confirm it is working, and only then revoke the old one. Both sets stay valid during the overlap, so there is no forced cutover window.Do not revoke first. Anything still using a revoked credential stops authenticating immediately.
No. The client secret is displayed once, at creation, and cannot be retrieved afterward. Elation cannot look it up either.Create a new credential, update your integration, then revoke the one you lost. This is also why we suggest issuing a separate credential per integration or per internal service: losing or rotating one does not disturb the rest.
No. The API type is chosen when the credential is created and cannot be changed afterward, so a credential is either an Elation APIv2 credential or a FHIR R4 credential. Create one of each if you need both.This is the most common cause of FHIR authentication failures. A REST 2.0 client ID and secret will not mint a token on the FHIR token endpoint, and the error you get back describes a policy or scope problem rather than pointing at the credential type. If FHIR auth is failing and the same credentials work fine against REST, the credential type is the first thing to check.See Service Base URLs for the FHIR endpoints and Getting started with the FHIR API for registration.
The token endpoint no longer supports the Resource Owner Password Credentials flow. Stop sending the username and password, and set grant_type to client_credentials. Your client ID and secret do not change.See Get Token.
Usually not. When a third party needs to reach your data on your behalf, that runs through Elation’s partner track rather than through your own Core Developer subscription, and it is authorized by your practice in writing rather than by adding an add-on to your contract.Reach out to Support with the vendor’s name and what they need to read or write. If Elation already has an integration with them, you may not need to build anything.
03 — SANDBOX

​
Building before you buy

No. The sandbox is free, and it does not require a Core Developer subscription or a particular EHR tier. It is open to current Elation customers and to organizations looking to partner with Elation.What it does require is an executed API License and Usage Agreement. See Get started for the full sequence, including how to request a sandbox.
No. Your sandbox arrives as a blank replica of the EHR with only the account used to provision it. You create your own users, patient charts, appointments, and practice settings, which means your test data matches the shapes your integration actually cares about.Add more providers under Settings > Manage Accounts, the same way you would in a live practice. See Managing user accounts.Use synthetic data only. Sandbox practices are PHI-free by design.
No. Sandbox and production are permanently separate, and nothing moves between them in either direction. Practice configuration, users, and test charts do not transfer, and production credentials are newly generated rather than promoted.Plan your go-live as a fresh configuration of the production practice, not a promotion of the sandbox.
A concrete list of what you exercised: the endpoints you called, the test scenarios you ran end to end, and how your integration behaves when a call does not succeed. Cover at least 401, 429, and 5xx handling, because those are the failures that show up in production rather than in a happy-path test.If you cannot produce that list, the build is not ready for real patient data. See Get started.
04 — APIS AND WEBHOOKS

​
Building against REST 2.0, FHIR, and events

The API License and Usage Agreement limits usage to fewer than 3 API calls per second and fewer than 150,000 calls per 24 hours. Elation reserves the right to adjust those limits. The API returns 429 when you exceed them. See errors.Two things that help in practice. Reuse an access token until it expires instead of requesting a fresh one per call, since the token endpoint is limited separately from the resource endpoints. And do not rely on a Retry-After header being present on every 429. Use your own exponential backoff with jitter.
No. Rate limiting is a technical protection for platform stability, not a billing mechanism. Exceeding the limit returns a 429 and never generates an invoice. Build in retry with exponential backoff and jitter — see errors.
No. The FHIR R4 API supports read and search only. That is deliberate, not a configuration gap: it exists to meet the ONC Certified § 170.315(g)(10) Standardized API criterion, and no scope change, application setting, or enablement request will turn on writes.Anything that creates or updates data in Elation goes through REST API 2.0. Most integrations use REST 2.0 for everything and reach for FHIR only when the use case requires FHIR-standard interoperability, such as SMART on FHIR or USCDI exchange.
Because cursor-based pagination is now the default. Cursor responses return next, previous, and results, and they omit count.If you need the total, add an offset parameter to the request, for example &offset=0. That switches the response to offset-based pagination, which includes count alongside limit and offset. Either way, a single page returns at most 100 results.Cursor pagination is the more performant and more reliable of the two, so prefer it and track completion from next being null rather than from a total. See Pagination.
Yes, within limits. Retries run hourly for up to 24 hours from the original event. Only a 5xx response or no response at all triggers a retry. A 4xx is treated as final and is never retried, so returning 400 to an event you cannot parse discards it.If retries are exhausted without a 200, the event stops and you are not notified. That is what the Published Events API is for: it returns the delivery record, including the HTTP status Elation received, for every event sent to your application over the last 90 days. Reconcile against it rather than assuming delivery.If you find a gap older than the retry window, contact Support.
24 hours is the current retry window. Older copies of Elation’s API documentation stated 72 hours. If you are working from a bookmark or a saved PDF, check it against Webhooks.
Delivery is at-least-once, so a delivery that succeeds on our side but whose response we never receive gets sent again. Separately, one logical change can emit more than one event for the same resource, and some background processing fires an event when nothing visible on the resource changed.Two consequences for your handler. Dedupe on event_id rather than event_uuid, since event_uuid is newer and can be absent. And make handlers idempotent per resource, not only per event: processing the same resource twice should reach the same end state rather than creating a second record.See Acknowledging events.
Partly, and not reliably for everything. Only two list endpoints expose a last-modified filter: patients and visit_notes. A polling loop can miss in-place edits to resources that do not expose one. That failure is silent, so you will not see an error when it happens.The recommended pattern is Webhooks for change detection, with the Published Events API as your reconciliation backstop. Reserve polling for patients and visit_notes.
Because API document signing is off by default. Until it is enabled for your practice, sending signed_by or signed_date returns a 400 with "Practice does not have API signing enabled". Requests that omit both fields are unaffected.Turning it on is a paid add-on. It requires an executed BAA, and an Admin User at your practice must review and accept the API document signing agreement, which covers clinical oversight and regulatory responsibility for documents signed this way. See Pricing and add-ons and errors.
Lab orders cannot be signed through the API. The signing fields are ignored on lab orders rather than rejected, so the order lands as an unsigned draft and no error tells you why. Sort your signing workflow out before you build around it.
Yes, with user impersonation. By default everything your integration creates is attributed to the API service account rather than a real provider, which is rarely what you want in a chart.Send the X-On-Behalf-Of header with the numeric id of the user you want to act as, and the request is processed as if that user made it. Attribution then lands on that provider in the chart, the action log, and the Hosted Database.Your token needs the act_as_user scope alongside at least one resource scope, and the user has to be active and in a practice your token covers. See User Impersonation. This is currently in closed beta and available to select customers only, so confirm with Support that it is on for your account before you design around it.
05 — HOSTED DATABASE

​
Querying your data in Snowflake

It depends on how you access the Hosted Database.On an Elation-managed Reader Account, Elation covers the Snowflake compute. Query as much as you need — there is no metering and nothing charged back to you.On a Direct Share into your own Snowflake account, you pay the compute your queries consume, because they run on your warehouse under your Snowflake contract. Elation still pays for the compute on our side that prepares and refreshes the shared data.Neither option changes what you pay Elation. The Reader Account keeps compute off your books. A Direct Share gives you control of the environment — roles, network policies, downstream pipelines — in exchange for owning its cost.If you are on a custom enterprise agreement rather than the standard subscription, check your order form.
It refreshes once a day, either at 1am PT or 5am PT, so a given day reflects the prior day’s activity in the EHR. There is no on-demand or self-service refresh, and you cannot trigger one. See How often does my data refresh.Additional daily refreshes are available as a paid add-on, priced per practice. Contact Support for a quote.If your workflow needs data closer to real time, it belongs on Webhooks or the REST API. The Hosted Database is built for analytics, not for driving live workflows.
Hover the clock icon on any table in the Snowflake UI, or run the documented query. Both are covered in View when your data was last refreshed.One trap is worth knowing. hdb_last_sync is a per-row column that records when Elation’s internal store last refreshed that row from the source application. It does not tell you when your Hosted Database finished its most recent build, and it does not confirm that an individual record has landed. If you are filtering to find recent activity, filter on a business timestamp such as creation_time instead.A query that runs during the rebuild window can also see a partially built table. If the data still looks wrong after you have checked the last refresh time, contact Support with the table and what you expected.
No to all three. Your Elation Snowflake account is a reader account. You can query the data we share, but you cannot insert, update, or delete it, load outside data into it, or create tasks, streams, procedures, or warehouses. That last restriction is what rules out scheduling a query inside the Hosted Database and emailing the results.See what kind of access you get and Can you grant me write permissions. Broad administrative roles are not granted; your role covers user and role management within your own account.If you need write access, scheduling, or your own pipelines, set up a Direct Share into a Snowflake account your organization owns. See How to set up Direct Share.
A Reader Account is a Snowflake account Elation owns and manages for you. You log in and query. It is the faster path and needs nothing from you beyond a login.A Direct Share puts the same data into a Snowflake account your organization owns, which means you control the warehouses, roles, network policies, and anything you build downstream. It is the right choice if you want to join Elation data against other sources or write transformed tables.You do not run both indefinitely. When you move to a Direct Share, your Reader Account stays live for 30 days and then you lose access to it, so finish your cutover inside that window. See How to set up Direct Share for the account details Elation needs from you.
Only if your practice is on Elation Billing. If you are not, those tables are not created at all — they are absent from your share rather than present and empty.If you are on Elation Billing, clinical, operational, and billing data all sit in the same Hosted Database, which is what makes joins across the chart and the revenue cycle possible. Claims, charges, payments, ERA adjustments, and claim queues are all queryable. Browse the current tables in the Hosted Database schema.
Start with the schema browser and confirm the exact name, since it is the current source of truth for every table and column.If it is documented but missing from your share, the usual cause is that the underlying feature is not provisioned for your practice rather than a pipeline fault. A few fields visible in the EHR are also not carried into the Hosted Database at all. Contact Support naming the table and column and we will tell you which it is.
It depends on the class of change. Breaking changes get 30 calendar days. Behavior changes, where the schema holds but the volume of data behind it shifts, get 7 days. Purely additive changes are announced when they ship.Notices go to the Hosted Database Release Notes, which publishes RSS. Wire it into Slack or a feed reader so deprecations reach you instead of waiting to be found. See Change management and schema versioning for the full policy, and Early Release if you would rather test a change against your own pipelines before its GA date.
They are in different timezones. Data from the REST API should be assumed to be UTC. Data in the Hosted Database is Pacific Time, and it shifts with daylight saving.So an event late in the day looks like it happened on different calendar days depending on which surface you read it from, and a naive join or date filter across the two silently produces wrong counts. Normalize to one timezone before you compare. In Snowflake, convert_timezone does this per query, though the result does not persist.See Dates for the API side and What timezone is my data in for the Hosted Database side, including the one column that is documented as an exception.
Snowflake locks a user after repeated consecutive failed logins and then clears the lock automatically after about an hour. An account admin on your side can also clear it sooner.The usual cause is not a person mistyping a password. It is an automated job retrying with stale credentials, which burns through the attempt count in seconds. Fix the credential in the job before you unlock, or you will lock again immediately. If you cannot get back in, contact Support.
You do not need to read SQL to sanity-check an answer. Three habits do most of the work:
  1. Read the interpretation line. Analyst restates what it thought you asked, including the date range it chose. That is where a wrong answer usually reveals itself, and it’s written in plain English.
  2. Start with a question you already know the answer to. Ask something you can verify against a report you already run. If it matches, you have calibrated it for the questions you can’t check.
  3. Download the CSV and spot-check a few rows. Pull two or three patients out of the result and open their charts. Faster than auditing a query, and it catches the errors that matter.
If a number is going somewhere consequential, like a payer submission or a board report, have someone technical read the generated SQL, or rebuild it as a saved query once and reuse it.
Two limits to plan around. Analyst reads the Hosted Database, so answers reflect yesterday’s data, not this morning’s. And it answers on demand only — you cannot schedule a question or have results emailed to you on a recurring basis. For numbers you want to watch over time, rebuild the generated SQL as a dashboard tile.
06 — SECURITY AND COMPLIANCE

​
PHI, agreements, and access control

Yes, for production. API access to real patient data requires an executed Business Associate Agreement, and the practice whose data you will reach must also provide written authorization and consent. No production credential is issued before both are on file, and data you retrieve has to be used and disclosed consistent with HIPAA permitted and required uses.The sandbox is a different matter. It is PHI-free by design, so it is gated on the API License and Usage Agreement rather than a BAA. See Get started.
No. Your Hosted Database is a private copy of your own practice data. No other customer has access to it. Elation handles maintenance, backups, encryption, and auditing.
Elation does not require IP or domain allowlisting for API access. Authentication uses standard OAuth2 bearer tokens with an expiration, so calls from your infrastructure need no network-level registration with us.Outbound webhook traffic is the other direction, and it does originate from published, environment-specific IP ranges you may need to allow through your own firewall. Those ranges and the notice period before they change are on Webhooks.
Yes, two ways, and they stack.Network policies let you allow or block specific IP ranges. There is no UI for this on a reader account, so you create and manage them from a worksheet. See Managing network policies.Multi-factor authentication can be turned on per user from Snowflake’s own settings. See Setting up multi-factor authentication.
Practice admins. Credential management lives in Settings > API Access, and it is available to admin users only, so a provider or staff account without administrative privileges will not see it.Treat credentials like a shared password for your practice’s data. Store them in a secrets manager, never in email or chat, and revoke immediately if one may have been exposed. See Self-Service API Credential Management.
With scopes, in the form system/<resource>.<read|write>. Assign them when you create a credential, or edit them afterward, and changes take effect immediately. A credential with no scopes assigned falls back to a global scope carrying full practice read and write, which is rarely what you want for a single-purpose integration.Granular scopes are currently in closed beta and available to select customers only, so confirm with Support what is enabled for your account. See Token Scopes for the format, the full resource list, and the rule that specific scopes cannot be combined with the global scope in one token request.
07 — STAYING CURRENT Elation publishes RSS for both the API 2.0 Changelog and the Hosted Database Release Notes. Subscribing is how you hear about new endpoints, field changes, and deprecations before they reach your integration. See Subscribe to Elation Release Feeds. For pricing, access, contract questions, or anything above, raise a request at app.elationemr.com/support or contact your Customer Success Manager.