Data Security & HIPAA Framework

1. HIPAA regulatory context

HealthTrajectory is a consumer-facing application in which you initiate and authorise data connections. When a person directs their own records to a standalone consumer app of their choosing, that app is generally governed by Federal Trade Commission consumer protection law rather than by HIPAA, because the app is not acting as a covered entity or as a business associate of one.

That is our position, and we state it openly rather than implying a HIPAA status we do not hold. Two consequences follow, and both matter to you:

• Health information in HealthTrajectory does not carry the federal HIPAA protections it had while it sat with your provider.
• We remain subject to the FTC Act and the FTC Health Breach Notification Rule, plus state consumer health data statutes such as Washington’s My Health My Data Act — which carry real enforcement, including a private right of action in Washington.

Because we integrate directly with Epic FHIR infrastructure and handle information that is Protected Health Information in its origin system, we design and operate to HIPAA Security Rule standards by choice. Where a provider organisation requires a Business Associate Agreement for a specific deployment, we will enter into one and accept the corresponding obligations.

2. Encryption

• In transit. All traffic between the App, our servers, Epic FHIR endpoints and your device is encrypted with TLS 1.3 over HTTPS. Plaintext HTTP is not served.
• At rest. Databases holding health histories, bloodwork records and profile details are encrypted with AES-256. Backups are encrypted with the same standard.
• Credentials. Passwords are stored only as salted cryptographic hashes using a memory-hard algorithm. We cannot read your password, and neither can anyone who obtains the database.
• Tokens. OAuth access and refresh tokens for provider integrations are encrypted at rest and scoped to the minimum authorisation you granted.

3. Authentication and authorisation

User authentication and external electronic health record authorisation are executed using OAuth 2.0 and SMART on FHIR profiles.

Your provider portal credentials are never entered into, transmitted through, or stored by HealthTrajectory. Authorisation happens on your provider’s own system; what we receive is a scoped token, which you can revoke at any time from within the App or from your provider’s account settings.

4. Access controls and monitoring

• Role-based access. Internal system processes interact only with the data required for platform utility, on a least-privilege basis.
• Administrative access. Access to production systems requires multi-factor authentication, is granted only where an operational need exists, and is revoked when that need ends.
• Audit logging. Database connections, authentication events, record access and API calls are logged so that access to health information can be reconstructed after the fact.
• Separation of environments. Development and testing use synthetic or de-identified data. Production health data is not copied into non-production environments.

5. Infrastructure and service providers

We use third-party infrastructure — hosting, managed databases, authentication and AI inference — and we choose vendors on their security posture, not only their price. Each is bound by a written agreement requiring confidentiality, use limited to providing their service to us, equivalent technical safeguards, and prompt notification of any incident. Vendors handling health information are contractually prohibited from using it for their own purposes, including model training. We maintain a current inventory of which vendors can touch health data.

6. Application security practices

• Dependencies are monitored for known vulnerabilities, and security updates are applied on a defined schedule with critical fixes expedited.
• Changes go through review before reaching production; nothing is deployed straight from a developer machine.
• Secrets are held in a managed secret store, never in source control.
• Inputs are validated server-side, and authorisation is enforced on the server for every request rather than assumed from the client.
• Backups are taken on a defined cycle and restores are periodically tested, because an untested backup is not a backup.

7. Incident response and breach notification

We maintain an incident response process covering detection, containment, investigation, remediation and notification.

If identifiable health information is acquired without authorisation, the FTC Health Breach Notification Rule applies. We will notify affected users — and, where the Rule requires, the Federal Trade Commission and the media — without unreasonable delay and in any event within sixty (60) calendar days of discovery, together with any faster notice a state law requires. Notice will state what happened, what information was involved, what we have done, and what you can do.

8. Responsible disclosure

If you find a vulnerability, report it privately to Contact@espyeon.com and give us a reasonable period to remediate before disclosing it. We will not pursue legal action against researchers acting in good faith who stay within their own account and data, avoid privacy violations and service degradation, and do not exfiltrate, modify or destroy data. Testing that reaches another person’s health information is not good faith — stop and tell us instead.

9. What you control

The strongest control on your account is your own. Use a password unique to HealthTrajectory, enable every authentication factor the App offers, keep your device locked and updated, disconnect integrations you no longer use, and tell us immediately at Contact@espyeon.com if you suspect unauthorised access.

10. Limitations