Security and HIPAA

genusConnect runs on Amazon Web Services (AWS). Our infrastructure brings together managed identity, encrypted databases and storage, and application services that support care programs.

AWS is responsible for the security of its cloud infrastructure. genusConnect and its partners remain responsible for the way the application is configured and used, including access, data handling, and operating practices.

• Encryption and access controls help protect sensitive information in transit and at rest.
• Database backup and recovery capabilities support continuity planning.
• The AWS services handling protected health information must be covered by the applicable Business Associate Agreement (BAA) and service eligibility requirements.

genusAI uses frontier models for de-identified information. Sensitive information is handled by private internal models running on genusConnect’s own hardware and data systems.

Start with the program, the people using it, and the information it needs. A branded preview can use sample people and sample notes while the team works through the operating requirements.

genusConnect supports managed AWS deployment, with a separate workload account available as a scoped deployment option. Environment ownership, region, permissions, integrations, and support responsibilities are agreed for the project.

• Define who operates the environment and who administers partner access.
• Review data retention, backups, recovery expectations, and incident contacts.
• Validate the agreed workflows and connections before introducing live protected health information.

HL7 develops standards for exchanging health information. FHIR, or Fast Healthcare Interoperability Resources, is one of those standards and supports exchanging defined healthcare data through interfaces such as APIs.

HL7 v2 and FHIR connections are scoped with your IT team and system vendors. The available interfaces, information to be exchanged, permissions, and care workflow determine the approach and implementation effort.

• Agree the sending and receiving systems, data fields, and patient-matching approach.
• Define consent and access rules, error handling, and who supports the connection.
• Test the agreed interface before relying on it in a live program. Connection availability is confirmed for each project.

Single sign-on (SSO) can let staff use their organization’s identity to access a connected service. genusConnect uses Amazon Cognito for current authentication; partner SSO is scoped implementation work.

Together, we evaluate SAML or OpenID Connect (OIDC), the organization’s identity provider, and the permissions staff need. A successful sign-in still needs the right application role and organization access.

• Agree identity-provider configuration, role mapping, and multifactor authentication requirements.
• Plan account creation, staff changes, access removal, and session behavior.
• Confirm the connection and test the staff journey before enabling it for the program.

• Care-platform infrastructure supports encryption, managed identity, scoped access, and backup capabilities. Partners should review the controls and configuration for their deployment.
• Review staff permissions, account removal, authentication requirements, and permitted disclosures as part of program onboarding.
• Discuss recovery expectations, incident contacts, retention, and staff responsibilities in the applicable agreement. A capability is not a guarantee of a particular service level.
• Public website inquiries use Cloudflare D1 and Resend. Google Forms, Calendly, and care-wall previews are separate integrations described in the Privacy Policy; the care platform’s AWS agreement does not automatically cover them.
• SOC 2 readiness is not a completed SOC 2 examination or report. This page does not claim HIPAA certification.

A business associate may handle protected health information only as permitted by its agreement and applicable law. A general website privacy notice does not replace a healthcare provider’s Notice of Privacy Practices or a program-specific notice.

HIPAA’s minimum-necessary standard applies where required, with exceptions including certain disclosures for treatment. Access and disclosure still need an appropriate legal basis.

Requests for access, amendment, restrictions, confidential communications, or an accounting of disclosures depend on the records and the applicable rules. Contact the provider responsible for your care records; our support team can help identify the relevant program.

HIPAA does not establish a general medical-record retention period. Other laws, agreements, and record types affect retention; required HIPAA compliance documentation has its own retention requirements.

Additional rules can apply to substance-use-disorder records. The relevant provider or program supplies its required notices. Proposed changes to the HIPAA Security Rule are not represented here as rules already in force.

Tell support which service is involved and how we can contact you. For a care-program issue, also use the partner’s incident or support channel. This website and email are not emergency services.

When a business associate discovers a breach of unsecured protected health information, HIPAA requires notification to the covered entity without unreasonable delay and no later than 60 days after discovery. The agreement may require earlier reporting.

Individual, regulator, and media notices depend on the responsible party, circumstances, and applicable law. A partner may delegate notification tasks; no single deadline describes every type of notice. Other privacy and breach laws can apply outside HIPAA.