🏥 ORHub HIPAA Compliance & Security Whitepaper

Version: 1.0 Date: May 19, 2026 Classification: Public

1. Executive Summary

ORHub is an AI-powered surgical coordination agent designed for Ambulatory Surgery Centers (ASCs). Staff interact with ORHub via SMS to coordinate OR scheduling, turnover tracking, and case preparation. A web-based supervisor dashboard provides read-only operational visibility.

This document provides a transparent assessment of ORHub's security posture, HIPAA compliance controls, and infrastructure architecture. It is intended for hospital CISOs, IT directors, and compliance officers evaluating ORHub for pilot deployment.

Our approach: We distinguish clearly between controls that are implemented today, those actively in progress, and those on our roadmap. Every architectural decision — from choosing AWS Bedrock over direct API calls, to minimizing PHI in SMS — was made with HIPAA in mind from day one.

Controls Implemented

In Progress

Planned

365d

Log Retention

Key Security Highlights

BAA signed with AWS — covering EC2, EBS, CloudWatch, and Bedrock
Encryption everywhere — AES-256 at rest, TLS 1.2+ in transit
AI under BAA — Claude Sonnet via AWS Bedrock; no data leaves the BAA perimeter
PHI minimization — SMS contains only first names, room numbers, and times
Tamper-resistant audit trail — dual storage in Firestore + CloudWatch
Zero stored credentials — IAM instance roles for all AWS auth

2. Architecture Overview

Component	Technology	Purpose
Application Server	Node.js / Express	Core application logic
Infrastructure	AWS EC2 (us-east-1)	Compute
Database	Google Cloud Firestore	Data storage, audit logs
Authentication	Firebase Auth	Dashboard user auth
AI Engine	AWS Bedrock (Claude Sonnet)	NLP, coordination logic
SMS Gateway	TextMagic	SMS communication
Web Server	Nginx	Reverse proxy, TLS termination
Monitoring	AWS CloudWatch	Log aggregation

Architecture Diagram

┌──────────────────────────────────────────────────────────┐
│                   AWS Cloud (us-east-1)                   │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │           EC2 Instance (Encrypted EBS)             │  │
│  │                                                    │  │
│  │  ┌──────────┐    ┌─────────────────────────────┐   │  │
│  │  │  Nginx   │───▶│  Node.js Express App        │   │  │
│  │  │  (TLS)   │    │     (localhost:3000)         │   │  │
│  │  └────┬─────┘    └──────┬─────────┬────────────┘   │  │
│  └───────┼─────────────────┼─────────┼────────────────┘  │
│          │          ┌──────▼──────┐   │                   │
│          │          │ AWS Bedrock │   │                   │
│          │          │ (Claude)    │   │                   │
│          │          │ [BAA ✅]    │   │                   │
│          │          └─────────────┘   │                   │
│   ┌──────▼───────────┐   ┌───────────▼──────────┐       │
│   │ CloudWatch [BAA✅]│   │ Security Group       │       │
│   │ (365-day logs)    │   │ 22 / 80 / 443 only  │       │
│   └──────────────────┘   └──────────────────────┘       │
└──────────────────────────────────────────────────────────┘
         │ HTTPS                         │ HTTPS
         ▼                               ▼
┌──────────────────┐          ┌──────────────────┐
│ Google Firebase  │          │   TextMagic      │
│ / Firestore      │          │  (SMS Gateway)   │
│ [BAA 🔄]         │          │  [BAA 📋]        │
└──────────────────┘          └────────┬─────────┘
                                       │ SMS
         HTTPS                         ▼
         ▼                    ┌──────────────────┐
┌──────────────────┐          │   ASC Staff      │
│ Supervisor       │          │  (Mobile Phone)  │
│ Dashboard        │          └──────────────────┘
│ (Firebase Auth)  │
└──────────────────┘

3. Data Flow

SMS Interaction Flow

Staff Phone              ORHub                        AWS Bedrock
    │                      │                              │
    │── SMS (TextMagic) ──▶│                              │
    │                      │── Log inbound ──────────────▶│ Firestore
    │                      │── Process context ──────────▶│ Bedrock
    │                      │◀── AI response ──────────────│ (not retained)
    │                      │── Log response ─────────────▶│ Firestore + CW
    │◀── SMS Reply ────────│                              │
    │ (first name,         │                              │
    │  room, time only)    │                              │

PHI Data Locations

Location	PHI Present	Encrypted at Rest	Encrypted in Transit	BAA
AWS EC2 / EBS	Yes (in memory)	AES-256	N/A	✅
Google Firestore	Yes	AES-256	TLS 1.2+	🔄 In Progress
AWS Bedrock	Transient only	Not stored	TLS 1.2+	✅
AWS CloudWatch	Yes (logs)	AES-256	TLS 1.2+	✅
TextMagic	Minimized	Provider-managed	TLS	📋 Investigating
SMS (staff phones)	Minimized	Device-dependent	Carrier-dependent	N/A
Web dashboard	Display only	N/A	TLS 1.2+	N/A

4. Security Controls

Server Hardening

Control	Description	Status
OS Updates	Unattended security updates (automatic)	✅ Implemented
SSH Hardening	Key-only auth; password disabled; root login disabled	✅ Implemented
Brute Force Protection	Fail2ban: 3 failed attempts → 1-hour IP ban	✅ Implemented
Minimal Attack Surface	Security Group: ports 22, 80, 443 only	✅ Implemented
App Isolation	Node.js on localhost only; Nginx reverse proxy	✅ Implemented
Privilege Separation	Dedicated deploy user, no root for app ops	✅ Implemented
Process Management	systemd with automatic restart on failure	✅ Implemented
Penetration Testing	Third-party pen test	📋 Planned

5. Access Controls

Server Access

Role	Access Method	Permissions
App Deployment	SSH (deploy user)	Deploy code only; no sudo
System Admin	SSH (ubuntu user, .pem key)	Full admin; founding team only

Dashboard Access

Control	Description	Status
Authentication	Firebase Auth (email/password + Google SSO)	✅ Implemented
Data Scoping	Firestore rules enforce facility-level isolation	✅ Implemented
Access Logging	All read operations logged	✅ Implemented
MFA	Multi-factor authentication	📋 Planned
Session Timeout	Automatic session expiration	📋 Planned

Multi-Tenancy

Data isolation is enforced at the database layer — every Firestore document is scoped to a facilityId. Security rules prevent cross-facility access. This is logical isolation within a shared database; single-tenant deployment is available for organizations requiring physical separation.

6. Encryption

At Rest

Layer	Method	Key Management
AWS EBS Volumes	AES-256	AWS-managed
Google Firestore	AES-256	Google-managed
AWS CloudWatch	AES-256	AWS-managed

In Transit

Path	Protocol	Certificate
Client ↔ Nginx	TLS 1.2+	Let's Encrypt (auto-renewing)
App ↔ Firestore	TLS 1.2+	Google-managed
App ↔ Bedrock	TLS 1.2+	AWS-managed
App ↔ TextMagic	TLS 1.2+	TextMagic-managed
App ↔ CloudWatch	TLS 1.2+	AWS-managed

7. Audit & Monitoring

ORHub maintains a comprehensive, tamper-resistant audit trail across two independent storage systems:

Firestore Audit Collection

Every agent interaction: inbound message, AI response, reasoning, actions, token usage
Every dashboard access: user identity, resource viewed, timestamp
Every data modification: before/after state, initiating user
Failed authentication attempts with source IP

AWS CloudWatch Logs

Application logs, authentication logs, Nginx access logs
365-day retention
Stored independently from the application server

Tamper resistance: Audit logs exist in two independent systems (Firestore and CloudWatch), neither on the application server. Compromising the app server does not grant ability to modify or delete audit records.

Logs can be exported from Firestore filtered by date range, facility, user, action type, or case identifier.

8. AI/ML Data Handling

How ORHub Uses AI

ORHub uses Anthropic's Claude Sonnet via AWS Bedrock — a fully managed AWS service covered under the AWS BAA. The AI coordinates surgical operations; it does not make clinical decisions.

Data Retention by the AI Model

AWS Bedrock does not retain, log, or use customer inputs or outputs to train models. Input prompts are processed and discarded. No customer data is shared with Anthropic. This is contractually guaranteed under the AWS BAA and Bedrock service terms.

Authentication

ORHub authenticates to Bedrock using an IAM instance role. No API keys or credentials are stored on disk or in environment variables. Credentials rotate automatically via AWS STS.

No Third-Party AI Providers

ORHub does not send patient data to OpenAI, Anthropic directly, Google AI, or any AI provider outside BAA coverage. All AI processing occurs within the AWS BAA perimeter.

9. Subprocessors & Third Parties

Subprocessor	Service	PHI Access	BAA	SOC 2	Location
AWS	EC2, EBS, Bedrock, CloudWatch	Yes	✅ Signed	Yes	us-east-1
Google Cloud / Firebase	Firestore, Auth	Yes	🔄 In Progress	Yes	us-central1
TextMagic	SMS Gateway	Minimized	📋 Investigating	Varies	EU/US
Anthropic (via Bedrock)	AI Model	Transient	Covered by AWS BAA	Yes	us-east-1

10. Compliance Status Matrix

Administrative Safeguards (§164.308)

Requirement	HIPAA Ref	ORHub Control	Status
Security Management Process	§164.308(a)(1)	Risk assessment; controls per this document	✅
Assigned Security Responsibility	§164.308(a)(2)	Founding team; dedicated officer planned	🔄
Workforce Security	§164.308(a)(3)	Key-based auth; limited access	✅
Information Access Mgmt	§164.308(a)(4)	Facility-scoped access; deploy user separation	✅
Security Awareness Training	§164.308(a)(5)	Formal training program	📋
Security Incident Procedures	§164.308(a)(6)	Process exists; formal docs in progress	🔄
Contingency Plan	§164.308(a)(7)	EBS snapshots; DR plan in development	🔄
Evaluation	§164.308(a)(8)	Internal review; pen testing planned	📋
BAAs with Subprocessors	§164.308(b)(1)	AWS signed; Firebase/TextMagic in progress	🔄

Physical Safeguards (§164.310)

Requirement	HIPAA Ref	ORHub Control	Status
Facility Access Controls	§164.310(a)(1)	AWS SOC-certified data centers	✅ (via AWS)
Workstation Use/Security	§164.310(b-c)	Cloud-only; no on-premise	✅ N/A
Device & Media Controls	§164.310(d)(1)	EBS encryption; no removable media	✅

Technical Safeguards (§164.312)

Requirement	HIPAA Ref	ORHub Control	Status
Access Control	§164.312(a)(1)	Firebase Auth; Firestore rules; SSH keys	✅
Unique User ID	§164.312(a)(2)(i)	Individual accounts and SSH keys	✅
Emergency Access	§164.312(a)(2)(ii)	SSH admin access; formal procedure planned	📋
Automatic Logoff	§164.312(a)(2)(iii)	Session timeout enforcement	📋
Encryption	§164.312(a)(2)(iv)	AES-256 at rest; TLS 1.2+ in transit	✅
Audit Controls	§164.312(b)	Full trail in Firestore + CloudWatch (365d)	✅
Integrity Controls	§164.312(c)(1)	Tamper-resistant off-box dual logging	✅
Authentication	§164.312(d)	Firebase Auth + SSH key-pair	✅
Transmission Security	§164.312(e)(1)	TLS 1.2+ on all paths	✅

11. Risk Assessment

Risk	Severity	Mitigation	Remediation
Firebase BAA not yet signed	High	Migration to Google Workspace org in progress	Q2 2026
TextMagic BAA not signed	Medium	PHI minimized in SMS (first name, room, time only)	Q2-Q3 2026
No MFA on dashboard	Medium	Firebase Auth + access logging	Q2-Q3 2026
Single EC2 instance (no HA)	Medium	systemd auto-restart; EBS snapshots	2027
No formal pen testing	Medium	Hardening, minimal surface, fail2ban	Q3-Q4 2026
No session timeout	Low	Access logging; Firebase session mgmt	Q2-Q3 2026
No formal IRP	Medium	Informal process exists	Q2-Q3 2026

Transparency note: We are an early-stage company. Certain enterprise controls (SOC 2, pen testing, HA) are on our roadmap. We mitigate through security-first architecture, PHI minimization, dual audit logging, and honesty about our current state.

12. Incident Response

Detection: CloudWatch alerting; Fail2ban; audit log monitoring
Containment: Immediate server access termination, Firebase session revocation, SMS integration shutdown
Notification: Covered entity notified within 72 hours; affected individuals within 60 days per HIPAA (45 CFR §164.404-408)
Investigation: Full forensic trail from Firestore + CloudWatch dual logs
Remediation: Root cause analysis and control updates

13. Frequently Asked Questions

Where exactly is PHI stored?: Google Firestore (patient/schedule data, audit logs) and AWS CloudWatch (app logs). Both encrypted at rest. AWS BAA signed; Google Cloud BAA in progress.
Is the AI model seeing PHI?: Yes — it processes patient context for coordination through AWS Bedrock (BAA-covered). It does not retain or learn from the data.
Does the AI retain or learn from our data?: No. Bedrock does not store inputs/outputs or use customer data for training. Contractually guaranteed under AWS BAA.
Who has access to the production server?: A deploy user (no sudo) and an ubuntu admin user (SSH key only). Password auth and root login disabled.
What happens if the server goes down?: systemd auto-restarts the process. No HA/failover yet — planned for scale phase.
Can we get an audit log export?: Yes — Firestore audit collection, filterable by date, facility, user, action type, or case ID.
Penetration testing results?: Not yet — third-party pen test is on near-term roadmap.
Is our data isolated from other facilities?: Yes — all data scoped by facilityId with Firestore security rules. Logical isolation; single-tenant available on request.
What about physical security?: No on-premise infrastructure. AWS us-east-1 data centers maintain SOC 1/2/3 and ISO 27001 with 24/7 physical security.
Is there a mobile app?: No. SMS-based staff interface + web dashboard. No MDM/MAM concerns.

14. Roadmap

Immediate (Q2–Q3 2026)

Initiative	Priority
Google Cloud / Firebase BAA	Critical
TextMagic BAA or HIPAA-compliant SMS migration	High
Formal Incident Response Plan	High
MFA for dashboard login	High
Session timeout enforcement	Medium

Near-Term (Q3–Q4 2026)

Initiative	Priority
Third-party penetration testing	High
Formal data retention/deletion policy	Medium
DR runbook testing	Medium
HIPAA training program	Medium
Dedicated security officer	Medium

Scale Phase (2027)

Initiative	Priority
SOC 2 Type II certification	High
High-availability architecture	Medium
Business continuity plan	Medium
Cyber liability insurance	Medium