Sources and connections
How Medblocks names the systems you connect to and the live links created from them.
Medblocks connects your product to healthcare systems such as EHRs, payers, networks, and patient portals. These systems are called sources.
A connection is the live link to a source after it has been configured or authorized. A patient approving access, a clinician launching your app, or an organization adding credentials can all create connections.
Most docs start with the source you want to reach, then show how a connection is created and monitored.
Sources
Sources are catalog entries: Epic, Oracle Health, athenahealth, eClinicalWorks, CMS Blue Button, payer APIs, networks, and other systems that expose healthcare data or workflow surfaces.
A source can have a display name, logo, portal URL, FHIR base URL, vendor type, and setup requirements. The source exists before any patient or organization authorizes access.
Medblocks keeps the source-specific details on its side, like OAuth, SMART on FHIR, endpoint discovery, token refresh, rate limits, and portal differences. Your app works with one connection model instead of one implementation per source.
Use the Directory to browse and search available sources.
Connections
A connection exists after authorization. How it is created depends on the integration pattern.
| Pattern | Who authorizes | What it unlocks |
|---|---|---|
| Patient access | The patient | Their own records from EHRs, payers, and other patient-facing systems. |
| Clinician workflow | The provider organization | Your app inside the clinician’s EHR workflow. |
| Backend | The provider organization | Server-to-server sync without a user present. |
| Network | A treatment relationship | Records across exchange networks. |
Each pattern is unlocked by a real relationship you already have, not one enterprise contract that bundles every surface.
Connections have a lifecycle.
| State | Meaning |
|---|---|
active | Access works and records can flow. |
failed | Authorization did not complete. |
refresh_failed | Access worked before, but the refresh token stopped working. |
expired | Access is no longer usable. |
Your app should act on connection state, not just on whether a browser flow finished.
Bring your own credentials
Medblocks is designed around direct integration. Some sources need credentials from your app or organization before they can be used.
That matters for two reasons.
- Your relationship stays yours. The access is tied to your app, your customer relationship, and your compliance workflow.
- Your branding stays yours. Patients and clinicians approve the app you registered, not a generic brokered bundle.
Configure these credentials in Configure connections. Medblocks stores and uses them server-side to operate the connection, refresh access, and run the right integration pattern.
In the docs
- Find connections shows how patient-facing apps search the connection catalog.
- Authorization explains how patient approval turns into an active connection.
- After connection shows how to read connection state.
- Configure connections shows where workspace credentials live in the dashboard.