Frequently Asked Questions

Seald Healthcare encrypts patient data at the record level before it reaches third-party systems and attaches access policies that remain with the data wherever it goes. You decide who can access each record, under what conditions, and for how long, and you can revoke that access at any time, even after the data has been shared. The result is that PHI remains readable only to the people and systems you authorize, across every vendor, cloud, and workflow.

Seald Healthcare sits at the point where patient data leaves your environment for a third party. In healthcare, that is typically the integration infrastructure your organization already controls, including HL7 feeds, FHIR APIs, Mirth Connect, X12 claims workflows, SFTP transfers, and other outbound connections. We do not replace your EHR. We protect the data flowing to vendors, partners, payers, laboratories, analytics platforms, and AI systems.

It can, depending on the workflow. Most customers keep their existing encryption for systems they already control and deploy Seald Healthcare to protect patient data as it moves across vendors, clouds, and third-party workflows. In those environments, Seald Healthcare complements existing security controls by keeping PHI encrypted and under your control after it leaves your network. In other cases, Seald Healthcare can replace existing encryption entirely. For example, Seald Healthcare can encrypt patient data directly within platforms such as Microsoft OneDrive, Google Drive, SFTP workflows, and other shared storage environments, eliminating plaintext PHI and attaching policy-governed access controls directly to the data. The key difference is that traditional encryption typically protects infrastructure. Seald Healthcare protects the patient record itself, ensuring encryption and access policies remain attached to the data wherever it goes.

No. TLS protects data while it moves between systems, and at-rest encryption protects data while it sits on storage you control. Both stop protecting the data once a third party decrypts it for use. Seald Healthcare keeps patient data encrypted and policy-bound throughout the workflow, decryptable only at the authorized point of access.

Cloud providers secure their infrastructure. You secure your data. That's the shared responsibility model used by AWS, Azure, and Google Cloud. Their protections stop at the boundary of their environment. Seald Healthcare keeps patient data protected across clouds, vendors, processors, partners, and workflows, regardless of where the data travels.

Tokenization replaces sensitive values with tokens and stores the original data in a vault. That vault still contains plaintext data. Seald Healthcare never stores a vault of plaintext patient records. Data is encrypted at the record level, keys are held separately, and access policies remain attached to the data. You also gain real-time revocation and policy-governed access controls that tokenization alone does not provide.

Your first and highest-risk vendor connection is typically production-ready in about 60 days, with encryption, policy enforcement, and audit logging live. Additional vendor connections that use FHIR R4, HL7 v2, X12, or Mirth Connect often deploy much faster because Seald Healthcare sits alongside infrastructure you already operate.

For most vendors, no. If a vendor's staff simply needs to view data, they access it through a secure portal, authenticate, and see only what your policy allows. There is nothing to install and nothing to pay. Higher-volume vendors that process data programmatically can later integrate directly through our SDK. That integration is also free to the vendor.

No. Seald Healthcare sits at the infrastructure your organization already controls, including Mirth Connect, FHIR APIs, HL7 integrations, SFTP workflows, and other outbound connections. We do not require cooperation from Epic, Oracle Health, Athenahealth, eClinicalWorks, or any other EHR vendor.

You keep control of it. Every record remains encrypted and policy-bound after it leaves your environment, decryptable only at the authorized point of access. If a vendor relationship ends, you can revoke access to records that have already been shared. Every access, denial, and policy change is recorded in a tamper-evident audit log.

No. Encryption uses AES-256, which is hardware accelerated on modern processors. Cryptographic operations add microseconds, not milliseconds. In practice, network and application performance dominate workflow latency, not encryption.

Seald Healthcare operates the key management infrastructure, but the application keys that decrypt patient data remain under your control. Master keys are protected by hardware security modules and never exist in usable form outside those systems. The structural rule is simple: we hold keys, you hold data, and a breach of either one alone exposes nothing.

No. This is enforced by architecture, not policy. Seald Healthcare does not receive your patient data in readable form. The application keys that decrypt records remain on your side, which means we cannot access your data even if we wanted to.

Key backups use append-only roles, meaning keys can be added but not silently altered or deleted. Enterprise deployments can place software and keys in escrow through third parties such as Iron Mountain, ensuring recoverability independent of Seald Healthcare.

The encryption layer is. Seald Healthcare uses AES-256, which is widely considered resistant to quantum attacks against symmetric encryption. Our digital signature layer is designed to migrate to NIST-approved post-quantum standards as they mature. This matters because healthcare records must remain protected for decades.

Seald Healthcare uses AES-256-GCM with envelope encryption and integrates through HL7 v2, FHIR R4, X12, Mirth Connect, and SFTP workflows. Identity integrates through SAML, OIDC, and OAuth. The platform aligns with HIPAA requirements, including the encryption safe harbor described under 45 CFR §164.402.

Not the way they are today. When a vendor stores patient data in plaintext, a breach of that vendor exposes every record. With Seald Healthcare, the vendor holds only ciphertext and does not hold the keys, so a breach of their environment reaches data that remains unreadable. Under the HIPAA Breach Notification Rule (45 CFR §164.402), properly encrypted PHI with keys held separately is not considered unsecured PHI. A breach that reaches only encrypted data may not be a reportable breach at all. That can mean no notification campaign, reduced regulatory exposure, and a dramatically different outcome for your organization.

BAAs establish accountability after a breach. They do not prevent one. Seald Healthcare turns data-sharing agreements into cryptographically enforced access controls, so the terms you negotiate are enforced on the data itself. This is where Marlow, your AI security defender, comes in: Marlow analyzes your contracts and BAAs and helps translate them into record-level access policies, enforcing your contracts at the data layer. Access can be restricted by identity, device, location, purpose, and time window, with every access event recorded in a tamper-evident audit trail.

The platform is built for continuity across multiple cloud environments and redundant network paths, engineered for 99.999% reliability. Enterprise deployments can place software and keys in escrow with a trusted third party. Your ability to access patient data does not depend on a single system, a single cloud, or a single vendor.

Seald Healthcare is designed for high availability and targets a four-hour recovery time objective. Key requests typically complete in under 50 milliseconds, faster than the human eye can perceive, so cryptographic operations are imperceptible within healthcare workflows.

No. The architecture is designed so that patient data, keys, and policy enforcement remain logically separated. Enterprise customers can further reduce dependency through escrow arrangements, redundancy, and deployment architecture tailored to their environment.