Skip to main content

Patient Prism Data Access Guide

This guide explains the common ways to pull data from Patient Prism into your own systems (data warehouse, BI tool, internal dashboards), including when to use Scheduled Exports vs. API, and how GraphQL and REST fit together.

 

1) What “Do you have API access?” usually means

When a someone asks about “API access,” they typically mean:

  • “Can we get Patient Prism data into our own tool or warehouse?”

  • “Can we build an automated pipeline (ETL/ELT) that runs on a schedule?”

In Patient Prism, there are two main approaches:

  1. Scheduled Exports (no-code / low-code)

  2. Direct API access (code-based integration)

 

 

 

2) Two ways to pull data from Patient Prism

Option A: Scheduled Exports (recommended for most)

Best when: you want a regular “dump” of data files without building/maintaining API pagination, auth, and rate-limit handling.

How it works:

  1. You link a cloud storage bucket (e.g., AWS S3, Azure Blob Storage, or Google Cloud Storage).

  2. You configure an export (filters, date lookback, cadence, format).

  3. Patient Prism automatically generates files on schedule and drops them into your bucket.

  4. Your systems ingest from the bucket (often via an event trigger / scheduled job).

Pros

  • Minimal engineering lift

  • No pagination logic

  • Easy to operationalize with file-based ingestion pipelines

Cons

  • Some datasets (notably transcripts) may not be fully available via exports depending on your use case/setup; many teams prefer API for transcript retrieval.

 

Option B: API (direct connection)

Best when: you want a direct integration into your middleware/warehouse, or you need transcripts and other items that are easiest via API.

In practice, many clients use two API “paths”:

  • GraphQL API for call/call-related data and metrics

  • REST API for transcripts (pulled per call)

Pros

  • Flexible queries (especially with GraphQL)

  • Supports pulling specific datasets (raw or aggregated)

  • Transcripts are typically handled cleanly via API

Cons

  • Engineering effort: auth, pagination, retries, backoff, monitoring

  • Must plan around analysis timing (data can change shortly after a call)

 

 

 

3) GraphQL vs. REST: what you use each for

GraphQL API (reporting + call data)

Use GraphQL when you want:

  • Call records / metadata (“a call happened at X time from Y number… plus enriched Prism fields”)

  • Many of the same metrics you see in the Prism UI

  • Either:

    • Raw-ish data for ingestion, or

    • Pre-computed aggregations (so Prism does the grouping/counting and returns results)

Why it’s powerful: you can request exactly the fields you want, and you can also fetch aggregated metrics without indexing everything yourself.

 

 

 

REST API (transcripts and certain resources)

Transcripts are typically retrieved via a REST endpoint.

Important behavior: transcripts are not included in the “index/list of calls” response due to size.
Instead, the typical pattern is:

  1. Use GraphQL to fetch a list of calls (with call IDs) for a time window

  2. Iterate through the call IDs

  3. Use REST to fetch the transcript one call at a time (and choose the transcript format you prefer, e.g., speaker-separated agent/caller)

 

 

 

4) Authentication: service account + API token (recommended)

Why a service account?

API tokens are scoped to the user that creates them. The standard approach is to create a dedicated “service account” user inside Patient Prism, such as:

  • api-user@yourcompany.com

  • “BI Alias” account

Recommended permissions

  • Make this user a Company Administrator (highest access level)

  • Enable access to all locations (so data isn’t accidentally incomplete)

Token usage

Your engineering team will use the API token in an auth header (commonly Basic Auth with token) to authenticate requests to:

  • GraphQL endpoint (call data / metrics)

  • REST endpoint (transcripts)

 

 

 

5) Typical integration architecture (what most teams do)

A. API-driven ingestion (common for warehouses)

Flow

  1. Scheduler (cron) runs daily/hourly

  2. Middleware/ingestion service calls GraphQL to get call list & metadata

  3. Middleware then calls REST per call to fetch transcripts (if needed)

  4. Middleware transforms/normalizes JSON and loads into your warehouse (BigQuery/Snowflake/Redshift/etc.)

Key component: the “ingestion layer” (middleware)
This is where you:

  • Pull

  • Flatten/normalize

  • Validate

  • Handle retries / backoff

  • Load into your destination

 

B. Scheduled export ingestion (common for simpler pipelines)

Flow

  1. Patient Prism exports files to your bucket on a schedule

  2. Bucket event (or scheduled job) triggers ingestion

  3. Your pipeline loads files into the warehouse and transforms downstream

 

 

 

6) JSON payloads and flattening (what to expect)

API payloads are JSON (semi-structured). Most customers either:

  • Land raw JSON first, then flatten in transformations, or

  • Flatten immediately when it lands (can be heavier upfront)

A pragmatic approach is:

  • Stage raw JSON → then transform into analytics-friendly tables (recommended for maintainability)

 

 

 

7) Operational best practices (don’t skip these)

1) Allow a buffer for call analysis to finish

Patient Prism runs many inferences after each interaction. While results are often ready quickly, best practice is to avoid ingesting “fresh” calls too soon.

Recommendation: pull data with a 24-hour buffer (e.g., today’s job ingests through yesterday).
Reason: call attributes can change (e.g., “booked” status flips after follow-up calls).

2) Pagination / batching

When pulling a list of calls, expect a paginated/scroll pattern. Your integration should:

  • Page through results reliably

  • Deduplicate call IDs

  • Resume safely after failures

3) Rate limiting

Rate limits exist but are generally liberal. Still, implement:

  • Retry with exponential backoff

  • Concurrency limits (especially for transcript-per-call fetching)

4) Monitoring and alerts

Set up monitoring for:

  • Authentication failures

  • Export failures (for scheduled exports)

  • Drops in expected volume (e.g., “no calls for 2 days”)

  • Pipeline load failures

Also, add your team to Prism technical notifications so the right people get alerted about significant issues.

 

 

 

8) What you need to get started

For Scheduled Exports

  • Cloud bucket created (S3 / Azure Blob / GCS)

  • Bucket credentials configured and uploaded/linked in Prism

  • Export configured:

    • file format (CSV typically easiest)

    • cadence (daily)

    • lookback window (e.g., last 30 days daily)

    • filters (all locations / all calls, etc.)

    • column behavior (fixed schema vs auto-add new columns)

  • Downstream ingestion from bucket (event-driven or scheduled)

For API

  • Create Prism service account (BI/API user)

  • Set service account to Company Admin + all-location access

  • Generate and securely store API token

  • Obtain:

    • GraphQL endpoint + sample query

    • REST transcript endpoint + supported transcript formats

    • Sample payloads / field descriptions (for mapping)

  • Implement ingestion:

    • call list fetch (GraphQL)

    • transcript fetch (REST per call if needed)

    • landing + transformation approach

    • retries/backoff + monitoring

    • 24-hour buffer strategy

 

 

9) Common “which should we choose?” guidance

Choose Scheduled Exports if:

  • You want the easiest path to “get all call data into a warehouse”

  • You already have a bucket → warehouse ingestion pattern

  • You prefer file-based workflows over API engineering

Choose API if:

  • You need transcripts reliably and programmatically

  • You want more dynamic queries or computed metrics via GraphQL

  • You want to run the integration at your own cadence and logic

Hybrid is also common: exports for bulk call data + API for transcripts.

 

Was this article helpful?