No institution is asked to send its data anywhere.
NeuSymbol is equipment installed in its own data center. There is no cloud service to assess, no data processor to add to a register, no cross-border transfer to justify and no patient data egress to monitor.
This is equipment, not a data-sharing arrangement
Most institutions already operate a considerable amount of computing that processes patient information without it leaving the premises. Imaging modalities perform reconstruction on dedicated hardware in the scanner room. Picture archiving and communication systems hold the resulting studies. Laboratory analyzers, physiological monitoring platforms and digital pathology scanners each process identifiable clinical data locally, under the institution’s own controls, and have done so for decades without being treated as third-party data processors.
None of them required a third-party data processor assessment, a data transfer agreement, or an egress justification, because none of them send patient information anywhere. They are equipment that runs where the data already is.
NeuSymbol belongs to that established category rather than to the category of cloud analytics services. It is a private clinical computing environment installed in the institution’s own rack, processing institutional data inside the institutional network, governed by the institution’s existing access controls and retention policy. The distinction is not presentational. It determines which review process applies, which contractual terms are required, and which regulatory obligations are engaged.
What the platform therefore requires is an equipment and security review of the kind already conducted for any clinical system placed in the data center. It does not require a data-sharing review, a transfer impact assessment, or the addition of a processor to the institution’s register, for the straightforward reason that no data is shared and no transfer occurs. Institutions that have completed the assessment generally find it a materially shorter exercise than the one they had prepared for.
What this means for the security workload
In practical terms, NeuSymbol is usually the only candidate on an evaluation list that reduces the institution’s audit surface instead of extending it. Every alternative under consideration adds a location in which patient information exists, and therefore adds a party whose security posture must be assessed, monitored and periodically re-assessed for as long as the relationship continues.
| Concern | Cloud-based clinical analytics | NeuSymbol |
|---|---|---|
| New third-party data processor on the register | Required | Not required. No patient information is transferred |
| Data transfer or sharing agreement covering PHI | Required | Not required. Nothing transfers |
| Egress monitoring and annual justification | Ongoing | No patient data egress exists |
| Cross-border transfer assessment (GDPR, EHDS, APPI) | Required, frequently blocking | Not triggered. Processing is local |
| Vendor holds the patient records | Yes | Never. Under any configuration. |
| Breach exposure through the vendor | Records sit in the vendor’s environment | None. Reltronic holds nothing |
| Business continuity dependency on vendor uptime | Yes | No. Operates independently, including fully isolated |
| Encryption key custody | Vendor or shared | Institution |
| Audit scope change | Expands | Contained to one on-premise system |
Exactly what crosses the boundary
Clinical findings go to the institution’s authorized clinical and research staff, inside its own environment, through the systems clinical teams already use.
System telemetry, health, capacity and version information about the equipment itself. No clinical content.
Where an institution has chosen to participate in a collaborative study, statistical summaries only. Never records, never narrative, never identifiers. Participation is opt-in, study by study, and can be declined without affecting anything else the system does.
Patient records, clinical narrative, identifiers and images do not leave the equipment. This is not a configuration option that could be set differently. There is no mode in which it is otherwise.
Security posture
Protects itself physically
The equipment is designed for placement in environments less controlled than a corporate data center. If it detects that it is being tampered with, it protects its contents automatically and the data becomes unreadable. A record of the event is preserved for investigation.
Institutional access controls, not Reltronic’s
The system integrates with existing identity and access management. Reltronic personnel hold no standing access to the institutional environment. Support access is granted by the institution, scoped, time-limited and logged where institutional staff can read it.
Isolated operation supported
Where institutional policy requires it, the platform operates with no outbound connectivity whatsoever. Software and knowledge updates are then applied through a controlled offline process under the institution’s own change management, on its own schedule. This configuration is supported rather than tolerated, and a meaningful proportion of deployments run this way, particularly in defense-adjacent, correctional and government health settings.
Complete activity record
Because the platform is deterministic rather than probabilistic, an audit is reproducible. Replaying a recorded finding against the same data returns the same result, so a security or clinical reviewer verifies rather than takes on trust.
Every action the platform takes is written to a tamper-evident record held within the secure boundary of the appliance, timestamped and cryptographically signed at the point it occurs. The record is available to the institution’s audit and compliance functions without reference to Reltronic, and it survives power loss. Where a governance committee asks why a particular consideration was surfaced for a particular patient two years earlier, the question is answerable from that record.
Encryption throughout
Clinical data is encrypted at rest and in transit throughout its handling within the institution, using algorithms and key lengths the institution’s security team can review against its own standard. Key custody remains with the institution. Reltronic does not hold, escrow or have any means of recovering the keys, which is a deliberate constraint and one that cannot be relaxed by support arrangement.
Coordinated disclosure
Reltronic publishes a vulnerability disclosure policy and responds to reports on a defined timeline. Detailed security architecture, including tamper-response design, is provided to evaluating security teams under mutual non-disclosure. The specifics of those protective measures are not published.
Regulatory alignment
Processing happens entirely inside the institution. That lines up with the requirements that stall most clinical technology projects: HIPAA in the United States, GDPR and the European Health Data Space in Europe, APPI in Japan, and data localization rules elsewhere.
Institutions in restrictive jurisdictions are frequently unable to adopt cloud-based clinical analytics at all. The same deployment works there without modification, because there is no cross-border transfer to authorize.
Reltronic maintains a Trust Center documenting current compliance status, subprocessor information and security certifications, including those in progress.
What an evaluating security team receives
Reltronic completes your standard security questionnaire on request. Under mutual non-disclosure we also provide a network and data flow diagram, the deployment and hardening specification, integration requirements, an access control and support model, incident response commitments, and a subprocessor list.
Reltronic would rather answer a security team’s questions before the commercial conversation than after it. The deployments that fail are consistently the ones where security was consulted last.
Contact: client@reltronic.com