Frequently Asked Questions

Seald Healthcare protects patient data itself, not just the systems around it. PHI remains encrypted at the record level wherever it is reviewed, processed, shared, or stored, and decrypts only at authorized read time under policy for an approved person, device, application, service, or AI agent.

No. TLS protects data while it moves between systems, and at-rest encryption protects storage. Seald Healthcare adds persistent, record-level protection that remains with patient data across applications, vendors, cloud environments, databases, backups, and AI workflows.

Seald Healthcare manages key infrastructure separately from the patient data, but cannot independently decrypt customer PHI. Each data key is protected under key material controlled by your organization, keeping decryption authority separate from the systems storing or transmitting the data.

No. Seald Healthcare complements infrastructure, identity, endpoint, network, TLS, and at-rest security by protecting the patient data itself. Those tools protect systems and access paths. Seald Healthcare protects the patient data itself.

Your organization does. Access is governed by policies that determine who or what may decrypt a record and under what conditions. Policies can account for the user, device, service, workflow, location, time, and other authorized conditions, with access revocable in real time.

Policy Studio, powered by Marlow, Seald Healthcare's proprietary AI, turns BAAs, vendor contracts, and security requirements into proposed access policies. Your organization reviews and approves those policies before Seald Healthcare cryptographically enforces them at the record level on every decryption request.

Yes. Because decryption remains policy-governed, your organization can revoke authorization in real time even after encrypted patient data has been distributed or stored outside your environment. Possession of the ciphertext alone does not provide authority to decrypt it.

No. Seald Healthcare is zero-knowledge by design. We manage the cryptographic infrastructure and policy enforcement required to protect the data, but we cannot independently decrypt customer PHI.

Seald Healthcare supports multiple integration paths depending on how patient data is used. Secure Portal Access gives authorized users browser-based access without requiring a native vendor integration. Native Integration uses Seald Healthcare's API and SDK for applications, vendors, and AI systems that need to process patient data programmatically. Protected Storage keeps databases, archives, backups, cloud storage, and disaster recovery environments encrypted while preserving controlled access for authorized use. Seald Healthcare can also integrate into existing healthcare data flows such as HL7, FHIR, X12, SFTP, integration engines, APIs, and outbound file workflows.

No. Seald Healthcare is designed to deploy alongside your existing healthcare infrastructure. For outbound workflows, it can sit at the egress point where patient data leaves your environment, encrypting PHI before it reaches third parties without replacing your EHR or requiring EHR vendor cooperation.

That depends on the integration model. In many existing data workflows, vendors continue receiving data through the same connection, schedule, and format they use today. The difference is that protected PHI remains ciphertext unless an authorized user, application, service, or workflow is permitted to decrypt it. For human-review workflows, vendors can also access authorized records through Seald Healthcare's secure portal without requiring a native integration.

Integration depends on the workflow and deployment model. Seald Healthcare is designed to secure an initial patient-data workflow in approximately 60 days, with additional integrations using supported healthcare interfaces and existing deployment patterns able to move significantly faster.

Seald Healthcare is designed so that compromising the environment storing the data does not, by itself, provide the authority required to decrypt the protected records. Patient data remains encrypted, and decryption still requires an authorized request that satisfies the active policy.

Yes. Record-level encryption can persist across databases, cloud storage, archives, immutable backups, and disaster recovery environments. Protected records remain encrypted until authorized read time, including during restoration and recovery workflows.

Yes. Applications and AI agents can be treated as authorized services under policy. Seald Healthcare allows approved AI workflows to access the patient records they require while keeping PHI encrypted outside authorized processing contexts.

Seald Healthcare records decryption requests, denials, policy changes, revocations, key operations, and relevant access context in a tamper-evident audit trail. This provides visibility into who or what attempted to access patient data, when, and under what policy conditions.