Security

Last Updated: September 24, 2026

MedSystum ("Company," "we," "us," or "our"), processes sensitive healthcare payment data, including Protected Health Information ("PHI") contained in the 835/ERA remittance files you submit. This page summarizes the technical and organizational safeguards we use to protect that data.

Note: This page is provided for the initial release of the marketing website and describes our target security posture. It does not constitute a warranty or legal advice and will be updated as controls are formalized and independently assessed.

Section 1 — Encryption

• In transit. All traffic between you and the Service is encrypted using industry-standard Transport Layer Security (TLS 1.2 or higher).
• At rest. Data is stored on encrypted infrastructure. Sensitive application secrets — including any per-organization AI provider credentials and clearinghouse SFTP credentials — are additionally encrypted at the application layer using authenticated symmetric encryption (AES-based), with encryption keys managed separately from the data they protect.

Section 2 — HIPAA and Business Associate Obligations

We act as a Business Associate with respect to PHI in your Remittance Data. We enter into a Business Associate Agreement ("BAA") with you before you transmit any PHI. We use PHI solely to provide the Service and apply the minimum-necessary principle to every access and transmission.

Section 3 — Access Controls and Authentication

• Role-based access control with least-privilege roles (owner, admin, member, viewer).
• Token-based authentication with signed, expiring session credentials.
• Administrative actions and access to sensitive configuration are restricted by role.
• Two-factor authentication (TOTP authenticator apps) is available on every account and can be enabled in Settings. We strongly recommend it for all users and enable it for administrative accounts during onboarding.
• Team members are added by invitation only: an administrator invites a user with a specific role, and the user activates the account through a single-use, expiring set-password link. Self-registration into an organization is not possible.
• Clearinghouse connections (SFTP delivery of 835/ERA files) can be configured only by administrators. The clearinghouse server's host key is pinned and verified before any credential is sent, connections to private or internal network addresses are refused, and stored credentials are never displayed again after they are saved.

Section 4 — Tenant Isolation

The Service is multi-tenant. Every record is scoped to the organization that owns it, and access is enforced so that one organization cannot read another organization's data, reports, or configuration.

Section 5 — Artificial Intelligence and Subprocessors

Certain optional features generate plain-English explanations and draft appeal letters using third-party AI providers. Where such providers process data on our behalf, they do so under agreements — including BAAs where applicable — and through endpoints configured for zero or limited data retention. Requests to these providers exclude patient names, dates of birth, Social Security numbers, and member IDs; claim-level references (claim control numbers, procedure codes, and dollar amounts) may be included, and are only ever sent through the retention-limited or BAA-covered endpoints described above. See our Responsible AI page for details.

Subprocessors

The Service relies on the following subprocessors:

• Google Cloud Platform (Cloud Run, Cloud SQL — us-central1): application hosting, database, and file storage. Processes Remittance Data, including PHI.
• Vercel: hosting for the web application and this website. Serves the user interface; Remittance Data is not stored on Vercel infrastructure.
• Resend: transactional email (team invitations, notifications). No PHI is included in email.
• Google Cloud Vertex AI (Gemini models, covered by Google Cloud's BAA) and, where configured per-tenant, Anthropic: optional AI explanation features, as described above.

We will update this list before adding a subprocessor that handles PHI.

Section 6 — Infrastructure

The Service is hosted on HIPAA-eligible cloud infrastructure. We rely on the provider's physical security, network isolation, and availability controls, and configure our environment to limit network exposure.

Section 7 — Logging and Monitoring

We maintain audit logging of significant system and data-access events, including access to PHI, to support security review and our regulatory obligations. We monitor for anomalous activity and errors.

Section 8 — Vulnerability and Patch Management

We track dependencies for known vulnerabilities, apply security updates on a timely basis, and intend to engage independent third parties for periodic penetration testing.

Section 9 — Incident Response and Breach Notification

We maintain an incident-response process. In the event of a security incident involving PHI, we will investigate, remediate, and provide notifications in accordance with our BAAs, HIPAA, and applicable law.

Section 10 — Data Retention and Deletion

We retain data only as long as necessary to provide the Service and meet our obligations, and we return or destroy PHI on termination as described in our Data Retention Policy and the applicable BAA.

Section 11 — Compliance Roadmap

We are building toward recognized third-party assurance (such as SOC 2 and HITRUST). Status updates will be provided to prospective customers upon request.

Section 12 — Responsible Disclosure

If you believe you have found a security vulnerability, please contact us at security@medsystum.com. We appreciate responsible disclosure and will work with you to validate and remediate reported issues.