Our approach
How healthcare integration works today, and how we do it differently.
A great healthcare product that can’t integrate is just a demo.
However good your app is, it needs patient data to be useful, and a place in the clinician’s workflow to be used. If your app can’t do that, it gets replaced by one that can: a competitor that integrates better, or the EHR itself, shipping the feature natively to everyone already inside its walls. For most apps, good integration isn’t a nice-to-have. It’s the whole game.
But healthcare is one of the hardest industries in the world to integrate with. The systems that hold the data were designed to keep you out. So sooner or later, everyone building here hits the same wall and asks the same question: “How do I integrate?”
The cost of buying access
There’s no shortage of vendors who will sell you “integration solutions” in healthcare. So why are we building another one? Because most of them aren’t selling you integration. They’re selling you access.
That access usually comes in one of two shapes: a narrow slice of the ecosystem with no path to the rest, or a bundle of the whole thing where you pay for all of it at once, whether you use it or not.
Reaching an EHR, a system of record, or a Health Information Exchange has traditionally meant bespoke, one-off connections, because every system speaks its own dialect: as the old line goes, if you’ve seen one HL7v2 implementation, you’ve seen exactly one. The companies holding the data are notorious for gatekeeping it, so each connection takes months to stand up, and most of your bill goes to the negotiation, the red tape, and the proprietary glue holding brittle connections together.
And you’re renting a broker, not building on a technology vendor you control. The access sits on their side, not yours, so you’re never really free to leave.
We break down the main ones in our comparisons.
Tired of renting access?
Tell us what you're building and we'll show you what you can reach directly.
Why direct integration is finally possible
That is finally changing, and regulation is the reason. ONC’s information blocking rules and certification program, alongside CMS initiatives like CMS-9115, CMS-0057-F, and “Kill the Clipboard”, have steadily forced the systems open. The result is a set of standardized, regulated APIs you can connect to directly, with no broker in the middle.
The clearest way to see it is by surface. A single healthcare system now exposes several standardized API surfaces, and a different set of rules is now forcing each one open.
Patient access
The patient’s own right to their data is the most powerful key you have, because it opens far more than their EHR. With a single authorization, the same patient can unlock the data every system holds about them.
It starts with the EHR. ONC g(10) requires certified EHRs to let a patient pull their own records in minutes, from a single link. The patient signs in to their portal, like Epic MyChart, and authorizes your app directly.
But the EHR is only the first source. CMS-9115 mandates payers to expose patient data through the same kind of standardized APIs, so you reach the claims and coverage history no single EHR has.
TEFCA IAS goes further still: a patient can request everything a network knows about them after identity verification alone, with no treatment relationship required. The same is likely to extend to the CMS-aligned networks, opening up data that simply wasn’t reachable before.
The same consent reaches beyond the chart: patients can connect wearables and glucose monitors just as easily, contributing data no system of record has.
Clinician workflow integration
This is the surface most don’t even know opened up. CDS Hooks and SMART App Launch are enforced by CMS-0057-F for prior authorization and ONC’s EHR certification regulation. Together they let your app meet the practitioner inside the chart, at the right time.
CDS Hooks fire at the right moment in the clinician’s workflow, like opening a patient or placing an order, and surface your app’s guidance as a native card, right in the EHR.
From that card, SMART App Launch opens your full app embedded inside the EHR, already authorized and scoped to the patient in front of them.
You’re not just pulling data, you’re in the workflow where care actually happens. Almost no other integration platform offers this surface at all. That is what gets your app used: it appears at the right moment in the clinician’s existing workflow, instead of sitting in a separate tab they have to remember to open.
Backend integration
FHIR is now the common API for clinical data, and ONC certification requires every certified EHR to expose it server-to-server. The same standard works across systems, so you build against one API instead of a bespoke connector per vendor.
This surface runs without a user present. SMART Backend Services lets your server authenticate with its own credentials and system-level scopes, so integrations run unattended on a schedule instead of waiting for a patient or clinician to log in.
The FHIR Bulk Data APIs, now mandated by regulation as well, export all the data for a group of patients in a single job, so you can keep an entire cohort in sync continuously.
Together these cover most of what the legacy paths used to, replacing point-to-point HL7v2 feeds and proprietary SOAP APIs. EHRs are taking it further: Epic now routes HL7v2 interfaces over HTTP authenticated with SMART Backend Services, opening up a whole layer of integrations that used to need a dedicated interface engine.
Network integration
The big exchange networks like CommonWell and Carequality are going FHIR-first through TEFCA and the CMS-aligned networks initiative, so you can reach a patient’s data across organizations.
Under TEFCA, networks connect through QHINs, and a single QHIN reaches far beyond its own members. Epic Nexus, for example, links not only Epic-using organizations but every other QHIN and the non-Epic orgs beneath them.
Put together, the brokered route is no longer the only way in, and increasingly not the cheapest or fastest one either. Because these standardized APIs replace the bespoke connections, negotiation, and proprietary glue that the brokered route bills you for, connecting to them directly typically costs 10-20x less than a traditional bundled integration.
Wondering what you can reach?
Tell us your use case and we'll map the data and workflows open to you.
Pick the integrations that fit you
Ideally, every app wants every integration surface. More patient data and a place in more clinician workflows only make your product stronger. What’s practically viable comes down to the relationships you have, to the patient and to the organization, and each one unlocks a different level of access. Knowing which you have lets you plan your product around them.
A patient relationship is the easiest to start with. If your app reaches the patient directly, their consent alone unlocks patient access, with no contract with the health system required. The same consent reaches their EHR, payer, and wearables at once, which makes it the fastest way to launch.
An organizational relationship with a provider unlocks the system of record itself: clinician workflow integration and backend access. This takes more to set up, since the organization has to register and configure your app, but it puts you inside their EHR and lets you sync data server-to-server.
A treatment relationship unlocks network integration. The networks only open up if you actually provide or coordinate the patient’s care, which means having a licensed clinician with an NPI on your payroll treating them. With it, you reach a patient’s data across every organization on the network, not just the ones you connect to directly.
Bundled integration solutions break this. They assume you already hold both a treatment and an organizational relationship, because their contracts are structured to require them. The moment that isn’t true for you, you don’t get a smaller integration, you get none at all, because every point of integration is gated behind relationships you may not have.
We unbundle each integration from the rest: your app connects directly to each surface the moment your relationship permits it, and takes only what fits. You can start with whatever you have today and grow from there. A patient-facing app might launch on patient access alone, then contract its first clinic for organizational access, then hire clinicians and reach the network through a treatment relationship. All of it stays on one platform, and we are there to support you at each step as you grow.
The integration landscape
The same regulated APIs that let you connect directly have opened the door for a wave of specialist tools. Each is genuinely good at one piece: patient access, network exchange, or EHR integration.
You could assemble several of them and cover real ground, and for many teams a point solution per source is a reasonable place to start. We break down where each one fits in our comparisons.
But connecting is the easy part. The moment data starts arriving from more than one place, two problems show up:
One patient, many sources
When you pull a patient from an EHR backend and the same patient through a patient-mediated connection, nothing guarantees they line up. Names, birth dates, and identifiers sometimes match exactly across systems, sometimes they don’t. So one person often arrives as two records that look like two people.
One concept, many representations
Even once the records are linked, the same clinical fact is rarely written the same way twice. A single HbA1c result can arrive under different LOINC codes and inside different FHIR resources, and the problem compounds across coding systems like SNOMED CT, RxNorm, ICD-10, and CPT, and document formats like HL7 C-CDA. Something as specialized as tumor size can take many forms for the same concept.
Reconciling is now your problem
Many point solutions deduplicate and normalize the data they return, but only within their own source. None of them sees the others, so the moment you combine their outputs the duplicate patients and mismatched codes reappear, and reconciling the same patient and the same clinical fact across all of them becomes your problem.
And this is not trivial work. Every new source you connect adds more identifiers to line up, more code systems to map, and more conflicting values to choose between. The reconciliation logic becomes yours to build, test, and maintain, on top of the integrations you were trying to outsource in the first place.
This is the hardest part of working with healthcare data, and it rarely shows up until something goes wrong in production. When it does, the failure can be fatal. A penicillin allergy documented in one integration source might never be reconciled with a duplicate patient record your app is reading. A clinician then orders an antibiotic containing penicillin, and the patient goes into anaphylaxis.
Reconciliation as clinical safety
Whether it is a duplicate patient or a miscoded value, the result is the same: both leave your app reading data that looks correct but isn’t. A duplicate patient record can hide a comorbidity, and a warfarin medication request recorded under a code your query didn’t expect can vanish from the result. Either way your app shows something that isn’t true, and a clinician might act on it.
We are a clinically led team, so we treat this as a patient safety problem, not a data formatting nuisance.
Because we hold every source in one place, we resolve both, once, before the data ever reaches your app.
On the identity side, our built-in Master Data Management resolves who is who. It uses advanced probabilistic linkage, weighing names, birth dates, identifiers, and other traits, to score how likely two records are the same person, so matches hold up even when the details don’t line up exactly. Every source then feeds one record instead of fragmenting into many.
On the meaning side, we don’t hand you raw data to figure out. We normalize every source into openly available, clinically vetted data models, inspired by the openEHR Clinical Knowledge Manager. Few integration vendors invest here. Most stop at raw FHIR and leave the modeling to you. We maintain a vetted model for thousands of clinical concepts and present them as simple tables that are ready to query.
Have questions?
Tell us what you're building and we'll show you exactly what you can integrate.
Where to go from here
That is our approach: direct integration across every surface your relationships unlock, with the data linked, normalized, and ready to query. No broker in the middle, and nothing locked behind a bundle you don’t need.
If you’re weighing us against other integration vendors, networks, and data platforms out there, the comparisons lay out where we differ and why. If you’re ready to build, the Quickstart takes you from your first connection to your first patient record in minutes.