Integrations
A destination is configuration plus one small adapter.
An adapter knows how to hand an already mapped payload to one system and how to read its answer. It does not know what a patient is or which canonical field feeds which of its own fields. That boundary is why this list can grow without the pipeline changing.
| Destination | Status | Notes |
|---|---|---|
| NetSuite | In test | Sales order creation over the REST record API, with idempotency so a retry after a timeout cannot create the order twice. Token based auth is not finished and this has not yet run against a live account. |
| HTTPS endpoint | In test | A JSON post to your own middleware or any modern billing API. Refuses to send over plain HTTP. |
| Brightree | Planned | DME order and patient creation. |
| NikoHealth | Planned | Order intake and patient sync. |
| DaisyBill | Planned | Workers compensation billing, where documentation requirements are strictest. |
| DrChrono | Planned | Practice side record creation. |
| FHIR | Planned | ServiceRequest, Coverage and Patient resources against a FHIR R4 endpoint. |
| HL7 v2 | Planned | ORM and ADT messages over MLLP for hospital feeds. |
| SFTP CSV | Planned | A scheduled drop for systems with no API, which is more of them than anyone admits. |
In test means the code exists and is covered by tests but has not been pointed at a live account. Planned means designed and scheduled, not written. We list it this way so you can hold us to a date rather than discover the gap during implementation.
Need one that is not on this list?
If it has an API or accepts a file, it is an adapter and a mapping profile.
Talk to us