Integrations
Integrations: overview and status
What ArkCloud Health exchanges with outside services today, what needs a connection set up first, what is built but switched off, and what it does not do. Read this before you plan a go-live.
Written for: Clinic administrators · Billing and front desk leads · Buyers and implementation teams
How to read the status labels
A screen that exists is not the same as a workflow that works. Each label below says which one you have. The same labels are used throughout the documentation.
- Available
- Works in ArkCloud today with no special setup.
- Partially available
- Some of it works today; the page says exactly which part.
- Needs an external connection
- Built in ArkCloud, and needs an account or contract with an outside service before it works.
- Available with configuration
- Works once your organisation switches it on or completes the setup it needs.
- Not independently verified
- Built, but not yet proven end to end in production. Ask us before relying on it.
- In development
- Being built. Not available to use yet.
- Not available
- ArkCloud does not do this.
Works today
These work on ArkCloud's hosted service with no outside account. Several are the manual half of a workflow whose electronic half needs a connection: you can record the benefits a payer told you by phone today, while an electronic eligibility check needs a vendor connection.
| Capability | Status | What that means here |
|---|---|---|
| Building and validating claim files (837P and 837I) | Available | ArkCloud builds each claim as a professional claim (837P), or an institutional claim (837I) when the billing facility is set up to bill on the UB-04, and checks it before it can be sent. |
| Email to patients | Available | Portal invitations, statements, receipts, reminders and notifications are emailed from ArkCloud's hosted service, from an authenticated arkcloudhealth.com address. |
| Sign in with Google | Available | Staff can sign in with a Google account. The same lockout and two-factor rules apply as for a password sign-in. |
| Entering a referral by hand (including faxed referrals) | Available | Staff enter a referral from a fax, letter or phone call in Rehab or Access. Converting the referral creates the patient and the episode of care. ArkCloud does not receive faxes itself. |
| Recording benefits a payer stated | Available | Front desk and billing staff record what the payer said by phone or portal - copay, coinsurance, deductible, out-of-pocket, network status, visit limit and the call reference - on the episode in Rehab or on the Benefits worklist in Access. It is labelled as recorded, never as a payer response. |
| Tracking prior authorizations | Available | Staff record each authorization by hand - payer, service, contacts and references, decision, approved dates and visits - and ArkCloud counts visits used against it as charges are posted. The billing-readiness checks read it. |
| Recording a physician's plan-of-care certification | Available | The physician signs the plan of care outside ArkCloud. A clinician with signing authority, or a Rehab administrator, then records who certified it, their NPI, the date signed and the date the certification runs to; ArkCloud shows when it has expired. |
| Uploading outside records | Available | Staff upload a document or an exported record file, match it to the patient, and a licensed clinician reviews what it contains before anything reaches the chart. |
| Capability | Status | What that means here |
|---|---|---|
| Text messages to patients | Partially available | Texts are sent from ArkCloud's hosted account, only to patients who have agreed to texts, and STOP replies are honoured. US carrier registration (A2P 10DLC) for the sending number is not yet complete, so texts to US phones may be filtered until it is. Calls are not available. |
| Member enrollment files (834) into coverage proposals | Partially available | Staff can upload an 834 benefit enrollment file today; each coverage change becomes a proposal that a person approves or rejects, and nothing changes a patient's coverage until it is approved. Receiving 834 files automatically needs the clearinghouse mailbox.Requires: The clearinghouse mailbox, for automatic receipt only. |
| FHIR R4 view of your own data | Partially available | Signed-in users can read and search your organisation's own records as FHIR R4 resources and create a patient. Outside systems cannot use it, because it accepts only an ArkCloud sign-in, not SMART on FHIR or OAuth. |
Needs a connection first
These are built and do nothing until an outside account is connected. None of the service-wide connections below (clearinghouse, eligibility vendor, Stripe, Amazon Connect) is connected on the hosted service today. The referral and hospital-record connections are set up by each organisation, and neither has yet been proven with a real partner system.
| Capability | Status | What that means here |
|---|---|---|
| Sending claims to payers | Needs an external connection | Claims are built, not transmitted, until a clearinghouse mailbox is connected. On ArkCloud's hosted service no clearinghouse is connected today, so a submitted claim answers "Not sent" and stays Pending.Requires: A clearinghouse account with an SFTP mailbox, entered once for the deployment by ArkCloud, and your own enrollment with each payer. |
| Collecting acknowledgements and remittance (999, 277CA, 835) | Needs an external connection | Automatic collection of acknowledgements and electronic remittance (ERA) every 15 minutes needs the clearinghouse mailbox, which is not connected. Staff can upload an 835 or acknowledgement file on ERA/EOB Posting, or key a paper EOB, today.Requires: The clearinghouse mailbox, plus ERA enrollment with each payer through your clearinghouse. |
| Claim status inquiries (276/277) | Needs an external connection | Built: once a day ArkCloud asks the payer about claims still awaiting a decision 14 days after submission, and records the answer. It runs only through a connected clearinghouse mailbox, so no inquiry is sent on the hosted service today.Requires: The clearinghouse mailbox. |
| Real-time eligibility checks (270/271) | Needs an external connection | Built: a check sent while you wait, with the payer's answer stored. It needs a real-time eligibility vendor account, which is not connected on the hosted service, so no check is answered today.Requires: Availity credentials, configured once for the deployment by ArkCloud. |
| Batch eligibility through the clearinghouse | Needs an external connection | Without a real-time connection, a check can be queued and sent as a batch 270 through the clearinghouse mailbox, with the payer's 271 recorded when it arrives, usually hours later. The mailbox is not connected on the hosted service.Requires: The clearinghouse mailbox. |
| Card payments, saved cards and AutoPay | Needs an external connection | Built on Stripe, with each practice paid into its own Stripe account. Not switched on for the hosted service today: payments run in a non-charging mode and no Stripe keys are set, so no card can be charged. Payments received another way can still be recorded. No ACH.Requires: Stripe enabled for the deployment by ArkCloud, then your administrator connects your practice's Stripe account. |
| Amazon Connect softphone | Needs an external connection | Built: an embedded softphone that opens the caller's account. It needs an Amazon Connect instance and is not set up on the hosted service, so the Call Center menu does not appear.Requires: An Amazon Connect instance, configured for the deployment. |
| Electronic referrals from a referring EHR (FHIR) | Not independently verified | Built: referrals received over FHIR R4 from a referring organisation's system arrive on Rehab's Electronic referrals screen for a person to review, and status updates go back to the referrer. Each organisation sets up its own connection, and it has never been proven with a real referring partner.Requires: A referral-exchange connection your Rehab administrator sets up with the referring organisation. |
| Importing records from a hospital system (FHIR) | Not independently verified | Built: a read-only import from a hospital's FHIR R4 service into proposals a clinician reviews. Each hospital must register ArkCloud first; it has been tested only against ArkCloud's own test profiles and a public test server, never against an Epic or Oracle Health system.Requires: A connection your Rehab administrator sets up with each hospital. |
| Sending signed notes and plans to physicians | Needs an external connection | ArkCloud has the sharing workflow - verified recipients, a confirmation step, a purpose (for information, or asking the physician to certify a plan of care) and delivery tracking - but no Direct messaging or fax service is connected, so nothing is sent to a physician today.Requires: A Direct (HISP) or fax service, under a business associate agreement, connected to ArkCloud by us. |
Built, switched off
The ArkCloud API and outbound webhooks are built and experimental. They are switched off for the whole hosted service, so no organisation can turn them on yet. Ask us if you need them.
| Capability | Status | What that means here |
|---|---|---|
| ArkCloud API (read-only, API keys) | Available with configuration | Built and switched off on the hosted service. When on, it is experimental and read-only: claims, appointments and the event list, using scoped keys your administrator creates.Requires: ArkCloud switches the API on for the deployment, then your administrator enables it and creates keys. |
| Outbound webhooks | Available with configuration | Built and switched off on the hosted service. When on, ArkCloud sends signed event notices (identifiers and statuses, not patient details or note text) to an HTTPS address your administrator registers and verifies, with retries and a delivery log. Never yet run against a customer's receiver.Requires: ArkCloud switches the API on for the deployment, then your administrator enables webhooks and verifies an endpoint. |
Not available
Plan for these to happen outside ArkCloud. Where a step is manual, the related page says how to record what you did.
| Capability | Status | What that means here |
|---|---|---|
| Electronic prior authorization requests (278) | Not available | ArkCloud does not send authorization requests to payers. Your team submits by phone, fax, mail or the payer's portal and records the result. |
| Payer (provider) enrollment | Not available | ArkCloud does not enroll your practice or clinicians with payers, for claims, ERA or EFT, and does not track enrollment applications. Your practice does this with each payer and your clearinghouse. |
| Direct secure messaging | Not available | ArkCloud has no Direct secure messaging address or connection. |
| Receiving or sending faxes | Not available | There is no fax line or fax service in ArkCloud. A faxed document is entered or uploaded by staff. |
| Two-way EHR synchronisation (Epic, Oracle Health, MEDITECH) | Not available | ArkCloud does not synchronise with, or write back to, a hospital EHR, and has no MyChart integration. Every EHR sync operation is refused. |
| HL7 v2 interface (ADT, SIU, DFT feeds) | Not available | There is no HL7 interface: no listener, no inbound feed and nothing sent. A message library exists that an administrator can use to check or build a single message. |
| Microsoft or SAML single sign-on (Entra ID, Okta, OneLogin) | Not available | Not available. Microsoft sign-in is written but not switched on and has no sign-in button; SAML is refused until ArkCloud can verify SAML signatures. There is no SCIM user provisioning. |
What this service holds credentials for
Each integration page opens with a banner read from the running service. This table gathers them in one place. It answers a narrower question than the tables above: whether the account details for a connection are present, not whether your workflow is ready.
| Connection | On this service |
|---|---|
| Epic | Built, not usable yet |
| Oracle Health (Cerner) | Built, not usable yet |
| MEDITECH | Not built |
| HL7 v2 interfaces | Built, not usable yet |
| FHIR R4 API | Available |
| FHIR referral exchange | Set up per organisation |
| Clearinghouse (X12 EDI) | Built, not connected |
| Real-time eligibility (Availity) | Built, not connected |
| Payment gateway | Built, not connected |
| Twilio (SMS) | Configured, verification pending |
| Email delivery | Verified operational |
| Amazon Connect | Built, not connected |
| Single sign-on | Configured, verification pending |
| Outbound webhooks | Built, not connected |
| Custom integrations | Built, not connected |
Guides by task
- Referrals and physician communication - receiving referrals and recording plan-of-care certification.
- Eligibility and authorization services - what is manual today and what needs a connection.
- Provider enrollment - what your practice does with payers before claims can be sent.
- Clearinghouse setup, payment gateways, email and text messages.
- EHR systems (Epic, Oracle Health, MEDITECH), HL7 and FHIR.
Asking for an integration
Tell us which system you need to connect and what has to flow in each direction. We will say plainly whether it can be done today. See Custom integrations or contact us.