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.
