INTEROPX / SECURITY
Every message carries a patient's data. Here, security isn't a feature — it's the requirement.
InteropX is built around three questions any healthcare CTO will ask before signing off: who's allowed in, what happens to the data once they are, and how do you prove it later. This page answers all three.
ACCESS CONTROL
OAuth 2.0 · SMART on FHIR · RBAC
DATA PROTECTION
AES-256 at rest · TLS 1.2+ in transit
ACCOUNTABILITY
Append-only, query-level audit logs
REGULATORY ALIGNMENT
HIPAA Security Rule · BAA available
Identity & Access
Before any message is parsed or any record is returned, InteropX has to answer: who is this, what are they allowed to see, and how was that decided.
OAuth 2.0
Every client — internal service, partner integration, or third-party app — authenticates through standard OAuth 2.0, not a custom scheme to audit separately.
- —Client credentials, authorization code, and refresh token flows
- —Short-lived access tokens with automatic refresh rotation
- —Scope-restricted grants, down to resource type and operation
SMART on FHIR
Third-party clinical apps authenticate the same way whether embedded in the EHR or launched standalone — no separate integration path required.
- —EHR-launch and standalone launch flows both supported
- —Patient and encounter context passed securely at launch
- —Scoped access enforced down to individual FHIR resource types
Role-Based Access Control
Permissions map to real clinical and operational roles, not generic admin/user levels — so access reflects how a health system actually works.
- —Predefined roles for clinician, front-desk, billing, and integration admin
- —Least-privilege by default; access is granted, not assumed
- —Enforced at both the API layer and the data layer
Session & Token Security
Access doesn't just get granted correctly once — it's continuously re-verified for as long as a session is active.
- —Configurable token expiry per client type
- —Immediate revocation on credential compromise or role change
- —No long-lived static API keys for production traffic
Data Protection
Once access is granted, the data itself still has to be protected in motion, at rest, and in the record of who touched it.
Encryption
Patient data is encrypted everywhere it exists — in the database, in backups, and on the wire between every system it passes through.
- —AES-256 encryption at rest, including backups
- —TLS 1.2+ (1.3 where supported) for all data in transit
- —Managed key rotation; no PHI written to plaintext logs
Audit Logs
Every read and write is recorded in an append-only log that can't be edited after the fact — the record of what happened is as protected as the data itself.
- —Tamper-evident, query-level logging — not just record-level
- —Actor, timestamp, and resource captured on every access
- —Exportable audit trails to support HIPAA Security Rule reviews
PHI Isolation
Protected Health Information is segmented at the data layer so a misconfigured query or a compromised tenant can never access another customer's records.
- —Row-level security enforced at the database, not the application
- —Tenant context injected at the gateway, not trusted from the client
- —PHI fields flagged and masked in non-production environments
Key & Secret Management
Credentials, API keys, and encryption keys are never stored in application config or source code — managed through a dedicated secrets layer.
- —Secrets stored in a dedicated vault, rotated on schedule
- —Zero hard-coded credentials in any service or deployment artifact
- —Automatic re-keying on personnel change or suspected compromise
Compliance & Assurance
Security controls only matter if they map to what your compliance team actually has to demonstrate.
HIPAA
The architecture is built around the three safeguard categories the HIPAA Security Rule requires — not retrofitted onto a platform designed for something else.
- —Technical safeguards: access control, audit logging, encryption
- —Administrative and physical safeguards supported at the deployment layer
- —Minimum-necessary access enforced via RBAC and consent rules together
- —Business Associate Agreement (BAA) available for covered entities
Broader Compliance
HIPAA is the baseline, not the ceiling. InteropX's controls support the broader compliance picture health systems and their vendors operate under.
- —Architecture aligned with SOC 2 control objectives
- —GDPR-ready data handling for international deployments
- —Configurable data residency by deployment model
- —Audit exports formatted for compliance and legal review
A note on certification: specific certification status (SOC 2 report availability, BAA terms, regional data-residency guarantees) depends on deployment model and is confirmed during technical and legal review — this page describes the architecture's design intent, not a substitute for that review.
Bring your security questionnaire — we'll answer it against the actual architecture.
A working session with our engineering and compliance leads, scoped to your BAA, data-residency, and audit requirements.
Request security reviewSee architecture →Frequently asked questions
Yes. Every component is built with HIPAA Technical Safeguards as a default — PHI encryption at rest (AES-256) and in transit (TLS 1.3), role-based access controls, append-only audit logging, and BAA coverage for all subprocessors.
Every client authenticates through standard OAuth 2.0. SMART on FHIR is supported for clinical app launches — EHR-embedded or standalone — with patient and encounter context passed securely at launch.
AES-256 for all data at rest including backups. TLS 1.2+ (1.3 where supported) for all data in transit. No PHI is ever written to plaintext logs.
Yes. A Business Associate Agreement is available for all deployment models — SaaS, private cloud, on-premises, and hybrid. BAA terms are confirmed during the technical and legal review prior to go-live.
InteropX's architecture is aligned with SOC 2 Type II control objectives. Specific certification status depends on the deployment model and is confirmed during the security review.
Have more questions?
Ask our experts
