Security

Identifiable patient fields are encrypted with AES-256-GCM in the application before they are written to the database, so the stored value is ciphertext rather than readable text. This covers patient name, date of birth, phone, email, mailing and street address, Medicare Beneficiary Identifier, insurance member ID, insurance policy-holder identity, and the full body of every submitted clinical and enrollment form.

AES-256-GCM is authenticated encryption: altering stored ciphertext causes decryption to fail rather than silently returning corrupted data. Encryption keys support online rotation, so a key can be replaced without downtime and without leaving older records unreadable.

A small number of operational columns are deliberately stored unencrypted because they must be indexed for exact-match search or telephone dialing — for example the digits used to match an inbound call to a patient. These are individually documented and reviewed rather than left implicit, and they rely on Azure's storage-level encryption as a compensating control.

All browser and API traffic is served over HTTPS/TLS through Azure Front Door. Traffic between the application and its database is encrypted with TLS, and connections to external clinical and insurance systems use TLS with OAuth 2.0 bearer credentials that are never exposed to the browser.

Every user holds one role, and both page access and individual sensitive actions are checked on the server — not merely hidden in the interface. The check runs again on each action, so it cannot be bypassed by calling the underlying endpoint directly.

Authorization is fail-closed. If the permission configuration is missing, malformed, or unreadable, the system denies the action instead of allowing it. High-risk capabilities — exporting patient data, editing vendor credentials, changing security settings — additionally carry a fixed minimum-role floor that configuration cannot widen.

• Role-based access, enforced server-side on every action
• Per-role page visibility, administered and audited
• Fixed minimum-role floor on high-risk actions
• Time-bounded emergency ("break-glass") access, fully logged on grant and revoke
• Periodic review of users and permissions by the accountable owner

Staff sign in through Microsoft Entra ID using OAuth 2.0 with PKCE. QuestConnect does not store staff passwords for federated sign-in. Sessions use signed cookies with both idle and absolute expiry, and administrators can restrict access by IP range.

Access to and modification of patient information is written to an append-only audit log enforced at the database level, retained for six years in line with HIPAA, and suspended from disposal when a legal hold applies. Audit records capture who acted, what they acted on, and when — they do not copy the patient data itself into the log.

Coverage is enforced automatically: an unlogged path that touches patient data fails the build rather than shipping silently.

Every export that can contain patient information passes through a single shared gate. The gate requires a written business justification, re-checks the user's permission, applies a stricter role requirement above a bulk-volume threshold, and records a security event. The justification and the record count are stored; the exported contents are not.

Security-relevant activity — sign-ins, permission denials, patient-data exports, role changes, emergency access — is recorded in a dedicated event ledger with a review queue and reviewer attribution. Incident runbooks and a severity model are documented, and the response process is exercised on a recurring tabletop cadence.

To report a security concern, contact support@questconnect.app with the subject line Security Report. Please include enough detail to reproduce the issue, and do not include patient information in your report.

Changes reach production only through version control and an automated pipeline with blocking checks: authorization invariants on every server action and API route, automated scanning for committed secrets and for patient data in logs, dependency and supply-chain vulnerability scanning, and a database-migration safety gate that refuses to ship code ahead of the schema it depends on. A failing check blocks the deploy.

QuestConnect operates as a HIPAA Business Associate and maintains a SOC 2 readiness program mapped to the Trust Services Criteria, with per-control evidence and an explicit, published list of what is not yet complete.

QuestConnect is not currently SOC 2 certified. Readiness work and a completed audit are different things, and we do not describe one as the other. Vendors that may handle patient information are covered by Business Associate Agreements.

Dexcom data sharing is opt-in. Patients authenticate directly with Dexcom through Dexcom's OAuth 2.0 authorization flow before QuestConnect can request any data. QuestConnect never receives or stores Dexcom usernames or passwords, and a patient can revoke the authorization at any time through their Dexcom account permissions.

Dexcom tokens are stored server-side, encrypted at rest, and are never placed in the browser, on a mobile device, in a URL, or in application logs. Both access and refresh tokens are covered by the same key-rotation process as patient data.

QuestConnect retrieves only the data needed to support remote patient monitoring workflow: retrospective glucose review, trend review, care coordination, documentation, and billing readiness.

QuestConnect has applied for Dexcom production credentials. Until Dexcom separately approves production access, QuestConnect's Dexcom developer access remains sandbox-only. Sandbox data is simulated and contains no real patient information.

• Product Name: Dexcom API
• UDI / Device Identifier: 00386270000668
• UDI / Production Identifier: Version 3.18.0.0
• Date of Manufacture (DOM): 2026-04-23
• Part Number (PN): 350-0019

Dexcom states that the Dexcom API is developed under Dexcom's quality management system. Independent verification of Dexcom's compliance controls is available through Dexcom's FDA Registration and Listing entry.