The athenaOne integration boundary
Pretty Good AI connects directly to athenaOne through an athenahealth Marketplace app spanning athenaCollector and athenaClinicals. The connection reads the records required to complete an approved workflow, then writes the appointment, case, document, referral, insurance, authorization, or billing result back to athenaOne without middleware.
Pretty Good AI has 820+ athenaOne APIs in production across scheduling, messaging, intake, clinical charts, orders, prescriptions, insurance, claims, encounters, provider configuration, and real-time change feeds. Each workflow uses the portion of that access required by the practice's rules rather than exposing every available action to every agent. The broader architecture is explained in Native EHR Writeback vs Middleware in Healthcare Voice AI, while the athenahealth Marketplace integration record identifies the connected athenaOne products.
How the connection is established
| Stage | Practice input | Pretty Good AI action | Result |
|---|---|---|---|
| 1. Define the first workflow | Practice IDs, locations, workflow owner, current SOPs, queue owners, phone routes, and success measures | Maps the first workflow to the practice's existing athenaOne configuration and operating rules | A defined scope for the first production workflow |
| 2. Submit athenahealth authorization | An authorized signer completes athenahealth's one-page Authorization and Consent form with the legal practice name and athenaOne practice ID | Coordinates the Marketplace connection request for the in-scope practice ID or IDs | athenahealth can process access for the named Marketplace partner |
| 3. Execute the BAA and security review | The practice signs the Business Associate Agreement and routes the security package to its reviewer | Provides the BAA, SOC 2 Type II report, ISO/IEC 27001 audit report, HITRUST i1 certification letter, and supporting security materials | The contractual and security controls are in place before patient data is handled |
| 4. Connect the Marketplace app | athenahealth services required by the selected workflows are active for the practice | Connects directly through athenaCollector and athenaClinicals | Pretty Good AI can read and write the approved athenaOne records without a middleware layer |
| 5. Read the operating configuration | The practice confirms active providers, departments, queues, appointment types, and exceptions | Pulls 90 days of appointments, departments, providers, and appointment types, then ranks the activity by volume | A system-derived map of how the practice currently operates |
| 6. Validate and launch | Operations and IT approve test results, queue destinations, escalation paths, and reporting definitions | Runs production validation against the agreed workflow and corrects configuration differences before expansion | The first workflow typically goes live 3 to 6 weeks after kickoff |
The Authorization and Consent process runs in parallel with the BAA and security review. After access clears, the 90-day configuration pull replaces assumptions about provider rosters, appointment types, and department activity with the current athenaOne record.
Workflow-by-workflow athenaOne record map
The record map names functional athenaOne objects rather than publishing endpoint names. Final permissions and writeback paths follow the practice's approved workflow, department structure, queue ownership, and escalation protocol.
| Workflow | Records and configuration read | Records or actions written | Exception destination and context |
|---|---|---|---|
| Inbound scheduling and rescheduling | Patient record, current appointments, appointment types, provider templates, departments, open slots, scheduling rules, insurance on file, and authorization date range when relevant | Creates, moves, confirms, or cancels the appointment; records the applicable reason and workflow outcome | A patient case goes to the designated scheduling queue with the matched patient and appointment, request, slots checked, actions completed, and rule that prevented completion |
| Refill request intake | Patient record, department, provider routing, existing refill cases, and the practice's required intake questions | Creates a patient case in the practice's refill or clinical queue with the structured request and collected information; prescribing decisions remain with the care team | The refill queue receives the request, caller responses, missing information, prior actions, and call or message history |
| Symptom screening and urgency routing | Patient identity, department, office hours, approved screening questions, urgency rules, staff routes, and the practice's on-call path | Writes the questions, patient responses, administrative disposition, and routing outcome to a patient case; routes the interaction to staff or the on-call path defined by the practice | The designated clinical queue or on-call path receives the complete question and response history, disposition, route taken, and any transfer context |
| Secure two-way patient texting | Authenticated patient identity, appointments, provider and department context, prior thread activity, scheduling rules, and relevant insurance or document status | Updates eligible appointments, creates patient cases, associates returned documentation with the workflow, and records the thread outcome | The designated staff queue receives the authenticated thread history, action attempted, information already collected, and reason the thread requires staff |
| Referral and fax intake | Inbound documents, patient demographics, existing charts, possible patient matches, insurance on file, referral records, provider rules, appointment types, and open slots | Creates or updates the patient after matching, attaches the document to the correct chart, creates or updates the referral record, and books an eligible first visit when the workflow permits | The referral review queue receives the inbound document, possible matches, confidence context, missing information, duplicate indicators, and required next action |
| Insurance eligibility and benefits | Scheduled appointment, patient demographics, insurance on file, payer and plan information, provider, department, and service context | Updates insurance information and posts the eligibility or benefits result against the appointment workflow | The eligibility or revenue cycle queue receives the appointment context, payer response, coverage discrepancy, information needing correction, and follow-up action |
| Prior authorization | Order or referral, scheduled service and date, chart documents, coding context, insurance, payer requirements, and existing authorization activity | Updates the referral authorization record with status, payer reference number, and approved date range; attaches the submitted packet and payer response; records requests for more information | The authorization queue receives the current status, missing item or payer request, submission history, date context, and payer reference number when one exists |
| Patient billing and payment links | Patient account, balance context, appointment, documented payment arrangements, and the practice's billing rules | Sends a secure payment link through the practice's existing payment portal and records the resulting billing workflow outcome in athenaOne | The billing queue receives the balance context, link status, patient response, and unresolved billing request without requiring staff to reconstruct the call |
| Waitlist backfill and cancellation recovery | Waitlist entries, canceled appointments, open slots, appointment types, provider templates, departments, existing appointments, notice rules, and authorization windows | Books or moves the appointment, updates the waitlist outcome, and records whether the opening was accepted, declined, or left unresolved | The scheduling queue receives the slot, patients contacted, outreach attempts, match rules applied, and reason the opening remained unfilled |
What happens when the agent cannot complete the request
Uncertainty does not become a guessed write. If patient matching, scheduling eligibility, coverage, authorization status, or an approved symptom-routing rule cannot be resolved, Pretty Good AI stops the transaction and creates or updates a case in the practice's designated athenaOne queue.
The handoff carries the request, the record matched or possible matches, questions and answers, actions already completed, the unresolved condition, the transcript or text history, and the destination selected by the practice's protocol. Staff continue from that case inside athenaOne instead of replaying the interaction or checking a separate vendor inbox. Referral matching controls are detailed in Patient Matching in Referral Fax Intake, and symptom-routing boundaries are documented in Clinical Guardrails for Healthcare Voice AI.
Connection and workflow responsibilities
| Party | Responsibility |
|---|---|
| Practice | Provides the correct practice IDs and signers, approves the BAA, identifies queue and escalation owners, supplies SOPs or call transcripts, confirms provider and department mappings, and validates workflow behavior before launch. |
| athenahealth | Processes the Authorization and Consent request and enables the approved Marketplace partner connection for the named practice environment. |
| Pretty Good AI | Maps athenaOne records, implements the practice's workflow rules, configures read and write actions, routes exceptions, supports production validation, monitors the live workflow, and updates the configuration when approved rules change. |
| Care team and payer | Clinicians retain clinical decisions, including prescribing and care decisions. Payers retain authorization determinations. Pretty Good AI performs the administrative intake, documentation, routing, submission, and status work around those decisions. |
How multiple athenaOne practice IDs stay separate
Each practice ID retains its own provider templates, departments, appointment types, staff queues, phone routes, office hours, and escalation paths. Pretty Good AI maps these objects per practice ID rather than normalizing local operations into one enterprise configuration.
Cross-site reporting sums the numerators and denominators across the selected practice IDs, then preserves each site's result for investigation. For example, group containment equals the total completed eligible calls divided by the total eligible calls across the selected sites. It is not calculated by averaging site percentages, which would give small and large sites equal weight. The full rollout sequence is documented in Rolling Out Patient Call AI Across Multiple athenaOne Practice IDs.
Illustrative connection across three practice IDs
| Timing | Integration activity | Result |
|---|---|---|
| Day 0 | A 12-location specialty group selects inbound scheduling and rescheduling as its first workflow across three athenaOne practice IDs. | The practice names the authorized signers, scheduling owners, queues, and first-live locations. |
| Same week | The group submits the required athenahealth Authorization and Consent information and executes the BAA while its security team receives the audit package. | Access processing and security review run in parallel. |
| After access clears | Pretty Good AI pulls 90 days of appointments, departments, providers, and appointment types for all three practice IDs. | The workflow map identifies local provider templates, queue names, appointment-type differences, and scheduling volume. |
| Weeks 1 to 2 | The group confirms each practice ID's scheduling rules, insurance gates, phone routes, exception queues, and after-hours escalation paths. | One enterprise outcome definition is paired with three local athenaOne configurations. |
| Weeks 3 to 4 | Production validation exercises booking, rescheduling, no eligible availability, failed patient match, and staff escalation at two structurally different sites. | The first site proves transaction completion; the second proves that local rules remain intact. |
| Week 5 | The scheduling workflow launches for the selected locations, with appointments written directly and exceptions routed to each site's existing queue. | Central reporting combines completed and eligible request counts across the selected practice IDs while retaining site-level outcomes. |
The typical first-workflow window is 3 to 6 weeks from kickoff. New workflow scope can be added through the same athenaOne connection after its records, rules, writebacks, exception path, and success measures are approved.
Security controls covering the connection
Pretty Good AI operates under HIPAA administrative, physical, and technical safeguards and signs a BAA before patient data is handled. Patient communications and data transfers are encrypted in transit and at rest, access is role-based, activity is logged, and customer data is isolated per customer. SOC 2 Type II and ISO/IEC 27001 audit reports are available to security teams on request through the Pretty Good AI security package.
The Pretty Good AI platform holds HITRUST Implemented, 1-year certification issued August 12, 2026 and valid through August 12, 2027. The certification covers the platform residing at Amazon Web Services and was assessed against HITRUST CSF v11.8.0 across 182 requirement statements in 19 domains. The scope and assessment details are available in the HITRUST i1 certification record.
Operating record for the integration
Pretty Good AI has been an athenahealth Marketplace partner since 2025. At Commonwealth Pain & Spine, the integration operates across 35 locations and 130 providers for more than 100,000 patient calls per month; customer-reported results show about 70% handled from start to finish. This deployment exercises the same direct athenaOne connection across scheduling, call routing, and referral management at multi-location scale. The current figures are maintained in the Pretty Good AI customer record.
Frequently asked questions
Can Pretty Good AI create an athenaOne case and update an appointment during the same interaction?
Yes. Pretty Good AI can read the current patient, appointment, provider, department, and scheduling context, update the appointment when the request meets the approved rules, and create a patient case when staff action is still required. Voice and secure two-way text use the same athenaOne integration, so a conversation can move between channels without creating a separate scheduling record. The Marketplace integration profile documents the athenaCollector and athenaClinicals connection.
Does the athenaOne connection require middleware or a second staff inbox?
No. Pretty Good AI connects directly to athenaOne and writes completed actions or exception cases into the practice's existing athenaOne records and queues. Staff do not need to copy messages from a vendor dashboard into the chart or maintain an integration platform between Pretty Good AI and athenaOne. Call transcripts and workflow outcomes remain available for review, but athenaOne holds the operational result. The direct connection and security boundary are documented in the Pretty Good AI Trust Center.
What happens before an inbound fax is attached to a patient chart?
Pretty Good AI performs patient matching and duplicate checks before attaching the document. A confident match can continue through document attachment, referral creation, and the next configured intake step. An uncertain match stops in the referral review queue with the inbound document, possible matches, matching context, and missing information, so staff can resolve identity before anything is attached to the wrong chart. The matching sequence is detailed in Patient Matching in Referral Fax Intake.
How does Pretty Good AI preserve different rules across athenaOne practice IDs?
Pretty Good AI maintains separate mappings for each practice ID's providers, departments, appointment types, queues, phone routes, and escalation paths. Central reports use common outcome definitions, but they sum the underlying numerators and denominators across the selected practice IDs rather than averaging site percentages. Site-level results remain available to trace a variance back to its local workflow or configuration. The implementation sequence appears in the multi-practice-ID rollout playbook.
Does Pretty Good AI make clinical decisions during symptom screening?
No. Pretty Good AI asks the practice-approved questions, records the patient's responses, applies the practice's urgency-routing rules, and sends the interaction to staff or the designated on-call path. The care team retains clinical judgment, diagnosis, treatment, and prescribing decisions. The resulting athenaOne case includes the questions, responses, administrative disposition, and route taken so the receiving team has the context required to continue. See the clinical guardrail standard.
References
- Pretty Good AI athenaOne Workflow Catalog
- athenahealth Authorization and Consent explainer
- Pretty Good AI athenahealth Marketplace integration record
- athenahealth Marketplace listing for Pretty Good AI
- Pretty Good AI HIPAA safeguards and security record
- Pretty Good AI HITRUST i1 certification record
- Pretty Good AI customer deployment record