The clinical record is yours, and it is addressable.

Your record leaves in a standard format

The hardest question to answer honestly in this category is what happens to the clinical history if the relationship ends. TrueEval answers it with an endpoint rather than a clause. Patient records are addressable as FHIR R4, exportable as a complete FHIR collection Bundle through export-patient-records, and exportable as C-CDA 2.1 XML through generate-ccda — the format a receiving EHR ingests. The C-CDA carries allergies, medications, problem list, laboratory results and encounters sections against the standard CCD templateIds. Every export writes a PHI-access audit row before the bytes leave.

FHIR R4

Six endpoints, all serving application/fhir+json. The unified fhir-api endpoint returns a CapabilityStatement declaring fhirVersion 4.0.1 and its resource set. The five resource-specific endpoints authenticate with an API key scoped fhir:read and filter every query to the org that key resolves to; a single-record request returns the bare resource and anything else returns a searchset Bundle. Resources are profiled against US Core where a profile exists. Every request, success or failure, is written to an audit log with the endpoint, method, status, scopes required and whether they matched.

Authentication and scoping

Keys are 32 bytes of CSPRNG output, hex-encoded behind a te_ prefix. The plaintext is generated at the client, shown once, and never transmitted for storage — what reaches the server is a SHA-256 hash plus a ten-character lookup prefix, so a key cannot be recovered after issue. Every key resolves to exactly one org, carries an explicit scope array, an optional expiry, and a per-minute rate limit that defaults to 60. Scopes cover intake, patients, appointments, labs, notes, prescriptions, billing, queue and webhook management, plus fhir:read for the FHIR surface.

Partner REST API

api-treatment-catalog is the canonical catalog, served with a 60-second cache so a pricing change made in the admin UI reaches a storefront inside a minute with no cron and no local mirror. api-patient-intake and external-intake-webhook cover intake handoff, both idempotent on the partner's own external order id. api-patient-status polls visit, billing, prescription, lab-kit and timeline state at a configurable detail level.

Cost basis is redacted at the boundary

The catalog endpoint answers unauthenticated reads by design, because patient-facing prices are meant to be public. Wholesale cost and computed margin are not. A redaction step removes floor_cost_cents, mso_margin_cents and affiliate_margin_cents from a deep copy before any anonymous response is serialized — at both success exits, and after the snapshot cache rather than before it, so a cached payload can never leak fields the fresh path strips. API-key holders still receive them because the partner contract owes them.

Webhooks

Subscribe an HTTPS endpoint and pick your events: chart_review.completed, visit.completed, patient.intake_started, patient.intake_completed, prescription.dispatched, lab_kit.shipped, lab_kit.delivered, lab_results.available, payment.collected and payment.failed. Every event uses one envelope carrying id, timestamp, event, entity_type, entity_id, org_id and data, signed with HMAC-SHA256 keyed by your subscription secret and sent as X-Webhook-Signature. One builder produces the wire body for both live deliveries and test pings, so a receiver that parses the test parses production.

The delivery guarantee

Ordered, at-least-once delivery per destination. Events for one subscription are delivered serially in creation order, and the first failure stops that destination for the rest of the run so nothing behind a failed event is delivered ahead of it. Destinations are independent. Retries use full-jitter exponential backoff from a 30-second base capped at 6 hours, dead-lettering after 12 attempts, which unblocks the destination. There is no global ordering across destinations, and delivery is at-least-once rather than exactly-once — deduplicate on X-Idempotency-Key or X-Event-Id. Endpoints must be public HTTPS and redirects are not followed.

Versioning

The partner contract is versioned and every response carries contract_version. The change history lives in the handler rather than in a changelog that can drift from it. Fields are never removed from an existing payload in a minor version and never renamed; new fields are added alongside, so a client that ignores one keeps working. New fields may appear inside data at any v1.x bump, so parse defensively.

What this page does not claim

No throughput, volume or SLA numbers: several of these surfaces are built and integration-tested rather than exercised at volume, and publishing a fill rate or a latency guarantee TrueEval has not measured would not be honest. No uptime commitment, which belongs in a signed agreement. No security certification — the platform carries real controls including audit logging on every PHI access, break-glass records, consent versioning, SSRF-guarded egress and fail-closed authorization on patient-scoped reads, but controls are not an attestation. No live base URL or sandbox credential; the host and the key are issued together.

Frequently asked questions

Can I export my clinical data out of TrueEval?

Yes, and it is an API call rather than a contract negotiation. Patient records are addressable as FHIR R4 through six endpoints, exportable as a complete FHIR Bundle through export-patient-records, and exportable as C-CDA 2.1 XML through generate-ccda. Every export writes a PHI-access audit row before the bytes leave.

What authentication does the TrueEval API use?

An x-api-key header carrying a te_-prefixed key. TrueEval stores only the SHA-256 hash of the key, never the key itself, so it cannot be recovered after issue. Every key resolves to exactly one org, carries an explicit scope array, an optional expiry, and a per-minute rate limit. The unified FHIR endpoint additionally accepts a Bearer JWT.

Which FHIR version does TrueEval implement?

FHIR R4 (4.0.1), as declared by the CapabilityStatement the unified endpoint returns. Resources are profiled against US Core where a profile exists, and responses are served as application/fhir+json.

How are webhook deliveries secured and retried?

Every body is signed with HMAC-SHA256 keyed by the subscription secret and sent as X-Webhook-Signature. Delivery is ordered and at-least-once per destination, with full-jitter exponential backoff from a 30-second base to a 6-hour ceiling and a dead-letter after 12 attempts. Endpoints must be public HTTPS, and redirects are not followed.

Can I test my webhook receiver before any real traffic exists?

Yes. send-test-webhook signs a test envelope with your own subscription secret and POSTs it to your real endpoint through the same code path a live event uses, then returns the HTTP status your receiver gave. The test body is built by the same function that builds production bodies.

Does the partner catalog expose TrueEval's cost basis?

Not to unauthenticated callers. The redaction step strips floor_cost_cents, mso_margin_cents and affiliate_margin_cents from a deep copy of the payload before any anonymous response is serialized. API-key holders receive those fields because the partner contract owes them.