Integration Architecture · v1.2

Five EDI files in. Two files out. No proprietary anything.

JetPatient implements the standard X12 transaction set plus FHIR R4 as an alternative transport. Identity is OAuth 2.0 + SAML 2.0 + SCIM. The full spec is downloadable below — including sandbox keys, Postman collection, and the exact companion-guide deltas vs. CAQH CORE Phase IV.

Download Integration Spec (PDF) Request sandbox keys →
Architecture · Three planes

Data, identity, application — three planes, one platform

Plan-agnostic by construction. The TPA remains plan-of-record; JetPatient sits next to it as a navigation layer that produces ranked outreach cohorts and routed-care outcomes.

DATA PLANE IDENTITY PLANE APPLICATION PLANE TPA WebTPA · Trustmark Healthcomp · EBMS · … claims engine JetPatient Edge Tokenization · mTLS SFTP · HTTPS · FHIR integration boundary JetPatient Core PREDICT inference Guardian state VPC us-east-1 834 · 837 · 270 835 · 271 tokenized Sponsor IdP Okta · Azure AD · Ping SAML 2.0 · SCIM Auth0 (Broker) RBAC · MFA · audit OAuth 2.0 + mTLS JP Apps Guardian · PREDICT API role-scoped tokens Guardian Console Benefits Manager + TPA Admin + Broker SPA · HTTPS + WSS <300ms p95 PREDICT API Batch scoring + on-demand HTTPS REST <800ms / 1k members Outreach Engine SMS + email + member portal SendGrid · Twilio Webhooks TPA event consumer HTTPS POST 5× retry · backoff
Implementation

What you implement against

If your platform already produces standard X12 and you have a SAML IdP, you have everything you need to integrate.

1

Data plane

Five inbound transactions, two outbound. Custom CSV supported as a fallback for legacy platforms.

  • Inbound: 834 eligibility (monthly + delta)
  • Inbound: 837 claims (36–60mo bulk + monthly)
  • Inbound: 270 eligibility inquiry (real-time)
  • Outbound: 271 eligibility response
  • Outbound: 835 remittance (wrap only)
  • Alt: FHIR R4 Patient · Coverage · EOB
2

Identity plane

OAuth 2.0 client-credentials for M2M, SAML 2.0 + SCIM 2.0 for humans. Auth0 broker; Okta / Azure AD / Ping all tested.

  • M2M: OAuth 2.0 + mTLS pinning
  • Token TTL: 15min access · 24h refresh
  • SSO: SAML 2.0, SP- and IdP-initiated
  • Provisioning: SCIM 2.0 lifecycle
  • MFA: TOTP + FIDO2; mandatory for Admin roles
  • Cert rotation: 90 days
3

Application plane

Guardian for humans, PREDICT API for systems, webhooks for event consumers. All HTTPS-only with documented latency SLAs.

  • Guardian Console: SPA, HTTPS + WSS, <300ms p95
  • PREDICT API: HTTPS REST, <800ms per 1k members
  • Outreach: SendGrid + Twilio (no custom SMTP)
  • Webhooks: 5 retries, exponential backoff
  • Status page: status.jetpatient.com
Authentication · Worked example

Get a token, query a member, write the audit log

The OAuth 2.0 client-credentials flow with mTLS at the edge. Three calls; complete round-trip in well under a second.

1 · Mint an access token
POST https://auth.jetpatient.com/oauth/token
Content-Type: application/x-www-form-urlencoded
[mTLS client certificate pinned at edge]

grant_type=client_credentials
&client_id=tpa-webtpa-prod
&client_secret=[redacted — issued under MSA]
&audience=https://api.jetpatient.com
&scope=read:members write:outreach

// 200 OK
{
  "access_token": "eyJhbGc…",
  "token_type": "Bearer",
  "expires_in": 900
}
2 · Fetch a Patient resource (FHIR R4 alt to 270/271)
GET https://api.jetpatient.com/fhir/r4/Patient?identifier=https://jetpatient.com/tokens|jp-tok-9f3d
Authorization: Bearer eyJhbGc…
Accept: application/fhir+json

// 200 OK
{
  "resourceType": "Patient",
  "id": "jp-tok-9f3d",
  "identifier": [{ "system": "https://jetpatient.com/tokens", "value": "jp-tok-9f3d" }],
  "meta": { "security": [{ "code": "HOPERAT" }] }
}
3 · Read the audit-log entry the call just wrote
GET https://api.jetpatient.com/audit-log?subject=jp-tok-9f3d&since=2026-06-03T14:00:00Z
Authorization: Bearer eyJhbGc…

// 200 OK — every read and write is logged with actor, scope, IP, and full request hash
[{
  "actor": "tpa-webtpa-prod",
  "action": "fhir.read.Patient",
  "subject": "jp-tok-9f3d",
  "at": "2026-06-03T14:21:08.412Z",
  "ip": "52.x.x.x"
}]
For your integration engineer

The full spec, the sandbox, the Postman collection.

Everything you need to start UAT today. Sandbox keys ship after MSA + BAA are countersigned; the PDF spec and Postman collection are linked here directly.

Integration Architecture Spec v1.212-page PDF · EDI · FHIR · OAuth · SAML · SLAs Sandbox keys + Postman collectionIssued under MSA + BAA · 5,000-member synthetic census Compliance AttestationHIPAA · SOC 2 status · AI Act readiness · sub-processors
Operational SLAs

What we hold ourselves to, in writing

Every SLA below is documented in the MSA with a measurable trigger and a contractual remedy.

99.9%
Data-plane uptime
Rolling 90 days · status.jetpatient.com live
99.9%
Console uptime
Guardian + member portal · rolling 90 days
<15 min
834 ingest ack
Per file · automatic 999 functional acknowledgment
<15 min
Sev-1 notification
Per incident · status page + named-contact email
Next step

Schedule a 30-minute integrations call

Our integrations lead, your platform team, and (optionally) the sponsor's benefits team. We walk the spec, demo the sandbox, and answer the platform-specific edge cases.

Email integrations@jetpatient.com Or just grab the spec (PDF)