Platform

One infrastructure layer
for clinical data and AI.

Connect once. Govern centrally. Run clinical and research applications on infrastructure you control.

Data path

How data gets into Nexus, and what happens to it.

Ingest to store · illustrative

Models in the platform

Language models are a platform service, not an application's private dependency.

An application does not hold its own model or reach out to one. It asks the platform, and the platform decides which pinned version answers, on which machine, with which data — under the scopes that application was already approved for.

A model sees only what the application may see

Inference runs on the same pseudonymized, scope-checked view the calling application was approved for. A model is not a way around the access rules.

Architected

Every inference is recorded

Which model, at which pinned version, on what it was given, and what it produced — in the same ledger as every other access.

Architected

Output is a draft until a person accepts it

Nothing a model produces reaches a hospital system on its own authority. The platform's write-back approval applies to model output exactly as it applies to anything else.

Approval path working

Free text is treated as containing patient data and is a separate grant, because de-identification of dictated text is not yet good enough to assume otherwise.

Principles

Six commitments the architecture enforces.

Ingest

HL7 v2 over MLLP into a vendor adapter, with everything site-specific held in one declarative configuration file rather than in adapter code. FHIR REST and DICOM interfaces follow the same adapter model.

Working · Synthetic data

Master patient matching

Deterministic rules first. An uncertain match goes to a review queue and is never merged automatically — a wrong merge is far more expensive than a deferred one.

Working · Synthetic data

Normalization and coding

The source code is always kept. LOINC and SNOMED mappings carry provenance, units are converted to UCUM, and quality flags travel with the record rather than being silently corrected.

Working · Synthetic data

FHIR R4 clinical store

An open-standard clinical store with platform metadata carried as an extension. If a hospital ever leaves, its data is already in a standard format on its own storage.

Working · Synthetic data

Governance and application scopes

An application declares the resources it needs. The hospital approves them once. Every request is checked against that approval, and a refusal is written to the ledger.

Working · Synthetic data

Aggregate-only access

Some applications are approved for counts rather than records. Grouped results are pruned inside the query engine before they leave it, so the application receives an already-reduced grid.

Working · Synthetic data

Compute allocation

Place workloads across the machines a site actually has, with the site choosing whether placement is automatic, proposed for approval, or set by its own rules.

Architected

Third-party applications

SDK-native or standards-bridged, both under the same scopes, isolation and audit trail. Bridges are built per standard rather than per vendor.

Architected

Deployment

Bare metal, virtualization, Kubernetes, OpenShift, research HPC, or a customer-controlled sovereign tenancy. Not every interface listed on this page is available on every target today.

Architected

Audit ledger

A hash-chained core with a validated clinical event catalogue on top. Applications never write it — the platform does, from what they return — and the chain can be verified independently.

Working · Synthetic data

Models and runtime

Models run on your hardware. Nothing is sent out of your building.

The runtime layer holds the model catalogue: what is installed, at which version, under whose licence, and which applications may call it. Every model is version-pinned and recorded, and any of them can be swapped.

Included in the signed bundle

Apache 2.0 or MIT only — models that need no negotiated contract. No separate licence, no separate fee, version-pinned, delivered in the signed update bundle and run on your hardware.

Architected

PurposeModels

General drafting and structuring

Gemma 4 (2B–31B), Qwen3.6, gpt-oss-20b, Phi-4

Indian and regional languages

Sarvam-30B, IndicTrans2

Speech to text

Whisper large-v3-turbo, IndicConformer — a draft transcript, reviewed by your staff

Search over records and literature

BGE-M3 and its reranker, Qwen3-Embedding, MedCPT

Reading clinical text

GLiNER-biomed, medspaCy, scispaCy

Research workspace

ESM2, ESM C, Boltz-2, Chai-1

Gemma 4 is the default general model. It became Apache 2.0 in April 2026, and that licence change is the only reason it can be shipped at all — which is how every model on this list is chosen.

Under your own licence

Models we support but do not ship. You hold the licence; we integrate them against your intended use, and we confirm what a given licence allows before anything is installed.

Architected

Medical language models -MedGemma and Google's health models, Med42, OpenBioLLM, Meditron.
Pathology and imaging
foundation models -Research workspace only — every strong one is non-commercial or closed, and we will not pretend otherwise.
Vendor models -That come with your NVIDIA or cloud agreements.
Any cleared third-party product -Hosted under the same controls as everything else.

ItemDetailsStatus

Bring your own weights.

A model your own team trained runs through the same manifest, scopes, isolation and audit path as any vendor's

Architected

Version pinning

Every model is pinned and recorded in the ledger alongside what it produced, and any of them can be swapped

Architected

Signed update bundles.

Containers, weights and manifests are signed, verified on the appliance, staged, and activated only after a person at your site approves

Architected

Air-gapped installs.

The same signed bundle path over removable media, with no outbound connection at all

Architected

Outbound-only management.

We never hold an inbound route into a hospital network

Architected

Architecture

Four layers of software. Your infrastructure underneath.

Nexus allocates and provisions workloads across the machines a site already owns — against the requester's role and the access their organization approved. The moat is the software, not the device.

Governance

Who can see what · what ran · what users did · one audit ledger

NEXUS

Applications and models

Care gapQualityEvidenceResearchThird-party AIOpen-weight LLMsSpeech to textSearch and embeddings

Bring your own weights

Model catalogue

VENDORS

Data platform

Integration · patient matching · cleansing · FHIR R4 · pseudonymized views

NEXUS

The planner is the product

Placement itself is a solved problem and Nexus does not re-solve it. What only Nexus can do is read the hospital's own theatre and endoscopy lists, so capacity is ready before a list starts.

Architected

Three modes, one difference

In automatic mode the plan goes straight to the scheduler. In guided mode an administrator approves it first. In manual mode the administrator pins workloads and sets quotas, and the planner reports conflicts.

Architected

Provisioned against role and access

A request carries who is asking and what their organization approved. A researcher's workspace, a quality report and a clinical workload are not the same request and are not placed on the same terms.

Architected

Models in the platform

One hub, many sites.

A hospital group or regional network runs a hub with the full compute pool, the governance console and the application catalogue, with spoke sites that either capture and display only, or hold enough local compute to keep working through a link failure.

Hub

Full compute pool, every application, the governance console, and the group's shared catalogue.

Architected

Thin spoke

Capture and display only. All inference runs at the hub.

Architected

Edge spoke

Local compute for the latency-sensitive work, syncing to the hub, and able to survive a link failure.

Architected

What this costs to run

The architecture is the easy half.

The diagram above is the shape any competent team would draw. What makes a clinical data platform expensive is not designing it once — it is carrying it, per vendor, per market, per site, for as long as the hospital runs.

PER VENDOR, PER VERSION

One adapter for each HIS, LIS and PACS product — and another each time a vendor ships a release that moves a field. Site-specific mapping stays in configuration, so the adapter itself survives the next hospital.

PER MARKET

Terminology and ontology licensing differs by country, and so does what a national licence covers. Patient matching has to hold against transliterated names, not only Latin ones.

PER APPLICATION, PER SITE

A validation run on that hospital's own cases before anything reaches a clinician, and an approval trail a tender can be walked through years later.

Building it once is a project.

Keeping it current is the product.

Availability

If the platform stops, your teams work as they did before it.

A single-host deployment includes a manual fallback for clinical work. Standby and clustered shapes are designed and not built — but the rules that make them possible apply now: services hold no state, the ledger has exactly one writer, and every consumer is idempotent.

ItemDetailStatus

Single node

One host. Manual fallback for clinical work, restore from backup