HIPAA
HIPAA

Ayra Health

Protected data

stays governed.

Ayra public proof surfaces are designed around data minimization controlled access and no raw patient data in public receipt paths.

Boundary posture · Public previews do not require PHI. Governed use requires written scope proper roles and the right agreements.

Last updated June 23 2026

Scope

This page summarizes Ayra's HIPAA-oriented posture for public previews, controlled pilots, production discussions, and governed deployments. It is not a substitute for a signed business associate agreement, customer security review, data processing agreement, order form, or legal advice.

HIPAA obligations depend on the specific relationship, data flow, deployment model, and role of each party. The final obligations for any customer relationship are defined in the signed agreements and approved implementation scope.

Role

Ayra may operate as a service provider, technology vendor, business associate, subcontractor business associate, or non-HIPAA website operator depending on the context. Public pages and public previews are generally not intended to receive protected health information.

When Ayra handles protected health information for a covered entity or business associate, Ayra expects the relationship to be governed by the appropriate written agreement, including a business associate agreement where required.

PHI boundary

Public pages, request forms, receipt previews, public transaction tracker surfaces, and developer examples are designed to avoid PHI, raw claims, live credentials, production secrets, private rule tables, and patient-identifiable records.

Evidence can be represented through commitments, references, proof IDs, batch roots, receipt references, redacted labels, and sanitized metadata. Those proof artifacts are designed to support reviewability without exposing the underlying patient or claim content in public surfaces.

Business associate agreements

Production use involving protected health information requires the appropriate contracting path before PHI is submitted. That path may include a business associate agreement, order form, security addendum, data processing terms, customer implementation plan, and approved subprocessors.

A BAA does not by itself authorize every workflow. Ayra and the customer still need to define permitted uses and disclosures, access roles, data categories, environments, retention expectations, deletion procedures, support boundaries, and incident-notification paths.

Minimum necessary

Ayra designs public and reviewer-facing proof surfaces around data minimization. The goal is to show enough structure to support review while limiting access to the underlying protected content.

• Use synthetic, de-identified, or sanitized data for public previews whenever possible.

• Use scoped identifiers and commitments instead of raw patient or claim content in public receipt paths.

• Limit reviewer access to the materials approved for that role and purpose.

• Separate proof metadata from clinical records, claims, credentials, and proprietary rule logic where feasible.

Safeguards

Ayra uses administrative, technical, and operational safeguards intended to support confidentiality, integrity, availability, and auditability. Safeguards may include role-based access, access review, logging, environment separation, encryption in transit, secure storage, vendor review, secure development practices, incident response procedures, and controlled disclosure paths.

This page intentionally avoids disclosing sensitive internal implementation details, secrets, network architecture, credentials, or security procedures that could weaken the platform.

Access and audit posture

Ayra expects governed deployments to use approved user roles, least-privilege access, authenticated sessions, audit logs, and role-specific review surfaces. Access to verifier materials, pilot dashboards, and production data should be limited to approved users with a defined purpose.

Auditability does not mean universal public access. Ayra's verification posture is designed to let authorized reviewers inspect proof context while keeping protected data, secrets, and proprietary logic out of public exposure.

Receipt boundary

Ayra proof receipts are designed so public or external receipt paths can show that a workflow event existed, was committed, or was anchored without exposing PHI, raw claims, clinical notes, full records, or private rules on the public receipt layer.

A receipt reference may support review, but it is not a complete designated record set, medical record, claim file, legal opinion, payer decision, or substitute for records maintained by the covered entity or customer.

Vendors and subprocessors

Ayra may use infrastructure, security, communications, monitoring, storage, support, and professional-service providers to operate the platform. Where a provider handles protected health information on Ayra's behalf in a HIPAA-regulated relationship, Ayra expects the appropriate contractual safeguards to be in place.

Customer-specific subprocessor lists, deployment details, and data flow diagrams may be provided during governed diligence or contracting rather than published broadly.

Incidents and breach process

Ayra maintains procedures for assessing suspected unauthorized access, use, disclosure, loss, or alteration of protected data. If an incident affects a governed customer environment, notification responsibilities, timing, content, and cooperation obligations are handled under the applicable agreement and law.

Security concerns should be reported through the request access form so they are routed to the appropriate internal review path.

Retention and deletion

Retention depends on the data type, customer instructions, legal requirements, contractual obligations, security needs, and audit posture. Some logs and proof metadata may be retained to preserve auditability, fraud prevention, security investigation, or legal defense even after other content is removed.

Deletion or erasure workflows may preserve proof structure while removing or rendering underlying protected content inaccessible, depending on the approved workflow and agreement.

Customer responsibilities

Customers, clinicians, payers, reviewers, and administrators remain responsible for configuring access, limiting submitted data to approved environments, obtaining required authorizations, maintaining their own records, training users, reviewing outputs, and complying with applicable laws and payer rules.

Do not use public previews, public forms, or public receipt surfaces as repositories for protected health information.

Compliance contact path

Use the request access form for BAA review, compliance questions, security diligence, HIPAA-related requests, or protected-data scoping. Ayra does not use a public email address as the primary intake path for HIPAA or compliance matters.

Ayra Health

Healthcare verification infrastructure. Starting in behavioral health.

© 2026 Ayra Health · Houston, Texas.