What's the difference between HIPAA's Required and Addressable implementation specifications?

Required specifications must be implemented. Addressable specifications must be implemented unless the covered entity can document that the specification is not reasonable and appropriate, and implement an equivalent alternative measure. In practice, most Addressable specifications, including encryption at rest, automatic logoff, and audit controls for transmission, are implemented by any reasonable security program. The Addressable designation allows flexibility in how they're implemented, not whether they're implemented. Healthcare developers should treat both Required and Addressable specifications as implementation targets.

How do you handle HIPAA compliance when using an LLM API to summarize patient call transcripts?

If you're sending transcripts containing PHI to an LLM API for summarization, that LLM provider is processing PHI and requires a BAA. Major LLM providers have different policies: some (like Azure OpenAI with appropriate configuration) offer HIPAA BAAs. Others do not offer BAAs or require enterprise contracts for BAA eligibility. Evaluate whether the BAA terms are consistent with your compliance requirements before using any LLM API with patient transcripts. Alternatively, de-identify transcripts before sending to LLM APIs, removing identifiers as described above means the data sent to the LLM is no longer PHI and doesn't require a BAA.

What audit log entries are required for HIPAA compliance around meeting recordings?

The HIPAA Security Rule requires that audit controls record activity in systems containing PHI, but doesn't specify exact log fields. Best practice based on HIPAA audit guidance is: action type (create/read/update/delete), timestamp, user ID, session ID, record identifier (recording ID, transcript ID), and outcome (success/failure). For recordings specifically, also log: who initiated the recording, who has been granted access, and any downloads or exports of the recording file. These logs should be retained for at least the same period as the recordings themselves and stored in a tamper-evident format, use an append-only database table or a dedicated logging service rather than a mutable lo

Can meeting recordings be used for medical AI training while maintaining HIPAA compliance?

Yes, through two paths. First, with patient authorization: explicit written authorization from patients for secondary use of their health information. Second, through de-identification: recordings and transcripts that have been reliably de-identified under HIPAA's Safe Harbor or Expert Determination standards are no longer PHI and can be used without restriction. The de-identification approach is more scalable for training data generation but requires rigorous validation of the de-identification pipeline. Institutional Review Board review may also be required depending on the nature of the research use, which is a separate consideration from HIPAA compliance.If you're building a hipaa meetin

HIPAA-Compliant Meeting Bot API for Healthcare

Q: Does a telehealth platform need a BAA with their meeting recording vendor?

Yes. If the meeting recording vendor processes, stores, or transmits patient communications, even temporarily, they are a business associate under HIPAA and a BAA is required. This applies even if the recordings only pass through the vendor's servers transiently before being delivered to your storage. "Transient" storage is still PHI processing. Before integrating any meeting recording API into a healthcare product, confirm that the vendor offers a HIPAA BAA and execute it before processing any patient recordings.

To use a meeting bot API in a healthcare application, you must verify four technical controls. First, where recordings are stored and how access is controlled. Second, how long media is retained and if you can configure it per call. Third, whether the platform provides an auditable signal upon data deletion. Fourth, how many third-party services process the audio between capture and transcript. These are the controls an assessor will ask about during a HIPAA audit.

Building applications for healthcare requires more than just a reliable API. It requires an infrastructure partner that provides the necessary controls for compliance. MeetStream is an agent-first voice infrastructure platform for meetings. Our API lets you deploy bots that join calls, listen, and act, while giving you the tools to manage data retention and receive auditable webhooks for key events like data deletion. MeetStream is HIPAA compliant and signs a Business Associate Agreement with healthcare customers before any PHI is processed.

The need for these controls is critical. A telehealth platform might add video consultation recording for quality improvement, only to face a HIPAA audit that finds inadequate encryption at rest, overly permissive access controls, and a missing Business Associate Agreement (BAA) with their recording vendor. This scenario is common because while recording a call seems simple at the API level, the compliance requirements create specific technical obligations.

This article translates HIPAA's rules into technical decisions for developers. We cover when a recording becomes Protected Health Information, the specific Technical Safeguards you must implement, BAA requirements, and how to design your recording infrastructure for compliance from the start. This is technical context, not legal advice; always consult with a qualified Privacy Officer and legal counsel for your specific compliance program.

When Does a Meeting Recording Become PHI?

A meeting recording becomes Protected Health Information (PHI) when it contains individually identifiable health information. Under HIPAA, this includes any data about a person's health condition, care, or payment for care, combined with an identifier. Identifiers are broad and include names, specific dates, phone numbers, email addresses, and more. A typical patient consultation recording contains multiple identifiers, like the patient's name and voice, making the entire recording PHI.

The definition extends to less obvious cases. A staff meeting where patient cases are discussed by name creates PHI. A training session using real patient examples, even without names, may be PHI if the details could identify the individual. The most direct approach is to assume any recording involving an identifiable patient discussing health is PHI and apply the full set of technical safeguards. This avoids the risk of misclassifying data.

HIPAA Technical Safeguards for Meeting Recordings

The HIPAA Security Rule specifies Technical Safeguards that covered entities and their business associates must implement for electronic PHI. For meeting recordings, these rules translate to four key areas of implementation.

Access Control: Every user accessing PHI recordings must have a unique ID. Access must be limited to the minimum necessary for their role. Your system needs procedures for emergency access and should enforce automatic logoff from interfaces displaying PHI. In practice, this means row-level access control in your database, scoped to a patient's care team. All access must be authenticated, and every retrieval should be logged with a user ID, timestamp, and access type.

Audit Controls: You must have mechanisms to record and examine all activity in systems that contain PHI. This is the audit log requirement. Every creation, read, update, and deletion of a recording or transcript must be logged in a tamper-evident store. The log must capture who took the action, what they did, on which record, and when.

Integrity: Electronic PHI must be protected from improper alteration or destruction. For recordings, this means verifiable integrity. You can achieve this by computing a cryptographic hash of the recording file when you store it. Store this hash separately and verify it before providing the recording for clinical or legal use. A mismatch proves the file was altered.

Transmission Security: You must implement technical security measures to protect PHI as it travels over a network. This requires TLS 1.2 or higher for all API communication, including media downloads and transcript display. Your code should always verify certificate validity and reject self-signed certificates in production environments that handle PHI.

Encryption at Rest and Key Management

While encryption at rest is an "Addressable" specification under HIPAA, not "Required," it is a practical necessity. An organization would find it difficult to justify storing unencrypted patient recordings to an auditor. For recordings in cloud object storage, use server-side encryption with customer-managed keys (SSE-KMS in AWS, or equivalents in GCP and Azure). This gives you auditable control over key access and rotation.

For transcript data in a database, use column-level or full database encryption. The management of encryption keys is often the most vulnerable part of the system. Use a dedicated key management service like AWS KMS, enforce key rotation policies, and restrict key access to specific service accounts and administrators. All key usage must be logged.

Why a Business Associate Agreement is Non-Negotiable

A Business Associate is any entity that performs activities on behalf of a covered entity involving PHI. A meeting recording API vendor that stores or transmits patient recordings is a business associate. A Business Associate Agreement (BAA) is a required contract that defines how the vendor will protect PHI. You cannot legally use a third-party service that handles patient PHI without a signed BAA.

This applies even if the vendor's storage is transient. If a recording passes through a vendor's servers on its way to you, a BAA is required. This extends to your cloud storage provider, database host, and any LLM API you use for transcript processing. When evaluating a meeting bot API, ask directly if they offer a BAA and review its terms before you start building.

Implementing HIPAA Data Retention Policies

HIPAA requires that documentation related to compliance be retained for six years. However, state laws often mandate longer retention for medical records, sometimes ten years or more. Your application must enforce the longer of the applicable federal and state requirements.

You can implement this with an API that supports configurable data retention. For example, when creating a bot with MeetStream, you can set a specific retention period in the `recording_config` object of your API call. When your application receives the webhook indicating the recording is ready, you can store its ID along with a calculated deletion date. A scheduled job can then run daily to permanently delete recordings that have passed their retention date.

A flowchart showing the four stages of a HIPAA-compliant meeting recording: bot joins, media is captured, data is stored securely with encryption, and data is deleted based on retention policy. — *A compliant recording pipeline enforces access control, encryption, and retention policies at each stage.*

Document your retention policy, apply it consistently, and automate its enforcement. This reduces the risk of manual error and provides clear evidence of compliance to auditors.

How MeetStream Fits Your Healthcare Application

Building a compliant healthcare application requires a clear division of responsibility. MeetStream provides the agent-first voice infrastructure, and your application implements the compliance logic.

MeetStream's responsibility is to provide the tools for compliant data capture. This includes reliable bot joining for Zoom, Google Meet, and Microsoft Teams, and an API that allows you to configure data retention on a per-call basis. We provide auditable webhook events, such as `data_deletion`, to confirm that your retention policies have been executed. For audio capture, we provide fully isolated per-participant audio streams on Zoom and speaker-attributed streams on Google Meet and Teams. MeetStream signs a BAA for its part of the chain; your application remains responsible for access control and audit trails for its own users.

A diagram showing three stacked layers of responsibility for HIPAA compliance. The bottom layer is Cloud Infrastructure, the middle is the MeetStream API, and the top layer, highlighted, is Your Application, which handles access control and policy. — *HIPAA compliance is a shared responsibility, with your application logic being the top and most critical layer.*

Your application's responsibility is to use these tools to build a compliant system. This includes executing a BAA with MeetStream and all other vendors, implementing encryption for data you store, building reliable access control and audit logging, enforcing retention policies, and obtaining patient consent for recording. The API is a component; HIPAA compliance is a property of the entire system you design and operate.

Conclusion

Building with a meeting bot API for healthcare requires a focus on specific technical controls from day one. By verifying a vendor's support for configurable data retention, auditable deletion, and secure transmission, and by building reliable access control and encryption into your own application, you can create a system that is both functional and compliant. The key is to see the API as a set of infrastructure primitives that you use to enforce your organization's documented privacy and security policies.

See the full API reference at docs.meetstream.ai.

Related guides

Frequently Asked Questions

Does a telehealth platform need a BAA with their meeting recording vendor?

Yes. If a meeting recording vendor processes, stores, or transmits patient communications, they are a business associate under HIPAA, and a BAA is required. This applies even if the data is only stored transiently. Confirm a vendor offers a BAA before processing any patient data.

What is the difference between Required and Addressable HIPAA specifications?

Required specifications must be implemented. Addressable specifications must also be implemented, unless you can document that the specification is not reasonable for your environment and that an equivalent alternative measure is in place. In practice, developers should treat both as implementation targets, as most addressable controls like encryption are considered standard practice.

How do you handle HIPAA compliance when using an LLM to summarize transcripts?

If you send PHI to an LLM API, the provider is a business associate and you need a BAA. Some providers offer BAAs, often on enterprise plans. An alternative is to de-identify transcripts by removing all 18 HIPAA identifiers before sending the data to the LLM, in which case a BAA is not required for that interaction.

What audit log entries are required for HIPAA compliance?

HIPAA requires that you can record and examine activity, but does not specify exact fields. Best practice is to log the action type (create, read, update, delete), timestamp, user ID, the specific record ID, and the outcome. For recordings, you should also log who initiated the recording and any downloads or exports.

Can meeting recordings be used for medical AI training?

Yes, in two ways. You can obtain explicit written authorization from patients for this secondary use of their data. The more scalable approach is to de-identify the recordings and transcripts according to HIPAA's Safe Harbor or Expert Determination methods, after which the data is no longer PHI and can be used for training.