Security Overview

Security at Orvie is layered. No single control is trusted on its own: authentication, authorisation, audit and transport protection are designed to catch different failures. This page is a public summary. It deliberately omits configuration detail that would help an attacker, and it does not describe vulnerabilities that have not been fixed.

The workspace holds health data, which the UU PDP treats as specific personal data. That raises the standard we hold ourselves to, and it is why several controls below are stricter for administrators than for patients.

No system is perfectly secure. We would rather hear about a weakness from you than discover it after an incident; the reporting route is at the end of this page.

Verified accounts

An account is created as unverified and cannot sign in until the email address is confirmed with a six-digit code. Doctor accounts then wait for administrator approval before they can sign in. A rejected or suspended account is refused on the next request, not only at the next sign-in.

Passwords and one-time codes

• Passwords are hashed with bcrypt at cost 12. We never store or display the plain password.
• One-time codes are six digits, valid for 10 minutes, allow five attempts, are single-use, and are stored only as a SHA-256 hash bound to a server secret.
• Issuing a new code invalidates the previous unused code for the same address and purpose.
• Sign-in, code issuance and password reset are rate limited.

Second factor for administrators

Administrator accounts require a single-use code sent to the account email at every sign-in, in addition to the password. Invited administrators must also replace their initial password before they reach the workspace. We recommend that every clinician protects the email account they use for work with a strong, unique password and a second factor offered by their email provider.

Role-scoped access

• Authorisation is enforced on the server. Hiding a button is never the control.
• A doctor can open a patient chart only where there is an appointment or a record connecting that doctor to that patient.
• Hospital administrators are bound to their own organisation. Orvie administrators are bound to the staff domain and to their tier; only a super administrator can create another administrator.
• Administrators do not see clinical notes, and one hospital cannot see another hospital’s accounts.
• Demo sessions are read-only. Public demos use seeded sample data, not real patient records.

Sessions

Sessions are signed tokens with an eight-hour lifetime. Cookies are HttpOnly, SameSite=Lax and Secure when the site is served over HTTPS. The server re-reads the account status on each request, so a suspension takes effect without waiting for the token to expire.

In production, the workspace is served over HTTPS. Plain HTTP is used only for local development and private-network testing; it is not the production configuration. Session and CSRF cookies are marked Secure whenever HTTPS is in use, and Auth.js adds the __Secure- and __Host- name prefixes.

The application also sends the following response headers:

• Content-Security-Policy restricting scripts, styles, frames, objects and connections to the application’s own origin;
• X-Frame-Options: DENY and frame-ancestors 'none', so the workspace cannot be embedded in another site;
• X-Content-Type-Options: nosniff;
• Referrer-Policy: strict-origin-when-cross-origin;
• Permissions-Policy disabling camera, microphone and geolocation for the application itself.

Fonts, icons and scripts are served from our own domain. We do not load third-party analytics, advertising or tag-management scripts, which removes a common supply-chain path into a clinical page.

The application writes an audit event when an account is created or verified, when someone signs in, when an administrator approves or changes an account, when a clinical record, appointment, prescription, order or laboratory result changes, and when a doctor opens a patient chart. Each event records the actor, action, affected record, IP address, user agent and time.

Audit entries are not editable through the product. Access to the audit view is limited by administrator tier, and the retention period is aligned with the medical-record retention period described in the Privacy Notice. Audit logs support incident investigation and the accountability requirement in Articles 31 and 35–39 of the UU PDP.

We do not claim that every read of every record is audited. The events above are the ones the current build records; expanding read coverage is an ongoing engineering item.

• Least privilege. Administrator authority is tiered, hospital administrators are scoped to their organisation, and production access is limited to the operators who need it.
• Secrets. Credentials and signing keys live in the deployment environment, not in the source repository or the client bundle. The application refuses to start in production without an authentication secret.
• Backups. The database is backed up on a schedule, and restoration is tested as part of release readiness. Backup access is restricted to operators.
• Rate limiting. Sign-in, code issuance and password-reset paths are rate limited to slow credential guessing and code brute force.
• Dependency and platform maintenance. We keep the framework, database and authentication library on supported releases and review security advisories before deploying.
• Incident response. We maintain a breach runbook and a breach register. If a personal data breach occurs, we notify affected people and the authority within the 3 x 24 hour deadline in Article 46 of the UU PDP; the Privacy Notice explains what that notice contains.
• People. Staff with production access work under confidentiality obligations and receive access only for their role.

We do not hold ISO/IEC 27001 or SOC 2 certification, and we do not claim either. We also do not describe the service as “certified”, “audited” or “compliant” with a standard we have not been assessed against. Claims of that kind should be backed by a certificate and an audit report, and we would rather publish nothing than publish a badge we have not earned.

Our UU PDP work — records of processing, impact assessments, processor agreements, retention and breach response — is documented and reviewed with counsel as part of launch readiness. If we complete an independent security assessment, we will publish its scope and result here.

If you believe you have found a vulnerability, email security@deepvertex.tech. Include a description, the steps to reproduce it, the affected URL or component, and the impact you believe it has. Tell us how to reach you and whether you want to be credited. Do not include real patient data in the report.

Rules for research

• Use your own test accounts. Do not access, modify, download or retain another person’s data.
• Do not run denial-of-service tests, automated high-volume scanning, spam or social engineering against our staff or users.
• Do not test physical security, third-party services or accounts you do not own.
• Stop as soon as you have evidence of a vulnerability, and give us a reasonable opportunity to fix it before public disclosure. We ask for 90 days, or a shorter period we agree in writing.
• If you accidentally access personal data, stop, do not copy it, delete what you received, and tell us immediately.

What you can expect

• We acknowledge a report within three business days.
• We triage it and tell you our assessment within ten business days where we can.
• We fix confirmed issues according to severity and keep you informed of progress.
• We do not currently run a paid bug bounty. We will credit researchers who ask, unless they prefer to remain anonymous.

For good-faith research that follows this policy, we will not pursue legal action or report you to authorities. That assurance covers our own action; it cannot bind third parties or a regulator, and it does not apply to research that harms patients, accesses data beyond the minimum needed to demonstrate a flaw, or breaks the law.

If you are unsure whether a test is in scope, ask first at security@deepvertex.tech.

Security reports and questions: security@deepvertex.tech. Privacy and data protection: privacy@deepvertex.tech. Postal address: DeepVertex Healthcare Technology, Jakarta, Indonesia.

This overview is version 1.0 and was last updated on 22 October 2026. We review it at least annually and whenever a material control changes. It should be read with the Privacy Notice and the Accessibility Statement.