Skip to content
zMed
Launch in your Hospital

Security & Compliance

Built for regulated healthcare. By design, not by patch.

Hospitals run on trust. zMed's security posture is a property of the platform — the same controls in every deployment, every unit, every country.

By Design

HIPAA GDPR HL7 FHIR ABDM

Certification Pathway

HITRUST SOC 2 Type II FedRAMP

Audit Workflows Supported

JCI NABH TJC ACHC

"By Design" denotes platform architecture; "Certification Pathway" denotes programmes in progress; "Audit Workflows Supported" denotes accreditation regimes the platform produces evidence for. Use of any mark denotes platform support, not certification, unless separately stated.

Where your data lives

On-premises: what stays inside, and the only way anything leaves.

YOUR HOSPITAL BOUNDARY PHI lives here — on-premises or sovereign in-country cloud, your choice Bedside devices monitors · ventilators · pumps no patient identity on devices Clinical teams role-scoped access personal sign-in unit · role · shift scoping One clinical record encrypted in transit (TLS) role-scoped reads each entry carries its author and time scores & alerts computed here, inside the boundary Your HIS LIS · RIS standard interfaces, inside the boundary AI OPT-IN + MASKING off until the hospital opts in Cloud AI (optional) masking per AI Addendum never used to train models THE ONLY OUTBOUND PATH fully on-premises AI removes even this

In an on-premises deployment, bedside devices, the clinical record, your hospital systems and your clinical teams all operate inside the hospital boundary. The only path that crosses it is the optional cloud-AI call, which stays off until the hospital opts in under the AI Addendum; the Addendum lists the AI features that mask direct identifiers before a request is sent. Patient data is never used to train AI models. Choose on-premises AI and even that path disappears. Hospitals that sign up online use the hosted service, which keeps data on servers in India.

Controls

What your IT and compliance teams will ask. Answered.

Role-based access, everywhere

Every screen, every action and every report is scoped by role, unit and shift. A nurse, an intensivist and a billing clerk see different systems on the same record.

Audit and access logging

Clinical records store who made each entry and when. The platform-wide trail of who viewed or changed a record — including any access by zMed staff — is being restored on a log store kept separate from the clinical database, with 180-day retention. Until it is live we do not offer it as an audit artefact.

Encryption in transit

Traffic between browsers, devices and the platform is encrypted with TLS. Encryption of stored data, and of traffic inside the hosted environment, is being put in place; Annex 2 of the Data Processing Agreement states which measures are in place today and which are not.

AI is off until you switch it on

For hospitals that sign up online, AI features are off. A hospital switches them on by accepting the AI Addendum, which names the AI providers and the features that mask direct identifiers before a request is sent. AI models can also run on the hospital's own infrastructure. Patient data is never used to train AI models.

Where your data is kept

The hosted service for hospitals that sign up online stores data on servers in India. Larger deployments can run on-premises or in an in-country cloud the hospital chooses.

Advisory-only intelligence

The platform makes no diagnosis, prescribes no medication, orders no procedure and discharges no patient. Every output is a recommendation a clinician reviews — the chain of clinical responsibility is preserved at every step.

Deployment topologies — on-premises, sovereign cloud, hybrid and the edge appliance — are covered in detail here →

Audit readiness

The inspector reads from the system, not from someone's email.

Accreditation audits, statutory inspections and payer reviews all draw from the same canonical record — every figure in every report traceable back to the chart entry that produced it, every register serially numbered.

Operations

Availability and the parties involved.

Availability & continuity

Service levels are committed contractually per deployment. The architecture is built for the outage you will eventually have: in hybrid deployments the bedside chart keeps running against a per-unit edge appliance for 24+ hours offline, then syncs and reconciles automatically. Planned maintenance is scheduled with the hospital, never sprung on a shift.

Sub-processors

Fully on-premises deployments involve no sub-processors for clinical data. Where a deployment opts into cloud services (hosting, SMS and e-mail delivery, payments, optional AI features), the current sub-processor list — with role, region and data category for each — is provided during evaluation and maintained as part of your agreement, with notice before any change.

Put your security questions to us