MediQuery

Overview#

Clinicians spend a non-trivial fraction of every shift looking things up. A junior registrar checks the trust's antimicrobial guideline against the latest culture; a consultant pulls the most recent NICE guidance on a borderline presentation; a pharmacist cross-references a new prescription against the patient's renal function and existing medications; a nurse needs the local sepsis pathway in under thirty seconds. Each lookup involves several systems — a knowledge base, an EHR, a drug database, a literature search, the trust's own intranet — and the answer that matters is usually the synthesis across them, not a single citation.

MediQuery is the managed clinical application that consolidates that workflow into one cited answer. The clinician asks a question in plain English; MediQuery retrieves across the trust's configured knowledge sources, brings in the patient's EHR context when the clinician has explicitly opened a patient encounter, and returns a structured answer with inline citations to every source the answer rests on. The intent is not to make the decision — clinicians do that — but to make the evidence behind the decision legible in seconds rather than minutes, and to keep an audit trail of what the clinician saw at the moment they decided.

MediQuery is the most mature application in the Yobitel AI Applications suite and the reference implementation for the suite's design pattern: domain-grounded clinical workflow, verifiable citations on every claim, role-aware presentation, and an explicit clinician-override path. Trust operators configure it through a console; the underlying inference runtime is operated by Yobitel on the customer's behalf, and the customer owns the knowledge base, the EHR connection, the audit trail, and the encryption keys.

Yobitel Communications, the UK-headquartered AI infrastructure company that publishes MediQuery, sells it as a per-clinician-per-month managed subscription. NHS trusts and US health systems are the two largest customer segments today; regulated independent providers and clinical-research teams round out the rest.

Who uses MediQuery#

MediQuery is built for clinical staff first and for the trust operators who run the underlying configuration second. Each persona sees a different surface and is governed by a different RBAC role.

The product's vertical is healthcare: NHS trusts and ICSs in the UK, HIPAA-covered health systems in the US, and EU regulated trusts inside the EU Data Boundary. Independent regulated providers and clinical research institutions round out the customer base. The application is not deployed against general-purpose enterprise knowledge — it is designed against the clinical workflow, with citation, sovereignty, and override paths that an enterprise search product does not carry.

• Consultant — opens a patient context for a complex case, asks for the trust's protocol against the most recent national guidance, reviews cited evidence, records an override note when their judgement diverges.
• Registrar — runs a high volume of routine lookups (formulary, antimicrobial guidance, sepsis pathway, drug-interaction checks) during shift; relies on citation freshness and per-role default surfaces to keep the cognitive load low.
• Nurse — pulls the local sepsis pathway or the trust's escalation criteria at the bedside; sees a focused role-default surface rather than the full literature view a consultant gets.
• Pharmacist — cross-references a new prescription against the patient's renal function, allergies, and existing medications; uses the formulary, BNF, and DrugBank connectors most heavily.
• Trust admin / clinical governance lead — owns the answer-quality dashboard, the override-rate review, and the knowledge-base refresh cadence. Receives flagged-answer reviews and signs off on knowledge-source additions.
• IT and identity counterpart — owns the OIDC federation, the SCIM provisioning, the EHR connector wiring, and the audit-export bucket configuration. Does not see clinical content.

Customer experience walkthrough#

A clinician opens MediQuery from the trust's clinical portal, signed in via the trust's identity provider. The application is branded as the trust's own — the name is whatever the trust chose at deployment, the colour palette is theirs, and Yobitel's brand is not surfaced. A consultant working a complex case opens the patient context (an explicit action recorded in the audit trail) and types a question in plain English: 'patient is on rivaroxaban with eGFR 32, needs a peri-operative bridging plan'.

MediQuery retrieves across the trust's configured knowledge sources — the local peri-operative protocol, the trust's anticoagulation guideline, the relevant NICE guidance, and the BNF entry for rivaroxaban — and brings in the patient's renal function, current medications, and allergies from the EHR via the explicit fields the clinician's role is permitted to read. The returned answer is structured: a recommendation, a list of considerations specific to this patient, and inline citations on every sentence pointing back to the source document, section, and freshness window. An evidence-grade tag appears next to each citation where the source publishes one.

The consultant reviews the cited evidence, accepts the recommendation, and records a one-line clinical note — or, if their judgement diverges, takes the override path with a structured reason. Either way, the question, the answer, every citation shown, the EHR fields read, and the consultant's note are written to the immutable audit trail. The trust admin sees these aggregated in the answer-quality dashboard: citation-coverage trends, override rates, and a ranked list of topics where overrides are spiking and the knowledge base should be refreshed.

Configuration surface#

Trust operators configure MediQuery through a guided console — there is no CLI to install and no manifest to commit. The customer-facing configuration surface covers five areas: the trust identity and sovereignty pin, the knowledge base, the EHR connection, identity and clinical RBAC, and audit and billing settings. The underlying inference and retrieval runtime is operated by Yobitel and is not customer-tunable.

• Trust identity and branding — trust name, sovereignty region (UK NCSC OFFICIAL-SENSITIVE, EU Data Boundary, US HIPAA, air-gapped on-premise), clinician-facing application name, logo, and primary brand colour. Clinicians see the trust's brand, not Yobitel's.
• Knowledge base — the curated set of clinical sources MediQuery retrieves against. Each source carries a name, a class (guideline, formulary, local-protocol, evidence-summary, literature), an ingestion mode (upload, intranet crawl, managed connector), and a refresh cadence. Ingestion is incremental — adding a new guideline does not require a redeploy.
• EHR access scope — protocol (FHIR R4 or HL7v2), endpoint, and the explicit list of clinical fields MediQuery may read when a clinician opens a patient context. EHR access is per-encounter and per-clinician-role; MediQuery does not bulk-export EHR data and does not retain patient context beyond the answer's audit record.
• Clinical RBAC — IdP group IDs mapped onto each clinical role (consultant, registrar, nurse, pharmacist, admin). Role drives default knowledge surface, answer framing, and which EHR fields are accessible.
• Audit and retention — retention window in years (default 7 to meet HIPAA and trust governance), customer-owned object-storage bucket for immutable export, and the customer-managed KMS key the export is encrypted with.
• Billing — tier (standard, premium, air-gapped), per-instance hard monthly USD spend cap that pauses non-essential workflows when reached while clinical-decision flows continue uninterrupted.

Data integrations#

MediQuery integrates with the systems a trust already has: an EHR for patient context, identity for SSO and provisioning, and a set of clinical knowledge sources for retrieval. Connectors are configured in the console and tested against the trust's environment before clinical use.

EHR connectivity is the most consequential integration. MediQuery speaks FHIR R4 for modern EHRs and HL7v2 for legacy estates. In the UK, EMIS Web and TPP SystmOne are the primary primary-care targets; in the secondary-care estate, Epic, Cerner Millennium, and System C are common. In the US, Epic and Cerner Millennium dominate; Meditech, Athenahealth, and Allscripts are also supported where they expose a FHIR R4 endpoint. The connector reads only the explicit fields the trust whitelists per clinical role and never bulk-exports EHR data.

Managed knowledge-source connectors give the trust pre-built, refresh-managed access to common clinical references. The full list available today: NICE, BNF, MHRA, FDA, DrugBank, RxNorm, PubMed, Cochrane, UpToDate, ClinicalKey, and DynaMed. Each connector respects its source's licensing — the trust must hold the relevant subscription where required — and runs on a per-source refresh cadence. Custom intranet content is ingested via direct upload or a managed crawl pointed at the trust's intranet.

Identity and RBAC#

MediQuery federates identity through OIDC against the trust's primary identity provider — tested against Okta, Microsoft Entra ID, NHS Care Identity, and Keycloak. User and group provisioning runs through optional SCIM 2.0; trusts that do not run SCIM can map groups manually through the console. There is no MediQuery-local user database; every authentication round-trips through the trust's IdP.

Clinical RBAC is the second layer. The trust admin maps IdP group IDs onto five clinical roles — consultant, registrar, nurse, pharmacist, admin — and each role carries default knowledge-surface ordering, answer-framing posture, and EHR field access. A registrar querying the antimicrobial guideline sees a different default knowledge ranking than a consultant on a complex case, and a nurse opening a patient context can see the fields a nurse role is authorised to read, not the full record. Ambiguous group memberships (a user in two groups that map to different roles) surface a banner to the clinician and a ticket to the admin until resolved.

Every authentication, every role resolution, every patient-context open, and every EHR field read is recorded in the immutable audit trail with the clinician's identity and the trust's session context. The trust admin can replay any clinical session end-to-end through the audit panel.

Deployment modes#

MediQuery deploys in one of three modes. The clinician-facing experience is identical across all three; the differences are sovereignty, connector availability, and where the runtime physically sits.

• Managed multi-tenant on Yobitel NeoCloud — the default deployment for most NHS trusts and EU health systems. The trust gets an isolated tenant inside a Yobitel-operated sovereignty region (UK NCSC OFFICIAL-SENSITIVE, EU Data Boundary), with NHS Care Identity or the trust's primary IdP for SSO, a FHIR R4 EHR connector, managed knowledge-source connectors enabled per the trust's licensing, and audit export to a trust-owned S3 bucket encrypted with the trust's KMS key. Set-up to first clinical use is typically four to six weeks.
• Dedicated single-tenant on Yobitel NeoCloud — for trusts that require sole-tenant infrastructure for procurement or compliance reasons. Same managed posture, separate underlying capacity, with a per-trust performance and noisy-neighbour guarantee. Most often used by US health systems on HIPAA where the BAA scope mandates sole tenancy.
• Air-gapped on-premise — for regulated trusts and research institutions where no external network egress is permitted. Yobitel deploys the runtime into a customer-owned or Yobitel-operated on-premise enclave; knowledge sources are uploaded directly; the EHR connection is local; audit export writes to an on-premise object store. Connectors that depend on external APIs (PubMed, UpToDate) are replaced with local mirrors maintained by the trust on a quarterly refresh cycle.

Pricing#

MediQuery is priced per-clinician-per-month in USD across three tiers. The headline rates below are indicative for mid-2026; the trust's account team confirms current rates and any multi-year or seat-volume discounts before contract. Pilots run at a reduced rate for 60-90 days on any tier with structured success criteria.

Compliance posture#

MediQuery is built for regulated clinical estates and the compliance posture is treated as a first-class product feature. UK frameworks lead — NCSC Cloud Security Principles, NHS Data Security and Protection Toolkit, NHS DTAC, Cyber Essentials Plus, and the OFFICIAL-SENSITIVE classification align to NHS trust deployments. EU frameworks (GDPR, EU Data Boundary, AI Act high-risk obligations for clinical use) cover EU health-system deployments. US frameworks (HIPAA with BAA, HITRUST alignment where applicable) cover US health-system deployments.

Data residency is enforced at the sovereignty pin. A trust deployed into UK NCSC OFFICIAL-SENSITIVE never sees its PHI or audit trail spill into an EU or US region, regardless of capacity or price. PHI is encrypted at rest with AES-256, in transit with TLS 1.3, and at the application boundary with customer-managed KMS keys. The audit trail is immutable, exportable to customer-owned object storage, and retained for the trust's configured window (default seven years).

• NCSC Cloud Security Principles — controls mapped per principle for UK NCSC OFFICIAL-SENSITIVE deployments.
• NHS DTAC and NHS Data Security and Protection Toolkit — alignment evidence available under NDA.
• G-Cloud — listed under Cloud Software and Cloud Support; orderable through the Crown Commercial Service framework.
• Cyber Essentials Plus — current certificate.
• GDPR / UK DPA 2018 — DPA, sub-processor list, EU SCCs available; data residency enforced at admission.
• EU AI Act — high-risk clinical-decision-support obligations met by default; explainability through the citation surface, audit trail, and clinician override path.
• HIPAA — BAA available; PHI encryption, access logging, and audit retention meet covered-entity expectations.
• SOC 2 Type II — annual third-party audit covering security, availability, confidentiality, and processing integrity.
• ISO 27001:2022 — current certificate.
• Air-gapped deployment — supported for the highest-sensitivity environments where no external network access is permitted.

Outcomes#

What a successful MediQuery deployment looks like depends on the trust's starting position, but the leading indicators stabilise around the same four signals across NHS trust and US health-system rollouts. Trusts that hit these targets within the first 90 days typically convert from pilot to full-estate rollout without escalation.

Citation coverage above 92% of clinical answers — every claim in the answer maps back to at least one source the trust has authorised. This is the headline answer-quality signal; below this band the application is generating content the trust cannot defend.

Override rate at or below 10% for routine queries — clinicians accept the cited recommendation without amendment for the vast majority of straightforward lookups, and overrides on complex cases carry a structured reason that feeds the next knowledge-base refresh cycle. A persistent spike above 15% on a specific topic means the underlying knowledge source is stale or missing.

Clinician usage at 60-80% of licensed seats actively engaged each week — pilots that struggle to reach 40% usage usually have a knowledge-base or default-surface problem (the clinician's first question did not find a satisfying answer), not a product problem. Trusts with high usage typically have a clinical-champion model where consultants in each speciality nominate the first three knowledge sources for their team.

Time saved per clinician — self-reported and corroborated by EHR session-length data, typical deployments report 20-40 minutes per clinician per shift returned to direct patient time as routine lookups collapse from minutes to seconds. The exact number varies by speciality and trust, and the trust's clinical-effectiveness team is the right owner of that measurement.

Where MediQuery fits in the Yobitel stack#

MediQuery is the flagship clinical entry in the Yobitel AI Applications suite. It sits on top of Yobibyte, which provides the managed inference surface and the workspace boundary; the trust never sees a model, an accelerator, or an inference engine. Yobibyte sits on top of Omniscient Compute, which surfaces the underlying capacity from Yobitel-operated regions; the trust never sees a provider or a capacity reservation. InferenceBench provides the open methodology that grounds the model selection inside Yobibyte's marketplace; the trust can independently verify the ranking that drove the application's model choice.

Practically, a trust adopting MediQuery is buying a clinical workflow, not a platform. The clinical lead and knowledge librarian configure knowledge sources and EHR connectivity; the IT counterpart wires identity and audit export; the clinical cohort runs the pilot; Yobitel operates everything underneath. NeoCloud Operations runs the underlying GPU estate, Managed Ops runs the 24/7 NOC, Customer Excellency owns the relationship, and Professional Services delivers any bespoke integration work (custom EHR connectors, trust-specific knowledge-base builds, on-premise hardware delivery). The trust consumes one subscription and one console.

For trusts that want to extend MediQuery's pattern to other clinical applications, the Yobitel AI Applications suite includes vertical applications for additional clinical and life-sciences workflows. Trusts that want to build their own clinical RAG application on the same foundation can do so through Yobibyte directly; MediQuery is the reference implementation, not the only path.