The Provider pillar of the Three Pillars framework. A clinician-facing portal, currently in active development, that will surface the patient context your EHR doesn’t capture: out-of-network labs, medication and supplement lists, longitudinal vitals, and dietary adherence. Designed to run on-premises or inside your VPC, so protected health information never leaves your perimeter. The underlying PHI de-identification pipeline is already running in production; the clinician-facing surface is being engineered now. Early-access design partners are being accepted.
NexGenHealth.io is organized around three interconnected audiences bound by a single commitment: non-invasive monitoring, evidence-led care, and patient-owned data. Each pillar has a distinct role. Together they describe how NexGenHealth.io is designed to operate — research informs the clinical tools a provider uses, patients retain ownership of their data at every step, and patient-shared context becomes clinical signal. Some pieces are shipped today; others are in active development — see each pillar card below.
Scientists developing non-invasive monitoring technologies, AI-driven nutrition research, and chronic-disease prevention protocols. NexGenHealth.io is building a coalition of providers and patients to pilot and validate non-invasive approaches.
The Provider Portal is in active development. Once shipped, clinicians will be able to receive patient-shared context their EHR doesn’t capture — out-of-network labs, supplement lists, longitudinal vitals, dietary adherence — on architecture designed to run on-premises or inside your VPC. The underlying PHI de-identification pipeline is already running in production; the clinician-facing surface is being engineered now.
Health-engaged consumers who track vitals and labs in a consumer portal, generate meal plans from a large recipe database with dietary and allergen filters, and choose — on their own terms — what context to share with their clinicians.
Eight clinician-first tools, each engineered so that patient data never leaves your environment. Local model inference, on-prem de-identification, and consent-gated data exchange with the patient portal — by default, not by configuration.
One canvas for every linked patient — vitals, wearable streams, labs, medication adherence, meal logs, and condition history — with a 30-day rolling view and anomaly flags surfaced automatically.
Ask questions grounded in a specific patient’s record — no cloud round-trip, no third-party inference. Built on self-hosted Llama / Mistral backbones so PHI never leaves the deployment perimeter.
Patient-uploaded labs, imaging reports, and visit summaries are de-identified on-ingest, extracted to 40+ structured biomarkers, and delivered to the chart before the appointment starts.
Long-run trend views for glycemic control, lipid panels, blood pressure, weight, and HRV. Compare the last 12 months against guideline targets without exporting a single row to a spreadsheet.
Draft personalized care plans with AI assistance, then push the finalized plan directly into the patient’s portal — meals, cardio targets, supplement guidance, and follow-up cadence. The patient sees exactly what you authored.
End-to-end encrypted messaging inside the portal. Attach lab interpretations, diet revisions, or educational content — the patient receives them in-app, not in a plaintext email.
Summarize a year of records into a pre-visit brief — all processed on-box. No chart content is transmitted to external LLM providers; no BAA gymnastics with third-party cloud AI vendors required.
Every read, write, export, and AI inference is logged with a traceable request ID. Generate auditor-ready evidence bundles on demand. BAA-ready posture from day one; Row-Level Security enforced on every table.
Cloud LLMs trade latency and lock-in for convenience. In a clinical setting, that trade becomes unworkable: every prompt containing PHI requires a BAA with the inference provider, a minimum-necessary review, and an audit boundary most organizations don’t have the staff to operate. The Provider Portal solves this by default — by running inference inside your perimeter instead of negotiating it out of one.
Your GPU. Your model. Your perimeter.
Self-hosted Llama 3, Mistral, Qwen, or Phi-3 on your infrastructure — dedicated GPU, inference servers (vLLM / TGI / Ollama), and managed upgrades. No chart content, no patient identifiers, and no queries ever transit a third-party inference endpoint. BAAs become internal documents, not vendor negotiations.
Scrub before you think.
Stanford-AIMI NER runs locally on ingest — names, addresses, MRNs, account numbers, and other direct identifiers are redacted before the content reaches any downstream model. Dates are normalized through an internal offset algorithm so longitudinal trends remain analyzable without exposing real calendar dates.
Retrieve without leaking.
Self-hosted embedding models (mxbai-embed-large-v1, 1024-dim) and pgvector on your Postgres build a private retrieval layer over your practice’s chart notes, care protocols, and published guidelines. The Clinical Assistant grounds every answer in sources you can point to — yours, not a third-party vendor’s.
Know what your model knows.
Every deployed model ships with a held-out evaluation harness and published precision / recall / F1. Drift is monitored weekly; re-eval is a one-command operation. No black-box — your team can re-run the eval before any production promotion.
Sharing is a decision, not a default.
Patients explicitly grant per-field, time-boxed, revocable consent on what flows from their portal into yours — labs, vitals, wearables, meal logs, condition history. Providers see a clear manifest of what they have access to, for how long, and under what scope. Revocation propagates to cache in seconds.
Care plans in. Vitals out.
Flow runs both ways: patients stream labs and wearable data into your chart; you push finalized care plans, meal recommendations, and medication guidance back to the patient’s portal. The patient sees what you authored; you see how they responded.
Share what matters. Nothing else.
§164.502(b) is enforced in code. A provider’s view of a patient is filtered to the minimum-necessary dataset for the clinical purpose — diabetologist sees glycemic and metabolic data; psychiatrist sees mood, sleep, and medication adherence; PCP sees the longitudinal summary. No fishing expeditions.
A consent-gated, bi-directional channel with local inference in the middle. The patient controls what flows; the provider gets clinically-actionable context; the infrastructure keeps PHI inside the perimeter on both sides.
The patient’s control plane. They log vitals, upload labs, log meals, and track conditions. Direct wearable streaming (Apple Health, Oura, Whoop, Garmin, Dexcom via webhooks and API) is on the roadmap. They decide what is shared, with whom, and for how long.
The clinician’s workspace. Aggregated patient context, local-AI summaries, care-plan co-authoring — all rendered without a single byte of PHI leaving the deployment perimeter.
The architectural difference between an LLM call that stays inside your perimeter and one that leaves for a third-party endpoint is the compliance difference between an internal process and a BAA-bound disclosure. Here is what changes at each layer.
| Dimension | Third-Party Cloud AI | NGH Local AI (on-prem / VPC) |
|---|---|---|
| PHI Egress | Every prompt leaves your perimeter | Zero egress — inference stays on-box |
| BAA Burden | Required per inference vendor; renegotiated per model change | Internal policy — no external BAA chain |
| Audit Boundary | Shared with provider; logs split across vendors | Single, unified audit plane you control |
| Model Drift Control | Vendor pushes silent updates; behavior shifts mid-eval | Pinned versions; drift detected in-house |
| Latency | Internet round-trip per token | Sub-100ms on dedicated GPU |
| Data Residency | Vendor-defined region; opaque sub-processors | Wherever your server is |
| Cost Profile | Per-token OPEX; scales linearly with usage | Fixed CAPEX on GPU; marginal cost near zero |
| Training-Data Exposure | Depends on vendor opt-out settings and enforcement | Your data never trains anyone’s model |
Compliance primitives are shipped with the platform, not bolted on. The same architecture that runs our patient pipeline in production is what the provider portal inherits — with additional clinician-facing controls layered on top.
Uploaded records pass through the de-identification pipeline before they reach any downstream model or storage layer. Names, addresses, MRNs, account numbers, and other direct identifiers are redacted; dates are normalized through an internal offset algorithm so longitudinal trends stay intact without exposing real calendar dates.
TLS 1.2+ only, non-root service accounts, authenticated Redis, UFW-hardened firewalls, fail2ban, LUKS-encrypted vaults. Every API and UI route is JWT-authenticated and Row-Level-Security-enforced.
Role-based access control with an audited emergency-access path for urgent clinical situations, reviewed automatically after every use. Audit logs are immutable and retained for the OCR-recommended six years. Evidence bundles can be exported on demand for external audit.
Role-based and specialty-based data filtering is enforced in code, not policy. A specialist never sees data outside their clinical scope unless the patient has explicitly granted it.
Because inference is local, the BAA chain for AI processing stops at your perimeter. For cloud-adjacent components (edge hosting, managed database) we sign Business Associate Agreements and pass them through to your compliance officer.
Architecture diagrams, API map, environment matrix, port map, threat model, alerts — every service ships with the documentation we use internally. If an auditor asks for it, we hand over the same binder we use to operate it.
Early-access design partnerships are being accepted now. General availability follows a staged rollout after the local-AI inference stack and consent layer complete internal validation and external audit. If you want a more specific timeline for your practice, contact us and we’ll talk through the current milestone plan honestly.
No. By default, all clinical inference runs on locally-hosted models (Llama, Mistral, Qwen, Phi) on your infrastructure — no prompt ever transits a third-party inference endpoint. If you later choose to enable cloud-LLM features for non-PHI workloads, BAAs are in place for the vendors we support.
Three: fully-hosted by NGH in a single-tenant VPC (we sign the BAA, you operate the clinical workflow); self-hosted inside your own cloud account (you sign no BAA for inference, because it stays inside your account); or fully on-prem in a customer data center for environments with hard data-residency requirements. All three share the same codebase.
Inside their patient portal, a patient generates a Provider Link code, enters your NPI, and grants per-category consent — labs, vitals, wearables, meal logs, condition history — each with a time-boxed scope. You see a clear manifest of what you have access to and for how long. The patient can revoke any category at any time; revocation propagates to your cache within seconds.
FHIR R4 export/import is planned for GA. SMART-on-FHIR embed is on the roadmap so the portal can appear as a tab inside your existing EHR (Epic, Cerner, athenahealth, etc.). An HL7 v2 bridge handles legacy systems that haven’t completed FHIR migration.
Every PHI read, write, export, message, and AI inference is logged with a traceable request ID to an immutable audit log. Your Privacy Officer can export evidence bundles on demand for HIPAA audits, SOC 2 Type II assessments, or internal quarterly review. If a clinician needs to use the emergency-access path to view a record outside their normal permissions, the system automatically notifies the compliance officer and queues the event for post-incident review.
The patient’s portal shows exactly what you have access to at all times and includes a one-tap revocation control. Revocation propagates to your cache within seconds — your dashboard updates in real time. Data that was already included in a saved chart note remains under your clinical record-keeping obligations; new data simply stops flowing.
Use the Join Early Access button below. We’ll schedule a 30-minute call, walk through your practice’s clinical workflow and compliance posture, and — if it’s a fit — slot you into a design-partner cohort with priority input on the clinician-facing UI.
Early-access design partners get priority input on the clinician-facing workflow, dedicated engineering-to-clinician communication, and the first production deployments. No commitment, no pricing pressure — just an honest conversation about what you need.