LifeLines
Book a demo

Product

Care for patients

EHRRemote MonitoringCommunicationsSchedulingSoonPrescriptionsSoonPatient TerminalSoon

Ship and bill

Orders & ShipmentsInventoryBillingClearinghouseSoon

Keep track

CRMQueuesAnalyticsTasksSoon

Automate and connect

AutomationsDeveloperMobile AppSoon
See every moduleBuild a combination

Features

PulsePage helpKnowledge BaseRelease LogTeam ManagementSchedule and AwayRole SettingsPlatform SettingsPractice scopeHome PageGlobal searchLayoutsApps dockNotificationsAppearanceAccount securityFilesTickets

Solutions

For RPMFor ClinicsFor Call centersFor Billing companiesFor Device suppliers

Services

Setup and onboardingPhone numbers and textingBranded callingWebsite and domainWork email accountsSupportCustom work
Every featureEvery solutionConnectionsEvery serviceBlogLog in

LifeLines/Blog/Software

Healthcare API Integration: What a Practice Should Ask For

Healthcare API integration explained for practice managers: what to connect, which standard to ask about, and the key, webhook and log controls to require.

Guide·6 min read·

Laptop showing code

The short answer

  1. 01An API integration moves data between systems with no retyping or file uploads
  2. 02Decide what should move between which systems before you talk about technology
  3. 03Insist on scoped keys, logging and a signed BAA before any key is handed over

A healthcare API integration lets two systems exchange patient and practice data directly, without someone retyping it or uploading a file. You do not need to write the code to make good decisions about one. What a practice needs is a clear idea of what should move between which systems, and a short list of controls to insist on before any key is handed over. This guide gives you both.

What a healthcare API integration actually is

An API (application programming interface) is a door one system opens so another system can ask it for data or ask it to do something: look up a case, create a patient, log a call. The system knocking on the door identifies itself with a credential, usually an API key, and every request is checked against what that key is allowed to do.

A webhook works the other way round. Instead of your other system asking every few minutes whether anything changed, the platform sends a message to an address you give it the moment something happens: a case was created, a status changed, a call was logged.

An integration often uses both. The API is for reading and writing on demand, and webhooks are for hearing about changes as they happen. A file export (a spreadsheet emailed every night) is the older alternative. It still has its place, but it is slower, harder to control and easy to lose track of.

Start with the job, not the technology

Before any technical conversation, write down what the integration is for, in one sentence per flow. For each one, answer four questions.

  1. What moves? Referrals coming in, cases going out to a partner, device readings arriving, claim status coming back, call records going to a reporting tool.
  2. In which direction? Read only, write only, or both. Read-only access is far easier to keep safe.
  3. How fast? Does the other side need to know within seconds (a webhook), or is once a day enough (a scheduled request)?
  4. Which system is the source of truth? If a patient's address can be changed in both systems, decide which one wins. Two systems that both think they own a field will overwrite each other.

This list becomes the brief for whoever builds the integration, and the test of whether it is finished. If you are still choosing the system itself, add these flows to your EHR evaluation questions.

Ask which standard the API uses

APIs come in different shapes, and the shape decides who can build against it and how much work that takes. Ask the vendor plainly what theirs is.

  • General web APIs, often called REST or GraphQL, are the common choice in modern software. Any developer can work with them, but each vendor's data model is its own, so every integration is built for that vendor.
  • Healthcare standards such as FHIR and the older HL7 version 2 messages define common shapes for clinical data, so two systems that both speak the same standard need less custom work. Federal interoperability rules refer to FHIR for certain kinds of data sharing.

Neither is automatically better. What matters is whether the API covers the data your flows need and whether your partner can work with it. Ask too whether the documentation is public, whether there is a place to try requests safely before going live, and which operations exist for the records you care about.

The access controls to insist on

An API key is a password for software. Treat it with at least the same care, and ask for these controls.

Keys that can be replaced and stopped

  • The full key is shown once, when it is created, so it cannot be read later from the vendor's screen.
  • A key can be rolled to a new one with a short overlap, so the old key keeps working while your other system switches over.
  • A key can be revoked at once if it leaks or a partner relationship ends.
  • Keys can be set to expire.

Least privilege by default

  • A new key starts with no access. Someone with the right permission grants each operation it needs, and nothing else.
  • The key is limited to the records it needs: one practice, not every practice you work with.
  • You can choose whether a key acts on behalf of the organization as a whole or as a named person. A key acting as a person should never be able to do more than that person can.
  • There is a ceiling above every key (allowed operations, request rate, number of keys, key lifetime) that a separate permission controls.
  • There is one switch to stop all API access at once if something goes wrong.

What to ask about webhooks

Webhooks carry data out of the platform to an address on the internet, so they deserve their own questions.

  • Are deliveries signed? A signature lets the receiving system confirm the message really came from the platform and was not forged.
  • Are failed deliveries retried, and can they be replayed? Your receiving system will be down at some point. Messages should not be lost when it is.
  • Can you send a test event? You should be able to check an endpoint works before real data flows.
  • What is in each message? The safest default is identifiers and status only, with patient information included only when an endpoint is deliberately set to receive it. That fits the HIPAA minimum necessary standard.

Logging and troubleshooting

When an integration misbehaves, the first question is always "what did it actually send?" Ask whether every request is logged with the key that made it, the operation, the person it acted as and the result. Each request should carry an ID that both sides can quote, and you should be able to filter the log and export it. Without this, a support conversation turns into guesswork.

Contracts and HIPAA

The vendor whose platform holds your patients' data is already your business associate and should have signed a BAA. If a third party builds or runs the integration for you and handles PHI along the way, it may need its own BAA too. Ask your compliance adviser, and see our HIPAA compliant software checklist for what the agreement should cover. Include each integration in your risk analysis, and review who holds keys at least as often as you review staff access.

Frequently asked questions

What is the difference between an API and an integration?

The API is the door a system opens. The integration is the work that uses it: the code or tool that moves a specific piece of data between two specific systems, on a schedule or in response to an event.

Do we need FHIR to integrate with other healthcare systems?

Not always. FHIR helps when both sides support it and the data you need fits it. A general web API works just as well when one side builds against the other's documentation. Ask what each system offers before choosing.

Who at the practice should own the API keys?

One named person, usually an administrator, should own the list of keys: what each is for, who holds it and when it was last reviewed. Partners hold keys; they should not create their own.

What should we do if an API key leaks?

Revoke it, or stop all API access if you are not sure which key leaked. Check the request log for what it was used for, issue a new key, and talk to your compliance adviser about whether the incident needs reporting.

Sources

Read next

Every article