Clinical purpose
Connect interpretation, encounter documentation, and supported follow-up workflows to the clinical record without requiring duplicate entry.
Developer documentation
Opalite Health EHR Integration
A standards-based connection between Opalite and the clinical record, designed for secure chart context, clinician-reviewed documentation, and auditable delivery.
FHIR R4SMART on FHIROAuth 2.0Customer authorized
Application owner: Opalite Health, Inc. · Last updated August 2026
Integration at a glance.
Opalite requests access according to the workflow a customer enables. Availability varies by EHR, API version, and organization configuration.
Authorization model
SMART on FHIR and OAuth 2.0 are used where supported. Each healthcare organization controls whether Opalite can connect and which permissions it receives.
Deployment model
Opalite connects to each customer environment using organization-approved credentials and configuration. There is no shared clinical data tenant across customers.
Requested data access
The application uses a system-facing, confidential client for supported backend workflows. Customer approval remains required before production access.
| Clinical category | Access | Purpose |
|---|---|---|
| Patients and demographics | Read, search | Identify the correct patient and display relevant demographic context. |
| Appointments and encounters | Read, search | Associate an Opalite session and its documentation with the correct visit. |
| Practitioners, organizations, and locations | Read, search | Route clinical workflows to the correct clinician, facility, and organization. |
| Clinical notes and document references | Read, search, create, update | Retrieve encounter documentation and deliver clinician-reviewed notes and interpretation records. |
| Conditions and assessments | Read, search, create, update | Read the active clinical context and support explicitly approved assessment workflows. |
| Allergies, immunizations, medications, and observations | Read, search | Provide relevant chart context during documentation and clinical review. |
| Orders, results, procedures, and family history | Read, search | Surface existing clinical context without placing or modifying structured orders. |
| Communications and messages | Read, search, create, update | Support authorized telephone encounter and care-team communication workflows. |
| Care plans, care teams, goals, and consent | Read, search | Give clinicians longitudinal care context while documenting the active encounter. |
| Questionnaires and responses | Read, search, create | Use patient-entered history in the note and return supported, clinician-approved responses. |
| Caregivers and authorized proxies | Read, search | Represent relevant family, caregiver, and proxy context in supported workflows. |
| Provenance and audit context | Read, search, create | Preserve source and authorship context for supported clinical documentation exchanges. |
Guardrails around every chart write.
Access to a write-capable API does not mean every workflow can write. Opalite applies server-side policy, clinician approval, patient matching, and outcome verification before reporting success.
- Write operations are limited to workflows enabled by the healthcare organization.
- Clinicians review generated documentation before it is sent to the chart.
- Patient and encounter identifiers are validated before a write is attempted.
- Opalite records the requested operation, outcome, and verification state for auditability.
- Unknown or unverified write outcomes fail closed and are read back before retry.
- Opalite does not place or modify structured medication, laboratory, or referral orders through this integration.
Connection lifecycle
Every implementation is scoped to the customer and follows the controls of that customer’s EHR environment.
Customer authorization
The healthcare organization approves the application and requested access for its environment.
Secure exchange
Opalite uses customer-scoped authentication to read the minimum context needed for the active workflow.
Reviewed delivery
Approved documentation is written to the selected chart and verified against the resulting EHR state.
Machine-readable endpoints
Public signing keys for EHR authentication.
Epic retrieves these JSON Web Key Sets to verify Opalite's SMART Backend Services client assertions. Nonproduction and production use separate signing keys.
Epic sandbox JWKSEpic production JWKS
Only public verification keys are exposed. Private signing keys remain in Opalite's managed secret store.
Security and support
Built for regulated healthcare environments.
Opalite maintains healthcare-focused security controls, signs a Business Associate Agreement with covered-entity customers, and supports customer security and implementation reviews.