FHIR
ArkCloud exposes a small FHIR R4 facade over its own data at /api/fhir. It can be called only from a signed-in ArkCloud session; it is not an interface that an EHR or another external system can use. ArkCloud reads from outside FHIR servers in only two places, both in Rehab and both set up per partner: the referral exchange described below, and the outside records import from a hospital.
FHIR R4 view of your own dataPartially 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.
What the facade does
Requests go to /api/fhir/<ResourceType> (search) or /api/fhir/<ResourceType>/<id> (read), scoped to the signed-in user's organisation. /api/fhir/metadata returns a CapabilityStatement.
| Resource | Read | Search | Create (POST) |
|---|---|---|---|
| Patient | Yes | _id, identifier, name, birthdate, gender, _count (at most 100 per page) | Admin only (other roles: 403 forbidden) |
| Coverage | Yes | Yes | No |
| Claim | Yes | Yes | Refused (Admin: OperationOutcome not-supported; other roles: 403 forbidden) |
| ExplanationOfBenefit | Yes | Yes | No |
| Encounter | Yes (Rehab) | _id, patient, date | No |
| Appointment | Yes (Rehab) | _id, patient, date | No |
| Condition | Yes (Rehab) | _id, patient, category, clinical-status | No |
| CarePlan | Yes (Rehab) | _id, patient, date | No |
| DocumentReference | Yes (Rehab) | _id, patient, date | No |
| Practitioner | Yes | _id, name, identifier | No |
| Organization | Yes | _id, name, identifier | No |
Creating a resource with POST needs the "edit account details" permission, which only the Admin role holds; any other role receives HTTP 403 with an OperationOutcome whose code is forbidden. Searching with POST /api/fhir/<ResourceType>/_search is a read and is open to every role the facade admits. The CapabilityStatement states that SMART on FHIR / OAuth 2.0 authorization is not offered and lists only the interactions above: it does not advertise Patient update, or transaction, batch or system-wide search.
Sample request
Made from a browser that is signed in to ArkCloud (synthetic data):
GET /api/fhir/Patient?name=example&_count=10
Accept: application/fhir+json
Cookie: <ArkCloud session cookie>
200 OK
{
"resourceType": "Bundle",
"type": "searchset",
"entry": [
{ "resource": { "resourceType": "Patient", "id": "example-id",
"name": [{ "family": "Example", "given": ["Test"] }] } }
]
}FHIR referral exchange (Rehab)
A Rehab administrator can configure a referring partner under Rehab settings, Integrations, Referral exchange. ArkCloud then receives FHIR R4 referrals (ServiceRequest, Patient, Practitioner, Coverage) - pulled from the partner with SMART Backend Services (a private-key JWT, never a client secret) or pushed to ArkCloud with an HMAC signature - matches the patient without ever merging records, and reports accepted, scheduled, completed or declined back to the referrer.
Verification: contract-tested against a simulated partner only (mocked network). No partner connection has been proven, and validating the settings checks their shape without contacting the partner.
Not built
What it would take
This is a list of engineering gaps, not a delivery commitment. For an external system to use FHIR with ArkCloud, the product would need at least: OAuth 2.0 client registration and token issuance (or SMART Backend Services), scope enforcement per resource, update and bundle interactions with role checks, and tests for each.
Until then, claims and remittance travel through the clearinghouse mailbox once it is connected, outside records are uploaded in Rehab, and anything else is implementation work arranged with support (see custom integrations).