Security & HIPAA
Written for the person who reviews us.
Most vendor security pages are a list of words chosen to survive a skim. This one is organised the way your IT reviewer would organise it: where we sit in the HIPAA framework, the controls that exist in the code today, and every vendor in the path of patient data, named.
Where we sit
We are a business associate, and we act like one.
We are not a covered entity, we do not bill payers, and we do not practise medicine. We process protected health information on your instructions to run workflows you ordered — which puts specific, enforceable obligations on us.
No protected health information reaches this system before a business associate agreement is signed.
You own the record
As between us, the practice owns the patient records and the protected health information. We hold it to do the job you hired us for.
You submit the claims
We never bill Medicare, never take reassignment of benefits, and never sit between your practice and its money.
Your clinicians decide
Every clinical action has a named human and a timestamp attached. We employ no clinical staff.
Subprocessors inherit the obligations
Any vendor in the path of patient data is held to the same terms we accept from you, and is required to have an agreement in place before it sees any.
Built and running
Controls that exist in the code today.
These are on in our demonstration environment, which is how we know they work rather than hope they will.
Mapped to the HIPAA Security Rule's technical safeguards. Descriptions are deliberately specific: a reviewer can ask us to demonstrate any line here.
Encryption of identifiers at the column level
Patient names, Medicare Beneficiary Identifiers, phone numbers, and email addresses are encrypted as individual database fields, not merely protected by disk encryption. A database dump without the application key does not yield identities.
Encrypted transport, signed callbacks
Every outbound call runs over HTTPS. Inbound webhooks from device and messaging vendors are HMAC-SHA256 signed and idempotent, so a replayed or forged callback cannot create a reading or advance a workflow.
Authenticated by default, authorised by role
No endpoint is public unless deliberately made so. Access is scoped by role — clinical staff, physician, administrator, operations — and enforced per route on the server, not hidden in the interface.
An append-only audit log
Every read of patient data and every workflow action carries an actor and a timestamp. The log is append-only in the data model: entries cannot be edited or deleted, including by us.
Tenant isolation between practices
A practice's data is scoped to that practice. Users hold access to the clinics they belong to, and switching context is an explicit, logged action.
Minimised input to the language model
Before anything reaches a model, identity is stripped: it receives an opaque internal token, an age, coded conditions, and the readings. No name, no date of birth, no Medicare Beneficiary Identifier, no address.
A hard human boundary on clinical action
The model drafts and ranks. It cannot sign an order or a note, change a plan, enrol a patient, or submit a claim. That boundary is enforced in code, not in policy.
No patient data in support channels
Protected health information does not go into vendor support tickets, chat logs, or issue trackers. Reproductions use synthetic records.
Subprocessors
Every vendor that touches the data.
Four, named. Each one is here because it does something we would otherwise have to build badly, and each is in scope for your security review.
Clinical drafting
Anthropic
Ranks incoming readings and drafts notes, orders, and patient outreach.
Monitoring devices
Tenovi
Supplies the cellular cuffs, glucometers, scales, and pulse oximeters, ships them to the patient, and posts each reading back to us. Device assignment is keyed to the same opaque token, and Tenovi never receives the clinical record.
Delivery to the chart
Documo
Faxes signed orders and notes into your record over their HIPAA-covered API. This is the subprocessor that necessarily handles an identified document, because the document is the point.
Hosting and compute
AWS
Runs the application, its database, and the scheduled worker. Region and configuration are documented and reviewed with you before go-live.
Patient messaging and claim submission run through pluggable adapters, so a practice that already has a clearinghouse or a messaging platform keeps it. Whichever vendor lands in that slot is held to the same terms we accept from you and has an agreement in place before it sees patient data.
Reporting a vulnerability
Email us with enough detail to reproduce it. We will confirm receipt, keep you updated while we fix it, and credit you if you want the credit. We will not threaten you.
security@itas.healthPlease do not include real patient data in a report. Nothing on this page is legal advice, and it does not modify any agreement between us.