Security
Up to Speed handles deeply personal health information. The decisions below are how we earn the right to do that. This page is a living document. It will change as the Service evolves, and we are happy to answer specific questions.
Contents
1. Principles
Three rules guide every security decision in Up to Speed:
- Ask for the minimum. The narrowest read permissions that work, the smallest set of data we touch, the shortest log retention that lets us debug.
- Never write back. Up to Speed is read-only with respect to your medical record. It cannot place orders, schedule, or message clinicians on your behalf.
- Make leaving easy. Disconnection, export, and deletion are first-class features, not buried.
2. Encryption
2.1 In transit
All connections to Up to Speed use TLS 1.2 or newer with modern cipher suites. HTTP Strict Transport Security (HSTS) is enabled. Connections to upstream FHIR endpoints and AI providers also use TLS 1.2+.
2.2 At rest
Database storage and backup volumes use full-disk AES-256 encryption. Sensitive application-level fields, including OAuth access tokens, refresh tokens, and other long-lived credentials, are additionally encrypted at the application layer using authenticated encryption with per-record keys derived from a master key held outside the application database.
3. Authentication
User passwords are stored as salted hashes (bcrypt). Up to Speed does not currently offer two-factor authentication; if you want a second factor in front of your Up to Speed account, sign in with Google and enable two-step verification there.
Session cookies are HTTP-only, Secure, and SameSite=Lax. Sessions are bound to the user's account and can be revoked from the Settings page on any device.
4. How the record connection works
Up to Speed connects to your hospital's record using SMART on FHIR, the industry-standard mechanism MyChart uses to let outside applications read your data with your permission. You sign in at your hospital's own site and approve the request there; Up to Speed never sees your MyChart credentials. You can revoke the connection from your hospital's patient portal or from Up to Speed's Settings at any time, and the return address Up to Speed uses is fixed and registered with your hospital, so it is not user-configurable.
The access Up to Speed requests is read-only and granular. Instead of one broad “all of your data” permission, it asks for a separate, narrow permission for each kind of data it consumes: demographics; laboratory results and vital signs; lab and imaging reports; medications; visits and hospital admissions; diagnoses; and clinical notes and radiology reports. Up to Speed requests no permission to write to your record, place orders, schedule, message clinicians, or reach any patient other than the one you've connected.
The credentialed handshake with your hospital happens entirely server-side, never in your browser, and uses key material Up to Speed never transmits where your hospital's system supports it. Credentials can be rotated without re-registering.
5. Access credentials
The time-limited credentials your hospital issues to Up to Speed after you approve the connection are encrypted before being stored, using a key unique to that connection. They are decrypted only at the moment Up to Speed makes a call to your hospital, held in memory only for that call, and removed automatically once they expire.
6. Data isolation
Each Up to Speed account is scoped to its own user record, and authorization is enforced at every layer of the application: routing, controller, query, and serializer. Background jobs that process FHIR data run in the user context of the connection that produced them and cannot reach other users' data.
Original FHIR payloads are stored verbatim alongside the parsed, normalized values that drive Up to Speed's dashboards. This lets us reprocess your data as we improve the application without needing to re-fetch it from the source, and it gives you a clean export path if you ever want to take your record elsewhere.
7. Infrastructure
Up to Speed runs on a rented virtual machine its operator administers rather than on a managed platform, behind a hardened reverse proxy with automated TLS, request rate limiting, and aggressive timeouts. Our additional disclosures name the hosting provider and say what a provider holding the disk can necessarily reach. The application server, the database, and background workers are isolated processes managed by a supervisor that restarts them on failure. Database backups are encrypted with the same standard as the live database, retained on a rotation, and stored separately from the primary host.
8. AI provider handling
Up to Speed's AI features fall into two groups, and as uptospeed.health is configured today both of them send data to OpenAI:
- Everyday text features, meaning plain-language explanations of lab tests and imaging reports. Each runs only when you press its button. These used to run on a model hosted on the server itself. They no longer do.
- Clinical-style review, meaning lab reviews, rounds preparation, methotrexate clearance and threshold checks, pathology and imaging findings extraction, and echo trends. We send a curated subset of your data, never your full record. The lab review and the imaging findings extraction run on their own when new results arrive; the rest wait for a button press.
Up to Speed marks every request to OpenAI store: false, which asks them not to keep it on the account and not to use it to improve their models. Under OpenAI's standard API terms it may still be held for roughly 30 days for abuse monitoring, and Up to Speed cannot verify or enforce that. The operator of an Up to Speed server can point either group at a model running on the server itself instead. The full account is in our privacy policy and additional disclosures.
Every AI call is logged to a per-user audit trail visible inside Up to Speed so you can see what was sent, when, and what came back.
9. Personnel access
Production access is limited to personnel who require it. Production credentials are not shared, are rotated on a regular cadence, and require multi-factor authentication. Privileged actions on production are logged. There is no routine access to user data. Access happens only in response to a specific support request you initiate, an investigation of a security event, or a legal requirement.
10. Logging and monitoring
Application and request logs contain the metadata needed to diagnose problems and detect abuse, retained for 30 days and then deleted. Logs do not contain plaintext credentials or full FHIR payloads. We monitor for unusual authentication patterns, unexpected error rates, and abnormal traffic, and we alert on conditions that suggest a compromise.
11. Incident response
If we discover a security incident affecting your data, we will notify you without undue delay and in any event within 72 hours of becoming aware of the incident, with the information you need to understand what happened, what was affected, and what we are doing about it. We will also notify regulators where required by law.
12. Vulnerability disclosure
We are grateful to security researchers who help keep Up to Speed safe. If you believe you have found a security vulnerability in the Service, please report it to security@uptospeed.health. Please give us a reasonable opportunity to investigate and remediate before any public disclosure.
You can expect:
- Acknowledgement of your report within 72 hours;
- An initial assessment within 7 days;
- Regular updates while we work on a fix;
- Credit (with your permission) once the issue is resolved.
We will not pursue legal action against researchers who act in good faith, follow these guidelines, and avoid privacy violations, service disruption, or destruction of data.
13. Contact
Security questions: security@uptospeed.health
Privacy questions: privacy@uptospeed.health
General support: support@uptospeed.health