AEVRUS is being built so that patients can bring a reconciled record to your institution, each fact traced to its source and disagreements between sources shown. It is in development, has been demonstrated only on synthetic test data, and does not accept real patient records yet.
AEVRUS is being built to bring together the records a new patient brings and reconcile them: each fact traced to its source, duplicates combined, and disagreements between sources shown rather than hidden. Today it retrieves some record types from vendor test environments. It has not been timed or evaluated in clinical use.
Planned measures, not yet evaluated: readmission rates, medication reconciliation accuracy, prior-authorization turnaround and quality-metric reporting, each relevant to MACRA, MIPS and commercial value-based contracts.
Planned, and not built today: patients who consent would contribute de-identified observations that research teams could query. No research data set exists.
AEVRUS is designed to sit above your existing EHR, not in place of it. Its EHR connections today are read-only FHIR R4 registrations in vendor test environments, using SMART on FHIR. It writes nothing back to any EHR. No rip-and-replace.
AEVRUS is in development and runs on synthetic test data only. It has no SOC 2 report and no SOC 2 audit under way, it does not offer Business Associate Agreements, and it has not been assessed for HIPAA compliance. Encryption: documents uploaded to the vault are encrypted with AES-256-GCM, each under its own key; other records are stored in the AEVRUS database without per-record encryption; connections use TLS. AEVRUS holds keys that can decrypt what it stores. Post-quantum encryption is not implemented. Clinician reads made through the AEVRUS portal are recorded in an access log the patient can view. The access log has no cryptographic protection: an administrator with direct database access could alter it, and access made directly to the database does not appear in it. Hosting: AWS us-east-2.
AEVRUS holds no real patient data. Patients grant and withdraw access to their records. Clinician reads made through the AEVRUS portal are recorded in an access log the patient can view. The access log has no cryptographic protection: an administrator with direct database access could alter it, and access made directly to the database does not appear in it. AEVRUS holds keys that can decrypt what it stores. AEVRUS does not sell patient data.
AEVRUS should be evaluated as an early-stage system: it holds no real patient data and has had no third-party security assessment.
AEVRUS is designed as a layer above your existing EHR, with no rip-and-replace and no data migration away from Epic, Oracle Health or athenahealth. Its connections today are read-only FHIR R4 patient-access registrations in vendor test environments, using SMART on FHIR. It writes nothing back to any EHR.
AEVRUS retrieves records through FHIR R4 patient-access interfaces and reads uploaded documents, keeping each fact traced to its source. Some record types are retrieved today; others are not yet stored.
Planned, and not built today: a reconciled view inside your EHR’s encounter screen. Today AEVRUS writes nothing to any EHR, and clinicians use AEVRUS’s own pages.
AEVRUS offers no Business Associate Agreement and accepts no real patient data. Access to records is by patient grant through authenticated sessions, and AEVRUS holds keys that can decrypt what it stores.
Questions about FHIR integration can go through the briefing request below
No pilot partnership is open, and AEVRUS does not accept real patient data.
A 30-minute walkthrough with the founding physician: the current architecture, what has been demonstrated on synthetic data, and what remains before any real data is accepted.
For CMIO, CIO, CFO, CMO, Compliance, or General Counsel.