When your system can’t push, we’ll come and get it
Plenty of good systems have an API but no webhooks, or only produce a nightly extract. HealthOS can poll your API, pick up your files or replicate your tables, and every one of those runs as a flow the provider can see and approve.
In short
- You give the provider a base URL and a credential. They install a connector and build a flow.
- HealthOS calls on a schedule, pages through what changed and maps it like any other source.
- The same connectors can write back, so a flow can send records to your system too.
Step by step: Let HealthOS read from your system, with screenshots of each step.
Your REST API
The HTTP endpoint connector calls a JSON API with whichever authentication it needs: an API key, a bearer token, basic authentication or OAuth 2 client credentials. A flow reads from it on a schedule, stages what comes back and maps it, the same as a webhook. As a destination it posts records to you.
Make it easy on both of us: support a “changed since” filter and stable paging, and give each record an id that doesn’t change when the record does.
Your FHIR server
If you run a FHIR R4 server, the FHIR connector searches it, follows the Bundle paging and brings the resources into a flow. As a destination it writes resources back, with a PUT when the resource has an id and a POST when it doesn’t. It authenticates with the same methods as the REST connector, which covers SMART Backend Services.
Files
For extracts, a flow can pick up files from SFTP or FTP, object storage or a document library, on a schedule. CSV, JSON and Excel files are read as records and mapped field by field. Files can also be uploaded by hand through bulk import, which helps with a one-off load during a migration.
Send a header row, keep column names stable between runs, and include the identifiers you hold. Those are what let each row match to the right person.
Database replication
Where the data sits in a database you already run, HealthOS can replicate chosen tables into its own copy, in full or incrementally, on a schedule. The common SQL databases are supported, and so is a JSON API treated as a source of tables. Flows then read from that copy, so your database isn’t queried by every flow in turn.
We ask for a read-only account, limited to the tables in scope. For incremental runs, a last-modified column or a rising key on each table keeps every run small.
Credentials
Whatever you give the provider, an API key, a client secret or a database password, is entered once in the connector’s set-up and stored encrypted. Each provider has their own connection with their own credential, so you can revoke one without touching the others.
Other routes
Tell us what your system exposes
An API reference or a sample extract is enough to start. We’ll tell you which route will be least work.