Integrations

The systems ArkCloud connects to.

Each integration carries one of four states: verified operational, configured with verification pending, customer setup required, or planned. Only a recorded real exchange counts as verified - credentials alone do not. No EHR connection has yet been proven against a live vendor system.

Ask about a specific system See the status board

A bright patch panel where blue and teal cables from many directions arrive and are gathered into one organized trunk.

Read on this request

Verified, pending, your setup, planned.

Each connection's state is read when this page loads, and the rows further down use the same labels. Verified means this service has exchanged real data with the provider; everything else says what is still missing.

Verified operational

This service has exchanged real data with the provider, on the date the row gives.

Email deliveryVerified operational

Configured - verification pending

Built and switched on here, but not yet confirmed with the provider. Credentials held are not proof it works.

FHIR R4 APIAvailable
Twilio (SMS)Configured, verification pending
Single sign-onConfigured, verification pending

Customer setup required

Built. Nothing is exchanged until your organisation connects its own account or credentials.

FHIR referral exchangeSet up per organisation
Outside records import (FHIR R4, C-CDA)Set up per organisation
Clearinghouse (X12 EDI)Built, not connected
Real-time eligibility (Availity)Built, not connected
Payment gatewayBuilt, not connected
Amazon ConnectBuilt, not connected
Outbound webhooksBuilt, not connected
Distributed tracingBuilt, not connected
Background worker alertsBuilt, not connected
Custom integrationsBuilt, not connected

Planned

Not built, or built but not reachable by any customer today.

EpicBuilt, not usable yet
Oracle Health (Cerner)Built, not usable yet
MEDITECHNot built
HL7 v2 interfacesBuilt, not usable yet

Built, not usable yet: Code exists in the repository, but no customer can use it today - the summary says why. Nothing is exchanged with the external system.
Not built: Nothing a customer can use exists yet; where code exists in the repository, the summary says so and why it cannot be reached. Nothing with this label is working software.
Available: Implemented, and needs no external credential.
Set up per organisation: Implemented. The credentials belong to your organisation, so an administrator creates the connection; nothing is exchanged until they do. Implemented is not the same as proven: see below for whether it has worked against the real system.
Built, not connected: The implementation exists. This deployment holds no credentials for it, so nothing is being exchanged.
Configured, verification pending: Implemented, and this deployment holds the credentials to use it. That has not been verified against the provider - an administrator can test the connection.
Verified operational: Implemented, the credentials are held, and this service has exchanged real data with the provider (the summary says when and how).

Requires a clearinghouse connection

Claims leave through your clearinghouse, not ours.

ArkCloud builds and checks the 837P. Sending it, and receiving the 835 remittance back, happens only through a clearinghouse mailbox your organization connects.

Clearinghouse, on this service: Built, not connected

Sending claims to payers and receiving remittance needs a clearinghouse connection, which is built but not yet connected on this service.

Claim to remittance

Illustrative sequence · synthetic data · requires a clearinghouse connection

837P built
Your clearinghouse
999 / 277CA
835 posted

837P built· In ArkCloud

Fictional patient · 97110 × 2 units · generated and validated in ArkCloud

Electronic health records

ArkCloud supports standards-based healthcare interoperability using FHIR R4. A Rehab administrator can configure two kinds of hospital connection: hospital record import (read-only) and the electronic referral exchange. Imported records arrive as proposals a licensed clinician reviews; nothing reaches the chart unreviewed, and nothing is written back to any EHR. No EHR vendor connection is verified yet: the generic SMART Backend Services path has run only against the public SMART Health IT reference sandbox (synthetic data, 2026-10-03). Each hospital must activate ArkCloud's client and agree to release records before a real connection exists. None is certified or marketplace-listed, there is no SMART on FHIR app launch into an EHR, and the older EHR sync API still refuses every request.

Hospital record importSet up per organisationNot yet proven with a partner
A per-hospital FHIR R4 connection using SMART Backend Services (signed JWT), checked against the hospital's CapabilityStatement and token endpoint. Staff import a patient's conditions, procedures, allergies, medications, observations (laboratory, vital signs, oxygen), encounters, clinical notes, imaging reports and study metadata, and service requests. Imports record purpose of use and authorization basis, are retried, and are listed in the Interoperability Center. Images stay at the source: there is no DICOM retrieval.
Limit: Run only against the public SMART Health IT reference sandbox with synthetic data; no hospital has activated a connection.
Technical evidence
lib/outside-records/connections.tslib/outside-records/fhir/import.ts
EpicBuilt, not usable yetNot yet proven with a partner
A hospital record import profile built to Epic's SMART Backend Services requirements (per-connection JWKS URL), read-only. Not yet verified against an Epic system. Not Showroom or App Orchard listed.
Limit: Tested only against ArkCloud's own synthetic Epic-style test profile.
Technical evidence
lib/interop/vendor-compatibility.ts
Oracle Health (Cerner)Built, not usable yetNot yet proven with a partner
A hospital record import profile using SMART Backend Services, read-only. Not yet verified against an Oracle Health system, and not Oracle Health certified.
Limit: Tested only against ArkCloud's own synthetic Oracle-style test profile.
Technical evidence
lib/interop/vendor-compatibility.ts
MEDITECH, athenahealth, NextGen, eClinicalWorksNot built
Not built. A MEDITECH connection can be recorded, but it is shown as unsupported where the hospital offers only SMART app launch, which ArkCloud does not have.
Technical evidence
lib/interop/vendor-compatibility.ts
FHIR R4 bundles and C-CDA documentsSet up per organisationNot yet proven with a partner
Staff upload a FHIR R4 Bundle or C-CDA file they received; its contents become proposals for clinician review. No network exchange.
Limit: Tested on synthetic files only.
Technical evidence
lib/outside-records/fhir/bundle-ingest.tslib/outside-records/ccda/import.ts
Electronic referral exchangeSet up per organisationNot yet proven with a partner
Receives FHIR R4 referral bundles by pulling them (SMART Backend Services client) or by an HMAC-signed push, matches the patient with staff review of ambiguous matches, and sends status updates back to the referrer. Contract-tested against a mocked network only.
Technical evidence
lib/ehr/referral-exchange/inbound.ts
HL7 v2Built, not usable yetNot yet proven with a partner
A library that parses and generates HL7 v2 messages, usable by an administrator one message at a time, and a single-file ADT/ORU upload sandbox for outside records that is off by default. There is no MLLP listener and no inbound HL7 interface, so no EHR can send ArkCloud an HL7 feed.
Technical evidence
lib/hl7/parser.tslib/outside-records/hl7v2/ingest.ts

Clearinghouses and EDI

Claims leave as X12 837P and remittances return as X12 835; claim status inquiries go out as 276 and come back as 277, and batch eligibility as 270 and 271. The clearinghouse is the route; the X12 generation and parsing are ours. Everything travels through one vendor-neutral SFTP mailbox rather than a vendor-specific API.

Clearinghouse SFTP mailboxBuilt, not connected
837P claims (837I for a facility that bills on the UB-04) are uploaded to your clearinghouse's SFTP mailbox; its 999, 277CA and 835 replies are collected from the same mailbox every 15 minutes and applied to the claims they name. The same mailbox carries a daily 276 claim status inquiry for claims still waiting two weeks after submission, whose 277 answers update claim status but never post money; batch 270 eligibility inquiries, whose 271 answers are recorded like real-time ones, when no real-time eligibility connection exists; and 834 enrollment files, which become coverage changes for staff to approve. Nothing is transmitted until the mailbox credentials are configured.
Limit: Not yet run against a live clearinghouse, and not configured on the hosted service today.
Technical evidence
lib/edi/mailbox/lib/jobs/clearinghouse-mailbox.tslib/jobs/clearinghouse-inquiries.tslib/edi/claim-status-inquiry.tslib/eligibility/batch-mailbox.tslib/edi/institutional-claim.tslib/edi/enrollment/
Availity eligibility (270/271)Built, not connected
Staff-initiated real-time eligibility checks through Availity's API, using your Availity credentials. Without them a check is queued as a batch 270 through the clearinghouse mailbox when that is configured, and labelled as queued until the payer answers; with neither, no check is made. Simulated coverage is never returned in production.
Limit: Not yet validated against Availity, and not configured on the hosted service today.
Technical evidence
lib/integrations/clearinghouse/availity.tsapp/actions/eligibility.ts
X12 837 and 835Built, not connected
Claim generation and validation, and remittance posting with an exceptions queue for anything that cannot be matched.
Technical evidence
lib/edi/claim-submission.tslib/edi/era-posting.ts

Payments

Patient payments and payment plans. In production a processor must be configured; the system refuses to run rather than silently reporting a payment that never happened.

StripeBuilt, not connected
Card payments, including Stripe Elements in the patient portal. Online patient payment stays off until Stripe is connected.
Limit: Not configured on the hosted service today, so no card payment can be taken there yet.
Technical evidence
lib/payment-processor.ts

Communications

Statements, reminders and notifications to patients and staff.

SendGridVerified operational
Transactional email, including statement delivery.
Limit: Email is sent through SendGrid from the authenticated arkcloudhealth.com domain; delivery to a staff mailbox was confirmed on 3 November 2026. The Status page shows the live state.
Technical evidence
lib/email.ts
TwilioConfigured, verification pending
SMS notifications.
Limit: Configured on the hosted service; verification pending. US carrier registration (A2P 10DLC) for the sending number is still being completed (26 October 2026), so texts to US phones may be filtered until it is done. STOP replies are recorded as SMS opt-outs. The Status page shows the live state.
Technical evidence
lib/sms.tslib/integrations/twilio.ts

Identity

One ArkCloud account per person, federated to the identity provider the organization already runs.

Google WorkspaceConfigured, verification pending
OIDC single sign-on with PKCE.
Technical evidence
lib/auth/config.ts
Microsoft Entra IDBuilt, not usable yet
The OIDC sign-in is written but not usable on the hosted service today. Ask us if your organization needs it.
Technical evidence
lib/auth/config.ts
SAMLBuilt, not usable yet
Not available. ArkCloud refuses every SAML assertion until it can verify SAML signatures with a vetted library.
Technical evidence
lib/auth/saml-availability.ts

For procurement: the services ArkCloud runs on

Not third-party product integrations so much as the services ArkCloud runs on. Listed because procurement asks where data goes.

S3-compatible object storage. Documents and exports. One storage API across environments, so local and cloud are not two divergent code paths.
Cold storage archival. Long-term retention of aged records to Glacier-class storage. It needs an S3 archive bucket and AWS credentials, and archives nothing without them.

What the labels mean

A label says whether a connector is built and whether this service holds what it needs to use it. It is not a vendor partnership or a marketplace listing. “Verified operational” means this service has exchanged real data with the provider; “Configured, verification pending” means the keys are in place but that has not happened yet. Where credentials are absent the system returns an explicit error rather than a silent success. “Not yet proven with a partner” means the code has never been run against a real vendor or partner system; that is the state of every built EHR, FHIR and HL7 entry above.

Ask about a specific system

Page last updated November 4, 2026

Tell us which systems your clinic runs on.

Every row above names the code behind it and what it does not do yet. Ask us about the ones your clinic depends on.

Ask about a specific system The readiness checklist