Zanus AI and HIPAA: Review the BAA and Actual Data Flow

Identify the relevant services and agreements

HHS cloud-computing guidance explains that a cloud provider handling ePHI on behalf of a covered entity or business associate can be a business associate, and addresses business associate agreements and safeguards. Have the reviewer determine how that guidance applies to the actual service chain.

Ask Zanus AI for deployment-specific documentation and the proposed BAA where required. Do not infer that a particular agreement, service or configuration is available without written confirmation.

Trace information beyond the phone call

A contract covering one service does not automatically answer questions about every connected destination. Keep the full information flow in the review.

Test controls with synthetic records

Have an internal caller request an administrative appointment change using test data. Inspect every resulting copy and verify that staff permissions match the proposed role. Try an unauthorised retrieval and record the actual response.

Ask the vendor to demonstrate correction, export, retention and deletion processes relevant to the deployment. Document exceptions for the qualified reviewer. Passing these operational tests does not by itself establish that the organisation has met all HIPAA obligations.

Keep the pilot within its reviewed scope

Use real patient information only after the organisation’s required review, agreements and controls are in place. Keep clinical questions and decisions with the practice’s approved process. Name the people responsible for exceptions and incident escalation.

Retain the assessed configuration and evidence, and reassess when providers, processing purposes or destinations change. A useful approval record states what was reviewed and what remains excluded; it should not turn a broad vendor claim into a permanent assurance about every future workflow.

Questions and answers

Is signing a BAA the entire HIPAA assessment?

No. Establish the applicable agreements and evaluate the actual data flow, safeguards, permissions and organisational responsibilities for the proposed use.

Mapping the Call Data Journey Before Signing Anything

When a healthcare organisation begins evaluating an AI phone system, the contractual review and the technical data-flow review need to happen in parallel rather than in sequence. A business associate agreement addresses legal accountability, but it does not by itself reveal where audio, transcripts and appointment data travel after a call ends. The following material helps an internal evaluation team build a working map of that journey before the qualified reviewer is asked to form a judgement.

Start by distinguishing three separate things that are sometimes conflated in early vendor conversations: the identity of the caller, the content of a specific request and the responsibility for acting on that request. A caller identifying themselves as a patient is not the same as a verified patient identity. A request to reschedule an appointment is not the same as a clinical instruction. And a system that logs a request is not the same as a staff member who owns the outcome. Keeping these distinctions clear during evaluation prevents the organisation from inadvertently designing a workflow where accountability is diffuse.

Building a Layered Data-Flow Diagram

Before any technical testing begins, ask the evaluation team to produce a written data-flow diagram that covers every layer where patient-adjacent information could appear. This is distinct from a network diagram or a system architecture diagram, both of which tend to describe infrastructure rather than information movement.

A useful layered data-flow diagram for a phone-based AI system would typically work through the following questions, each answered in writing before the next is addressed:

• Where does the audio signal originate, and which party controls the telephony layer?
• At what point is speech converted to text, and which organisation performs that conversion?
• Where is the resulting transcript held immediately after the call, and for how long?
• Which systems receive structured data derived from the transcript, such as appointment type, date or patient-supplied identifiers?
• Which staff roles can retrieve raw transcripts, summaries or structured records, and through which interface?
• Are any outputs forwarded to third parties for quality review, model training or operational support, and under what terms?
• What happens to stored data when a subscription lapses or a configuration changes?

Each answer should be supported by written documentation from the relevant party, not by a sales demonstration alone. Where a vendor cannot yet supply written documentation for a specific layer, that gap itself is material information for the qualified reviewer.

A Fictional Enquiry Traced From Receipt to Completion

The following is an illustrative scenario, not a claim about how any specific vendor system operates. It is offered as a template for the kind of step-by-step trace an evaluation team should perform with real vendor documentation in hand.

Imagine a caller contacts a dental practice's AI phone system and says they need to move their upcoming cleaning appointment because of a work conflict. Consider what happens at each stage:

Receipt

The telephony provider receives an inbound call and routes it to the AI system. At this point, the caller has supplied their phone number and possibly their name. The evaluation question is whether the phone number alone constitutes information that, in combination with other data the system already holds, could identify a patient. The organisation should ask the vendor to specify exactly which data fields are queried at this stage and which systems are touched.

Identification

The AI system may attempt to match the caller against an existing patient record using a phone number, date of birth or another supplied identifier. The evaluation question here is distinct from the receipt stage: which system performs the match, where is the match result stored, and does a failed match trigger any logging that itself contains patient-adjacent data? The organisation should also consider what happens if a caller supplies someone else's identifying information, whether deliberately or in error.

Request Processing

The caller states their scheduling preference. The AI system interprets that preference and, depending on configuration, may propose alternative appointment slots, confirm a change or place the request in a queue for staff review. The evaluation question is whether the system's interpretation is treated as a final action or as a draft requiring human confirmation. For requests that touch clinical scheduling, the organisation should be explicit about which category applies, and that decision should be documented before deployment, not resolved case by case during operation.

Downstream Writes

If the system writes to a practice management or scheduling platform, the evaluation team should document exactly which fields are written, which credentials are used to authenticate the write, and whether the write is auditable through the destination system's own logs. A write performed under a shared service account is harder to audit than one performed under a role-specific credential. The choice of credential architecture is a decision the organisation can make independently of the vendor.

Notification

If the system sends a confirmation message to the caller, the evaluation question is whether that message contains any information that, in combination with the channel used, could expose patient data. A text message confirming an appointment at a named specialist practice may carry more sensitivity than a generic confirmation. The organisation should define a notification template policy before deployment.

Retention and Closure

After the call ends, the evaluation team should document the expected retention period for the audio, the transcript and any derived records across every system that holds a copy. If the vendor, the telephony provider and the destination system each apply different retention periods, the longest period governs the practical exposure. The organisation should consider whether its own retention policy aligns with the longest of those periods and what deletion rights exist across each layer.

Role Design and Permission Scoping

One of the most reviewable aspects of any AI phone deployment is the permission structure assigned to staff who interact with the system's outputs. Before deployment, the organisation should document a permission matrix that specifies, for each staff role, which outputs they can read, which they can edit and which they can delete. This matrix becomes the basis for the access-control testing described in the original evaluation framework.

When designing this matrix, it helps to consider exception cases explicitly rather than leaving them to ad hoc judgment. Useful exception cases to consider include:

• A front-desk staff member who needs to correct a transcript that contains an error introduced by the AI system
• A practice manager who needs to retrieve a call record in response to a patient complaint
• An IT administrator who needs to export records as part of a system migration
• A temporary or agency staff member whose access should be limited relative to a permanent employee
• A staff member whose employment has ended and whose credentials need to be revoked promptly

Each of these cases requires a defined process. The process does not need to be elaborate, but it does need to exist in writing before deployment so that staff know what steps to follow without having to improvise under time pressure.

Evaluating the BAA as a Document Rather Than a Symbol

A business associate agreement is a legal instrument, and its review belongs with a qualified professional. However, an internal evaluation team can usefully prepare for that review by identifying specific questions the agreement should answer for the proposed deployment. The following questions are framed as evaluation criteria rather than legal advice:

• Does the agreement identify the specific services and data types covered, or does it use broad language that may not clearly include the telephony layer, the transcription service or downstream integrations?
• Does the agreement address subcontractors, and if so, does it require that subcontractors operate under equivalent terms?
• Does the agreement specify breach notification timelines and the process by which the organisation would be informed of an incident?
• Does the agreement describe what happens to data held by the vendor if the agreement is terminated?
• Does the agreement constrain the vendor's use of data for purposes beyond the immediate service, such as product development or model improvement?

Where the agreement is silent on any of these points, the organisation can seek a written addendum or clarification before signing. Silence on a material point is not the same as a prohibition or a permission; it is a gap that requires resolution.

Designing a Synthetic-Record Acceptance Exercise

A practical acceptance exercise uses invented records that have no connection to real patients. The purpose is to observe system behaviour under conditions that resemble actual use without exposing real patient information during a period when controls have not yet been verified.

A well-designed synthetic-record exercise for an AI phone system would include at least the following observable steps:

Normal-path test

A staff member acting as a caller contacts the system using a synthetic patient record and makes a routine scheduling request. The evaluator documents every system that receives any output from that call, verifies that the synthetic record appears where expected and nowhere else, and confirms that the requesting staff member's role permissions behave as the permission matrix specifies.

Mismatch test

A staff member provides identifying information that partially matches a synthetic record but contains a deliberate error, such as a transposed digit in a date of birth. The evaluator documents how the system responds, whether it fails safely, prompts for correction or proceeds with a partial match, and whether any log entry created during the failed match contains information that should itself be protected.

Unauthorised-retrieval test

A staff member assigned a restricted role attempts to access a transcript or record that their role should not permit. The evaluator documents the actual system response and compares it with the permission matrix. If the system does not prevent access, that gap should be documented for the qualified reviewer before any patient data is introduced.

Deletion test

After the normal-path test is complete, the evaluator requests deletion of the synthetic record across all systems identified in the data-flow diagram and then attempts to retrieve it through each available interface. The purpose is to verify that deletion is effective across the full data chain, not only in the primary interface.

The results of this exercise should be recorded in a format that can be retained as part of the organisation's configuration evidence. If any test produces an unexpected result, that result should be resolved before the pilot scope is extended to real patient information.

Handover Arrangements and Escalation Ownership

A phone-based AI system operates outside normal staffed hours in many deployments. That means the organisation needs to define in advance who owns an exception that occurs when no one is immediately available to respond. This is a process design question, not a technical question, and it requires the organisation to make explicit decisions rather than relying on the system to handle edge cases autonomously.

Useful handover questions to answer before deployment include:

• If a caller reports a clinical concern during what the system treats as a scheduling call, what is the documented escalation path and who is notified?
• If the system produces an incorrect appointment write that is not discovered until the following business day, who has authority to correct the record and what correction process applies?
• If the organisation's qualified reviewer identifies a configuration change that needs to be made urgently, who is authorised to pause the system's operation while that change is implemented?
• If a staff member suspects that a caller has supplied false identifying information to access another patient's record, what is the incident-reporting process?

Each of these questions has an answer that is specific to the organisation's structure and staffing. That answer should be written down and shared with the staff members who would be involved before the system handles any real patient interaction.

What the Approval Record Should Actually Contain

When the evaluation process is complete and the qualified reviewer has formed a judgement, the approval record should be precise enough to be useful to a future reviewer who was not present during the evaluation. A vague approval record that simply states the system was reviewed and approved creates false confidence because it cannot distinguish between a narrow approval of a specific workflow and a broad approval of all possible uses.

A useful approval record for an AI phone system deployment in a healthcare setting would specify, at minimum, the services and configurations that were reviewed, the data-flow scope that was assessed, the synthetic-record tests that were conducted and their results, the permission matrix that was in place at the time of approval, the staff roles named as responsible for exceptions and escalation, and the conditions under which a reassessment would be required. Changes to any of those elements should trigger a new review rather than being absorbed silently into an existing approval.

Keeping the approval record at this level of specificity also makes it easier to identify which parts of the deployment remain outside the reviewed scope, which is as important as knowing what was approved. A deployment that begins with a narrow, well-documented scope and expands deliberately through successive reviews is considerably easier to manage than one where scope boundaries were never drawn clearly in the first place.

Sources and next steps

This independent Sysevo guide proposes evaluation steps and reports no hands-on vendor test or compliance certification. Check the linked primary sources and Zanus AI’s current Front Office overview, then confirm the scope of your proposed deployment in writing.

Read Zanus AI dental receptionist booking for related context. To compare providers using the same requirements, explore Sysevo security and data controls or book a Sysevo demo. Sysevo publishes this guide and offers its own business software.

Related workflow guides

• Zanus AI Patient Scheduling: Keep Changes in the Right Queue
• Zanus AI Dental Recall Calls: Start With a Staff-Approved List

For current Sysevo subscriptions and usage options, compare plans and pricing.