How TMN Flow protects patient data.
Every TMN Flow launch runs in a dedicated AWS environment under a signed BAA, with encryption keys made for that practice alone. Here is every control, in plain terms.
HIPAA compliant
BAA-covered AWS infrastructure, a signed BAA with every practice, and documented safeguards before patient data moves.
The essentials
The 8 controls practices ask about first.
A signed BAA before any patient data moves
Every practice signs a BAA with TMN Creative, and TMN Flow runs on AWS infrastructure covered by AWS’s BAA. Your team approves in writing what is collected, where it is stored, who is notified, and how long it is kept.
Encryption keys made for your practice
Each practice gets 2 AWS KMS keys of its own. Key material never leaves AWS KMS, and every key rotates automatically.
Every application encrypted twice
Each application is sealed with AES-256-GCM under its own data key the moment it is received, then stored in tables encrypted with a second practice key.
Locked down, even from us
TMN’s own access roles are explicitly denied any read of a submission and any use of a practice’s payload key. The deploy pipeline cannot read patient data either.
Every change on the record
AWS CloudTrail records every action in the account into a locked archive kept for 7 years. Any change to keys, access, logging, or security settings sends an alert.
Monitored around the clock
Amazon GuardDuty and IAM Access Analyzer watch the account continuously, and a web application firewall screens every submission before it reaches the server.
No patient details in logs
Logs carry only a fixed list of operational fields, never patient details. An automatic tripwire flags anything in the logs that looks like personal data.
Patient details deleted on schedule
Details are kept only to deliver the referral and let your team confirm it, then deleted automatically on the schedule your practice approves in writing.
Encryption
In transit and at rest, with keys that belong to 1 practice.
TLS 1.2 or higher, HTTPS only
Your intake page and the API accept HTTPS only, with a TLS 1.2 minimum. AWS calls go to FIPS-validated endpoints where AWS offers them.
Verified connections to your system
Delivery to your system uses HTTPS with certificate verification always on, to an approved host only.
Email that requires TLS
Notification emails are sent only over TLS. A server that cannot do TLS does not receive the message, and the failure is recorded.
Bound to the right practice and record
Every encrypted record is cryptographically bound to its practice, its record, and its purpose, so it cannot be opened for the wrong one.
Isolation
Each practice runs in a stack of its own.
Separate everything that holds data
Each practice has its own API, hostname, tables, keys, credentials, and functions. Nothing in one practice’s stack holds another practice’s data.
No tenant switching
No request can choose which practice it reaches. Each function learns its practice at deploy time, never from the request.
Access
Fewer people, fewer keys, and nothing that lasts.
1 human identity, multi-factor every time
Human access is limited to TMN’s owner, with multi-factor sign-in on every sign-in and sessions that end after 1 hour.
No long-lived keys
No identity in the account holds a long-lived access key, and the root user has none.
Least privilege, with a hard ceiling
Every function has its own role with only the actions it needs, and a permissions boundary caps every role the system can create.
Production changes from AWS only
Production deploys run only inside AWS CloudShell, under the owner’s multi-factor session. No laptop or outside tool holds production credentials.
Monitoring and audit
Every action is recorded, and the important ones raise an alert.
A locked 7-year audit trail
CloudTrail logs every account action, plus every read and write of a storage bucket, into an archive under a 7-year retention lock.
Alerts on what matters
Root sign-in, key policy changes, trail changes, deleted logs, and permission changes each send an alert the moment they happen.
Threat detection
Amazon GuardDuty watches for stolen credentials and unusual activity. IAM Access Analyzer flags any resource shared outside the account.
A personal-data tripwire
A data protection policy scans the application logs for emails, phone numbers, Social Security numbers, insurance IDs, and IP addresses, and raises an alarm on any match.
The front door
A web application firewall screens every submission before the server sees it.
Rate limits and reputation blocking
Each address is limited to 30 requests per 5 minutes, and Amazon’s IP reputation list blocks known bad sources.
Only what an application looks like
Anything that is not a POST, carries a query string, or exceeds 16 KB is blocked. The API’s default AWS address is turned off.
Checked twice
Every answer is validated on the page, then again on the server, before anything moves.
Retention and recovery
Patient details are kept only as long as the job requires.
Deleted automatically
Details are deleted 7 days after delivery by default, on the schedule your practice approves in writing, with a hard stop after 90 days.
Delivery records without patient fields
Each delivery’s status and attempts are recorded, with no patient fields in the record.
Protected against accidents
A 3-day point-in-time recovery window protects the submissions table against an accidental delete.
Change control
Every change is planned, logged, and checked before it runs.
Logged before it runs
Every production deploy is written in the change log before it runs, and an alert that matches no entry is handled as an incident.
Data stores cannot be replaced by accident
A deploy stops automatically before it would replace or delete a table, key, role, queue, or secret.
Questions from your compliance team?
We walk through every control on the intake review, and your team approves in writing what is collected, where it is stored, who is notified, and how long it is kept before anything launches.