Articles

Best 5 AI Observability Tools for Healthcare AI Applications in 2026

Five healthcare AI observability platforms scored on HIPAA trace ingestion, §164.312(b) retention, per-clinician access, and BAA-boundary integrity. May 2026.

·
Updated
·
17 min read
healthcare ai-observability llm-observability hipaa compliance regulated-industries
Compliance-pressure-stack diagram showing how HIPAA Security Rule §164.312(b), HITECH Breach Notification, FDA SaMD AI/ML Action Plan + PCCP, 21st Century Cures Act, and EU AI Act Article 14 map to healthcare AI observability requirements
Table of Contents

Best 5 AI Observability Tools for Healthcare AI Applications in 2026

Compliance-pressure-stack diagram showing how HIPAA Security Rule §164.312(b), HITECH Breach Notification, FDA SaMD AI/ML Action Plan + PCCP, 21st Century Cures Act, and EU AI Act Article 14 map to healthcare AI observability requirements

A health system stood up an ambient-scribe pilot on a tier-1 LLM observability vendor. Six weeks in, the privacy officer asked one question: “Pull every trace where the draft note carries a patient’s MRN, scoped to cardiology, for the last 90 days.” The dashboard could not answer it. The exporter was not BAA-covered. Span attributes carried raw MRN. Retention defaulted to 30 days. The access tier was workspace-wide, not per-clinician. None of those failures showed up as a red dot in the UI — they showed up the day the privacy officer asked.

Healthcare AI observability is not healthcare AI evaluation. Evaluation grades clinical outputs against a rubric. Observability captures the production trace and stores it as system-of-record. The observability platform has three healthcare-specific jobs: HIPAA-compliant trace ingestion (PHI handling at the wire), retention that survives a HIPAA Security Rule §164.312(b) audit (6-year horizon under §164.530(j)), and per-clinician access controls that map to the clinical workflow. Generic LLM observability misses all three.

This guide compares the five platforms healthcare ML and compliance engineers should shortlist in 2026, scored on those three jobs.

TL;DR — the five-platform shortlist

#PlatformHIPAA + BAATrace retentionPer-clinician accessBest for
1Future AGIHIPAA + SOC 2 Type II certified per trust page; BAA on Scale tier; PHI redaction at span layerConfigurable HTTPSpanExporter to BAA-aligned store; per-tenant retention; tamper-evidentRow-level RBAC + SAML SSO + SCIM in Agent Command CenterAmbient scribes, prior-auth, clinical copilots in production
2Datadog AIHIPAA-enabled tier; BAA on enterpriseVendor-hosted; tier-1 retention; exporter not portableWorkspace + team scopes; per-clinician needs custom configTier-1 health systems already on Datadog APM
3Arize PhoenixOSS, self-host inside your BAA boundary; managed cloud is BYO BAASelf-host satisfies §164.312(b) if you wire WORM retentionRBAC ships in cloud tier; OSS path is your IAMClinical research IT, VA / DoD-tier teams
4New Relic AIHIPAA limited, enterprise contract; BAA is a sales conversationVendor-hosted; configurable retention at higher tiersWorkspace-shaped; per-clinician not nativeAPM-led shops standardized on New Relic
5Custom on-prem (Honeycomb / OTel)You own it; BAA scope = your orgHoneycomb dynamic sampling + your storage disciplineYou own the IAM and RBAC storyReal ML platform teams with hard on-prem mandate

Future AGI lands #1 because PHI redaction at the span layer, a configurable exporter to a BAA-aligned store, per-tenant tamper-evident retention, and per-clinician RBAC all ship as product defaults. Datadog and New Relic carry APM procurement gravity but ship the trace into a vendor-hosted backend. Arize Phoenix and the Honeycomb / OTel custom path put the BAA boundary entirely under your team’s IAM.

Why healthcare AI observability is different from generic LLM observability

Generic LLM observability tells you a request happened, what model answered, and how many tokens it burned. Healthcare observability has to also produce the audit artifact a CMIO signs, the breach-notification evidence a Privacy Officer reads, and the FDA SaMD audit-trail link a PCCP submission needs. Three failure modes ship in real deployments and do not appear on a generic dashboard: a span attribute carrying raw MRN ships unredacted to a backend the covered entity has not BAA’d; a clinical decision support trace is retained 30 days when §164.312(b) demands six years; a 200-tool-call prior-auth fan-out sits inside a workspace any product manager can read, when the privacy officer needs row-level RBAC scoped to the inquiry.

The 2026 framing is reliability, not capability. The question is whether the trace survives the privacy review and the FDA SaMD audit.

Six regulatory anchors set the bar: the HIPAA Security Rule §164.312(b) for audit-control retention with a 6-year horizon under §164.530(j); the HITECH Breach Notification Rule where raw PHI in a span is a breach trigger; the FDA SaMD AI/ML Action Plan + PCCP for audit-trail integrity linking an eval result back to its trace span; the 21st Century Cures Act; EU AI Act Article 14 (August 2026 enforcement); and the state PHI stack (CMIA, NY SHIELD, TX HB 4). The OpenTelemetry 1.37+ GenAI semantic conventions (gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens) are the 2026 vocabulary every platform here emits against — vendor-portable spans are the procurement insurance against a §164.312(b) 6-year horizon outlasting the SDK vendor.

The three-job scorecard

JobPass criteriaWhy it matters
1. HIPAA-compliant trace ingestionPHI redaction at the span layer pre-export (email, phone, SSN, MRN, patient name, DOB, API keys); BAA-aligned exporter; current HIPAA attestationRaw PHI in a vendor backend without a BAA is a HITECH breach trigger
2. Retention surviving §164.312(b)6-year retention under §164.530(j); tamper-evident audit log; configurable exporter; per-tenant retentionThe §164.312(b) obligation outlives most SDK vendors; vendor-locked retention is a compliance risk
3. Per-clinician access controlsRow-level RBAC mapping to CMIO, department head, attending, privacy officer, SaMD reviewer; SSO + SCIM; access audit logWorkspace-wide reads fail the privacy review; the trace store has to behave like an EHR audit log

Three of three is a production pick. Two of three is a candidate. One of three is a procurement risk.

How the five platforms compare on the three jobs

PlatformPHI ingestion (Job 1)§164.312(b) retention (Job 2)Per-clinician access (Job 3)Deployment
Future AGIStrong — per-tenant PHI redaction at span layer pre-export; MRN / patient name / DOB rule set; HIPAA + SOC 2 + GDPR + CCPA certified; BAA on Scale tierStrong — configurable HTTPSpanExporter to BAA-aligned, FedRAMP-resident, or HIPAA-retention-compliant store; tamper-evident logsStrong — RBAC, SAML SSO, SCIM in Agent Command Center; per-clinician row-level scopeCloud + OSS self-host; AWS Marketplace; BYOC
Datadog AIPartial — HIPAA-eligible tier; PHI redaction is pipeline-layer, not always span-SDK layerPartial — vendor-hosted; tier-1 retention if contracted; exporter not portable off DatadogPartial — workspace + team scopes; per-clinician needs custom configSaaS; Datadog cloud
Arize PhoenixPartial via self-host — PHI redaction is BYO at processor layer; OSS Apache 2.0; no sub-processor when self-hostedStrong via self-host — span store under your retention discipline; WORM is your deployment workPartial — RBAC in Arize cloud; OSS path is your IAMOSS self-host or Arize cloud
New Relic AILimited — HIPAA on separate enterprise contract; BAA is a sales conversation; span-layer redaction is BYOPartial — vendor-hosted; configurable retention at higher tiers; exporter not portablePartial — workspace + role scopes; per-clinician needs custom mappingSaaS; New Relic cloud
Custom on-premYou build — OTel collector with PHI-redaction processor; BAA scope = your orgYou build — your storage class, WORM retention, audit logYou build — your IAM, RBAC, SCIMSelf-host inside your VPC

#1 Future AGI — OTel-native traceAI, Agent Command Center, span-joined eval scores

Future AGI Observe UI showing span detail with prompt and output as attributes plus PHI-redaction badge and span_id linkage to eval result

Best for: hospital systems running ambient scribes, prior-auth agents, clinical decision support, and medical-coding copilots in production who need OpenTelemetry-native auto-instrumentation, per-tenant PHI redaction at the span layer, eval scores joined to the originating span via span_id, and per-clinician RBAC mapped to the clinical workflow.

Future AGI is the only platform in this shortlist where PHI-in-the-wire handling, §164.312(b) retention posture, and per-clinician access controls ship as product defaults. It is also the only one that closes the loop on trace data: spans flow into the eval store via span_id, eval scores feed the optimization layer (agent-opt), and optimized prompts flow back into production with the trace store as ground truth. Observability is one layer of a closed self-improving loop, not a standalone dashboard.

Key strengths:

  • traceAI — OpenTelemetry-native instrumentation SDK (Apache 2.0, OpenInference-compatible) with 35+ framework integrations across OpenAI, Anthropic, LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI, and more. Per-tenant PHI redaction strips email, phone, SSN, API keys, MRN-pattern, patient name, and DOB at the SDK before the exporter ships.
  • Configurable HTTPSpanExporter — the span destination is a deployment property. Targets a BAA-aligned, FedRAMP-resident, or HIPAA-retention-compliant store at your existing data residency without leaving OTel.
  • Agent Command Center ships per-clinician RBAC, SAML SSO, SCIM, and an access audit log. CMIO reads all services; department head reads only their service; attending reads only their patients; privacy officer reads any trace under inquiry; SaMD reviewer reads the audit-trail subset linking eval results to spans via span_id. Row-level scope, not workspace-wide.
  • Eval scores join spans via span_id through the ai-evaluation SDK (60+ evaluators, Apache 2.0). The FDA SaMD PCCP audit-trail integrity requirement that an eval result links back to its trace span ships as default, not a wiring exercise.
  • Error Feed auto-clusters trace failures into named issues with auto-written root cause and quick fix. Clinical reviewers reading 200-tool-call prior-auth traces stop scrolling flat span lists.
  • Compliance. SOC 2 Type II, HIPAA, GDPR, CCPA certified per the trust page; ISO 27001 in active audit; HIPAA BAA on the Scale tier; AWS Marketplace; air-gapped BYOC for federal posture.

Limitations:

  • The opinionated prompt library has fewer collaboration knobs than a dedicated prompt-registry tool. Trade: prompt, eval, and trace in one control plane.
  • The agent-opt self-improving loop is opt-in per route. Trade: the optimizer runs against real production traces with eval scores joined to spans.
  • DICOM and pathology imaging coverage is text-aligned; the imaging path is newer.

Pricing & deployment. Cloud + OSS self-host of the Apache 2.0 SDKs. Free + pay-as-you-go; HIPAA BAA on the Scale tier. See pricing.

Verdict: the only platform that ships PHI-in-the-wire redaction, §164.312(b)-compatible retention, and per-clinician RBAC as defaults rather than configuration work.

#2 Datadog AI — APM-led trace home with HIPAA-eligible posture

Datadog LLM Observability logo

Best for: tier-1 health systems and large EHR vendors already running Datadog APM with a HIPAA-eligible BAA in place, where the LLM observability tier extends the existing audit-retention shape without a new procurement cycle.

Key strengths:

  • GenAI semantic conventions adopted natively; LLM traces emit alongside Datadog’s APM schema with the same flame-graph UI muscle the platform team already runs.
  • HIPAA-eligible BAA posture for existing Datadog APM customers; the security review is faster because hospital InfoSec has vetted Datadog for non-LLM workloads.
  • Datadog query language and dashboards extend to LLM traces; analysts query without learning a new tool.

Limitations:

  • PHI redaction is pipeline-layer, not span-SDK layer; teams handling PHI wire pre-export redaction explicitly.
  • Trace store is vendor-hosted; a §164.312(b) 6-year horizon outlives the MSA, and the exporter is not OTel-portable off Datadog without losing platform-specific richness.
  • Per-clinician access is workspace-shaped; row-level RBAC takes custom configuration.
  • High-floor pricing; not the shape for digital health startups or cost-driven mid-market teams.

Pricing & deployment: enterprise contract; SaaS on Datadog cloud.

Verdict: the procurement-gravity pick when Datadog APM is already the trace home. Pair with a dedicated eval layer when clinical rubric depth or per-clinician RBAC matters more than dashboard unification.

#3 Arize Phoenix — OSS, self-host inside your BAA boundary

Arize Phoenix logo

Best for: clinical research IT, VA / DoD-tier deployments, and university hospital teams that want an OSS, OTel-native trace store self-hosted inside their own BAA boundary with no third-party sub-processor in the data path.

Key strengths:

  • OpenTelemetry-native; OSS Apache 2.0; self-host removes the sub-processor question when the trace store sits inside the covered entity’s data center.
  • Strong project / agent transcript view; the engineering-team default for OSS LLM observability.
  • GenAI semantic conventions adopted; mature LangChain, LlamaIndex, and OTel integrations; clinical research IT can build §164.312(b) retention on top of the OSS span store rather than buying a vendor’s retention story.

Limitations:

  • HIPAA-anchored retention, BAA-boundary integrity, span-layer PHI redaction, and per-clinician RBAC are all BYO. Phoenix gives you the trace store; WORM discipline, redaction processor, BAA-aligned exporter, and IAM mapping are your team’s deployment work.
  • Span-level cost attribution is lighter than Datadog or Future AGI.
  • Managed-cloud (Arize SaaS) carries its own retention contract; read it carefully against HIPAA-eligible BAA posture.

Pricing & deployment: free OSS; self-host or Arize cloud.

Verdict: the engineering-default pick for federal and academic-medical-center teams that want OSS self-host. Pair Phoenix with Future AGI’s ai-evaluation SDK for clinical-grade rubrics joined to spans by span_id.

#4 New Relic AI — APM-led alternative for non-Datadog hospital IT

New Relic AI logo

Best for: hospital IT shops and health-tech vendors already running New Relic APM where the LLM observability tier extends the existing instrumentation footprint without standing up a separate trace vendor.

Key strengths:

  • New Relic APM gravity is real for IT shops that standardized on it before Datadog; the security review and MSA conversation are shorter when the relationship is in place.
  • GenAI semantic conventions supported; OTel-instrumented agent stacks flow into New Relic without re-instrumentation.
  • Unified telemetry surface (logs + metrics + traces); account-level data partitioning supports multi-tenant digital health vendors needing clean tenant isolation.

Limitations:

  • HIPAA is limited and case-by-case; the HIPAA-eligible tier and BAA template are an enterprise sales conversation, not a self-serve toggle.
  • PHI redaction at the span layer is BYO. A custom processor or OTel collector sits between the SDK and the New Relic exporter to scrub MRN, patient name, and DOB.
  • Vendor-hosted trace store; exporter not OTel-portable off New Relic without losing platform-specific richness.
  • Per-clinician RBAC is workspace + role-shaped; row-level scope takes custom configuration. LLM-trace UI depth lighter than Datadog or Future AGI for 200+ tool-call fan-out.

Pricing & deployment: enterprise contract; SaaS on New Relic cloud; HIPAA tier on a separate contract addendum.

Verdict: the procurement-gravity pick when New Relic APM is already in place. For greenfield healthcare AI deployments, Future AGI traceAI ships PHI-in-the-wire redaction and per-clinician RBAC as defaults New Relic asks the team to wire.

#5 Custom on-prem (Honeycomb / OTel collector self-hosted)

Honeycomb logo

Best for: health-system AI labs with a real ML platform team, VA / DoD deployments with a hard on-prem mandate, large EHR vendors with board-level data-residency constraints, academic medical centers with research-grade infrastructure.

The custom path is honest about the trade: you own the trace stack end-to-end. A self-hosted OpenTelemetry collector handles ingestion, a PHI-redaction processor scrubs MRN / patient name / DOB / API keys before the span leaves the boundary, Honeycomb (or a self-host like ClickHouse + a query layer) is the trace store, and your IAM owns per-clinician access. The BAA conversation collapses to your own org.

Key strengths:

  • No third-party sub-processor in the data path; BAA scope = your covered entity; data-residency = your data center.
  • Honeycomb’s dynamic sampling and BubbleUp pattern detection scale to 200+ tool-call agent fan-out without the cost curve of unsampled tier-1 vendors. ClickHouse-backed self-host shapes of the same architecture are well-documented.
  • OTel-native by construction; full control over §164.312(b) retention, WORM discipline, tamper-evidence, and per-clinician RBAC mapped to your EHR identity provider.

Limitations:

  • You own the upgrade path, redaction-rule curation, storage scaling, query-layer performance, and dashboard build. Headcount math rarely beats a HIPAA-certified vendor unless the team exists.
  • Clinical rubrics, evaluator drift detection, and span-to-eval linkage do not ship with the trace store. Pair the custom path with ai-evaluation and traceAI so the primitives match what HIPAA-certified vendors run.
  • The audit-trace artifact is whatever you build it to be. Regulators evaluate what is there; what is missing is on you.

Pricing & deployment: Honeycomb SaaS has HIPAA terms at enterprise scale; the pure self-host path is infrastructure plus engineering headcount.

Verdict: the right answer when data residency is a hard mandate and the platform org is already there. The wrong answer when the narrative is “we’ll save vendor fees” — the math rarely works at startup scale. Use Future AGI’s Apache 2.0 SDKs inside the custom path so eval and optimization are not also custom builds.

Which healthcare AI observability tool should your team pick?

If you are a…PickWhy
Hospital system running ambient scribe / prior-auth, want HIPAA + per-clinician RBAC + span-joined eval in one stackFuture AGIAll three jobs pass as defaults; configurable exporter; per-tenant PHI redaction; Agent Command Center RBAC; eval-to-span via span_id
Tier-1 health system already running Datadog APM with HIPAA-eligible BAADatadog AIProcurement gravity; existing audit-retention extends; pair with Future AGI ai-evaluation for clinical rubric depth
Clinical research IT / VA / DoD / academic medical center wanting OSS self-hostArize PhoenixOTel-native OSS Apache 2.0; self-hosted span store under your §164.312(b) retention; no sub-processor
Hospital IT shop standardized on New Relic APMNew Relic AIExisting APM gravity; unified telemetry; HIPAA on separate contract; pair with Future AGI traceAI for PHI-in-the-wire defaults
Health-system AI lab with ML platform team and hard on-prem mandateCustom (Honeycomb / OTel)Full data-residency control; BAA scope = your org; pair with OSS Future AGI SDKs for eval and optimization
Federal contractor (FedRAMP) / VA / DoD with air-gapped requirementFuture AGI or Arize PhoenixFuture AGI if BYOC air-gapped self-host + configurable exporter close the gap; Phoenix if the team wants pure OSS self-host

Frequently Asked Questions

How does healthcare AI observability differ from healthcare AI evaluation?

Evaluation grades a model output against a clinical rubric. Observability captures the production trace and stores it as system-of-record. The observability platform has three healthcare-specific jobs: HIPAA-compliant trace ingestion that handles PHI at the wire, retention that survives a HIPAA Security Rule §164.312(b) audit (6-year horizon under §164.530(j)), and per-clinician access controls so the trace store reads like an EHR audit log. The sister-post on healthcare AI evaluation platforms covers the eval side.

What is BAA-boundary integrity in a healthcare observability stack?

The property that the span exporter, the trace store, and any downstream eval API all sit inside a signed Business Associate Agreement. The control is PHI redaction at the span layer pre-export plus a configurable exporter that lands traces in a BAA-aligned store. “HIPAA-compliant by product” is not a thing — BAA is per-engagement, signed per sub-processor.

How does an observability platform satisfy HIPAA §164.312(b) audit-control retention?

Trace data is one valid surface for the §164.312(b) audit log. The span store has to satisfy the 6-year retention obligation under §164.530(j), and the exporter has to be configurable so traces land in a HIPAA-anchored audit store. Future AGI’s configurable HTTPSpanExporter, Arize Phoenix’s self-host, and a Honeycomb / OTel-collector self-host all close this directly.

What does per-clinician access control look like in a trace store?

Row-level RBAC mapped to the clinical workflow: a CMIO reads all services, a department head reads their service, an attending reads their patients, a privacy officer reads any trace under inquiry, an FDA SaMD reviewer reads the audit-trail subset linking eval results to spans via span_id. Workspace-level access — the default in generic observability — fails this test. Future AGI’s Agent Command Center ships row-level RBAC + SSO + SCIM as a default.

How do you migrate trace data off a vendor-locked observability SDK?

OTel-native instrumentation is the migration story. GenAI semantic conventions per OTel 1.37+ are vendor-portable, so the exporter can swap backends without re-instrumenting. A §164.312(b) 6-year horizon usually outlives the SDK vendor. Future AGI traceAI, Arize Phoenix, and a self-hosted OTel collector all sit on the OTel-native path; Datadog and New Relic ingest OTel but the analytics surface is vendor-shaped.

Where each platform earns its slot

Future AGI earns #1 because it is the only platform that ships PHI redaction at the span layer, a configurable exporter to a BAA-aligned store, per-tenant tamper-evident retention, and per-clinician row-level RBAC as product defaults. The same trace store joins eval results to spans via span_id for FDA SaMD audit-trail integrity and feeds the agent-opt self-improving loop on real production traces. Datadog AI earns #2 on procurement gravity for tier-1 health systems already on Datadog APM. Arize Phoenix earns #3 on OSS self-host for clinical research IT and federal health systems. New Relic AI earns #4 on the same APM-gravity logic at non-Datadog shops. Custom Honeycomb / OTel-collector self-host earns #5 for teams with a real ML platform org and a hard on-prem mandate.

The shape of the pick is not “which platform is best” — it is “which buyer profile, procurement constraint, and BAA boundary fits the trace your Privacy Officer will read.”

Related reading: the healthcare AI evaluation platforms comparison, the healthcare RAG evaluation deep dive, the healthcare AI guardrails comparison, the HIPAA-compliant voice AI guide, and the medical chatbot playbook. External anchors: the HHS HIPAA Security Rule index, the FDA SaMD AI/ML Action Plan, EU AI Act Article 14, and the OpenTelemetry GenAI semantic conventions.


Updated May 2026. Re-eval cadence: quarterly on regulatory milestones (HHS OCR settlement docket, FDA SaMD enforcement, HHS OIG prior-auth enforcement, EU AI Act Article 14 August 2026 enforcement window) and OTel GenAI semantic conventions revisions.

Frequently asked questions

How does healthcare AI observability differ from healthcare AI evaluation?
Evaluation grades a model output against a clinical rubric. Observability captures the production trace — prompt, retrieval, tool fan-out, model response, latency, cost — and stores it as system-of-record. The observability platform has three healthcare-specific jobs: HIPAA-compliant trace ingestion that handles PHI at the wire, retention that survives a HIPAA Security Rule §164.312(b) audit with the 6-year horizon under §164.530(j), and per-clinician access controls so the trace store reads like an EHR audit log.
Why is generic LLM observability not enough for healthcare AI?
Generic LLM observability ships the trace to a vendor-hosted backend, often without a BAA, with PHI in raw span attributes, with retention defaults shorter than the 6-year §164.312(b) window, and with workspace-level access controls rather than per-clinician RBAC. Each of those is a HIPAA failure mode that does not show up in the dashboard.
What is BAA-boundary integrity in a healthcare observability stack?
BAA-boundary integrity is the property that the span exporter, the trace store, and any downstream eval API all sit inside a signed Business Associate Agreement. The control is PHI redaction at the span layer pre-export plus a configurable exporter that lands traces in a BAA-aligned store. BAA is per-engagement, signed per sub-processor — not a product property.
How does an observability platform satisfy HIPAA §164.312(b) audit-control retention?
Trace data is one valid surface for the §164.312(b) audit log. The prompt, the retrieved context, the model output, and the eval score that flagged the response are exactly what the rule requires the covered entity to retain. The span store has to satisfy the 6-year retention obligation under §164.530(j), and the exporter has to be configurable so traces land in a HIPAA-anchored audit store, not a vendor backend the covered entity has not BAA'd.
What does per-clinician access control look like in a trace store?
Row-level RBAC mapped to the clinical workflow: a CMIO reads all traces across services, a department head reads traces for their service, an attending reads traces for their patients, a privacy officer reads any trace under inquiry, an FDA SaMD reviewer reads the audit-trail subset that links eval results to spans via span_id. Workspace-level access — the default in generic observability — fails this test.
How do you migrate trace data off a vendor-locked observability SDK to satisfy §164.312(b)?
OTel-native instrumentation is the migration story. GenAI semantic conventions per OTel 1.37+ are vendor-portable, so the exporter can swap backends without re-instrumenting the application. A §164.312(b) 6-year retention horizon usually outlives the SDK vendor. Future AGI traceAI, Arize Phoenix, and a self-hosted OTel collector all sit on the OTel-native path; Datadog and New Relic ingest OTel but the analytics surface is vendor-shaped.
Related Articles
View all