Skip to Content

Industry Vocabulary Reference

Healthcare & Life Sciences

Comprehensive enumeration library for the Healthcare and Life Sciences vertical. Covers every subdomain where agentic AI is actively deployed as of March 2026: clinical operations and FHIR interoperability, prior authorisation under CMS-0057-F, clinical decision support, medical device AI regulation (FDA SaMD/PCCP), PHI data governance under HIPAA, revenue cycle and claims, patient engagement, pharmacy and medication, and life sciences research and development. Designed for use as OTel span attributes in an agentic AI SDK and as policy vocabulary in an OPA Rego GRC portal.

v2026.03.1636 enum categories2.2 schema9 subdomains16 standards

Back to industry coverage library

Download mirrored JSONOpen vertical SDK quick startGet API access

How to use this reference

  1. Start with the core file if you need the cross-industry governance baseline.
  2. Then move into the vertical file to see the regulated workflow vocabulary, policy surfaces, and implementation pressure unique to this market.
  3. Use the OTel attributes and policy paths here as the common language across SDK instrumentation, governance review, and evidence export.

March 2026 deployment context

As of March 2026, agentic AI in healthcare is deployed across: ambient clinical documentation (AI scribes replacing manual note-taking), autonomous prior authorisation workflows under CMS-0057-F (72h expedited / 7-day standard deadlines in force Jan 2026), AI-powered diagnostics (radiology triage, pathology, ECG interpretation), revenue cycle automation (claims scrubbing, denial management), patient engagement agents (appointment scheduling, chronic disease monitoring), medication management (dose optimisation, interaction checking, prior auth for specialty pharmacy), clinical trial matching and protocol deviation detection, and PHI de-identification for research. HIPAA BAA requirements apply to all agentic AI vendors handling PHI. The HHS OCR proposed January 2025 HIPAA Security Rule update removes required/addressable distinctions and adds mandatory encryption and continuous monitoring — directly affecting agentic AI deployments.

Risk note: CMS-0057-F requires payers to report prior authorisation metrics publicly by March 31, 2026 and implement all five FHIR APIs by January 1, 2027. The proposed HIPAA Security Rule update (January 2025) shortens breach notification timelines and mandates continuous monitoring — agentic AI systems handling ePHI must be included in risk analysis. Over 1,000 FDA-cleared AI/ML-enabled medical devices exist as of end-2024; the December 2024 PCCP final guidance and January 2025 draft guidance govern their lifecycle management.

Loading Model

  • Mirrored file: 04_vertical_healthcare_life_sciences.json
  • Kind: vertical

OTel Namespaces

healthcare

Primary Standards

  • HL7 FHIR v6.0 (R6 ballot) — Fast Healthcare Interoperability Resources
  • HL7 FHIR R4.0.1 — CMS-mandated API baseline (45 CFR 170.215(a)(1))
  • HL7 Da Vinci Project — CRD, DTR, PAS Implementation Guides (ePA workflow)
  • CMS Interoperability and Prior Authorization Final Rule CMS-0057-F (Jan 2024): metrics Jan 2026, APIs Jan 2027
  • ONC 21st Century Cures Rule / HTI-1 Final Rule (Jan 2024) — USCDI v3, SMART on FHIR
  • FDA AI/ML SaMD Action Plan — PCCP Final Guidance (December 2024)
  • FDA Draft Guidance: AI-Enabled Device Software Functions Lifecycle (January 7, 2025)
  • HIPAA Privacy Rule 45 CFR Part 164 Subpart E
  • HIPAA Security Rule 45 CFR Part 164 Subpart C — HHS OCR Proposed Update (January 2025)
  • HITECH Act — Breach Notification 45 CFR Part 164 Subpart D
  • 21 CFR Part 11 — Electronic Records and Electronic Signatures
  • HITRUST CSF v11 — Healthcare-specific security framework
  • ICH E6 R3 Good Clinical Practice — Clinical trial governance
  • FDA 21 CFR Part 312 — IND regulations for drug and biologic trials
  • CMS Conditions of Participation — Hospital and SNF requirements
  • CMS Stars Rating / HEDIS — Quality measure frameworks

Source URLs

Subdomains

SubdomainCategoriesSample Attributes
Clinical Operations & FHIR Interoperability9healthcare.condition.clinical_status, healthcare.observation.status, healthcare.appointment.status
Prior Authorisation & Utilisation Management4healthcare.prior_auth.status, healthcare.prior_auth.denial_reason, healthcare.prior_auth.davinci_workflow_step
Clinical Decision Support & AI Diagnostics4healthcare.cds.category, healthcare.fda_samd.risk_class, healthcare.fda_samd.pccp_modification_category
PHI Data Governance & HIPAA Compliance4healthcare.phi.handling_action, healthcare.phi.deidentification_method, healthcare.baa.status
Revenue Cycle & Claims Processing3healthcare.claim.submission_status, healthcare.claim.denial_reason_category, healthcare.coding.compliance_flag
Patient Engagement & Remote Monitoring3healthcare.patient_engagement.channel, healthcare.rpm.alert_level, healthcare.patient.consent_type
Pharmacy & Medication Management3healthcare.pharmacy.prior_auth_status, healthcare.pharmacy.adherence_status, healthcare.pharmacy.interaction_severity
Life Sciences: Clinical Trials & Drug Development4healthcare.clinical_trial.status, healthcare.clinical_trial.deviation_severity, healthcare.pharmacovigilance.signal_action
Quality, Safety & Regulatory Reporting2healthcare.patient_safety.event_category, healthcare.quality.measure_status

Implementation examples

  • Prior Authorisation & Utilisation Management: Prior Authorization Status. OPA rule: SLA gate — deny claim for autonomous PA determination when elapsed_hours > 72 (expedited) or elapsed_days > 7 (standard) and status is not in terminal states {approved, denied_*, cancelled_by_provider}. Escalate to human reviewer. (Cms 0057 F: CMS-0057-F: 72h expedited PA decision; 7-day standard PA decision; metrics reporting Jan 1 2026; PA API Jan 1 2027)
  • PHI Data Governance & HIPAA Compliance: Business Associate Agreement Status. OPA rule: block any agentic tool action that would transmit or store PHI with a vendor whose baa_status is not baa_executed_active. Block AI model training on PHI when status is not_required_no_phi_access without first applying de-identification. (Hipaa 164 504: HIPAA 45 CFR 164.504(e) — BAA requirements for business associates)

Illustrative policy patterns

enforce cms0057f pa response sla

Enforce CMS-0057-F prior authorisation response time mandates. Block autonomous agent from closing or deferring a PA request when the SLA deadline has been reached — force escalation to human reviewer with required denial reason codes.

Regulatory basis: CMS-0057-F CMS-0057-F: 72-hour expedited PA, 7-day standard PA — in force January 1, 2026; public metrics due March 31, 2026

package healthcare.prior_auth

terminal_pa_statuses := {
  "approved", "approved_with_modifications",
  "denied_not_medically_necessary", "denied_experimental_investigational",
  "denied_benefit_not_covered", "denied_step_therapy_required",
  "denied_not_prior_authorized", "partial_approval",
  "cancelled_by_provider", "expired"
}

deny[msg] {
  input.prior_auth_type == "expedited"
  input.hours_since_receipt > 72
  not input.healthcare_prior_auth_status in terminal_pa_statuses

block phi storage to unencrypted memory

Deny memory write operations storing PHI to non-encrypted memory stores.

Regulatory basis: HIPAA Security Rule 45 CFR 164 Subpart C; EU AI Act Article 10

package healthcare.data

deny[msg] {
  input.gen_ai_memory_operation == "storage"
  input.gen_ai_data_sensitivity == "phi_hipaa"
  input.encryption_at_rest != true
  msg := "PHI storage to unencrypted memory store is prohibited under HIPAA Security Rule 45 CFR 164.312(a)(2)(iv)"
}

From enum to evidence

The same vocabulary should carry from instrumentation through review. The OTel attribute names here become emitted metadata, those attributes become policy inputs, and those same labels should still be intelligible when a reviewer opens the decision record later.

import { VeriproofClient, VeriproofSdkOptions, SessionMetadata } from '@veriproof/sdk-core';
import { ClinicalConditionStatus, ClinicalConditionStatusMeta, DiagnosticObservationStatus, DiagnosticObservationStatusMeta, CareAppointmentStatus, CareAppointmentStatusMeta } from '@veriproof/sdk-core/verticals/healthcare-life-sciences';

const client = new VeriproofClient(
  VeriproofSdkOptions.createProduction({
    apiKey: process.env.VERIPROOF_API_KEY!,
    applicationId: 'healthcare-life-sciences-production',
  }),
);

const session = client
  .startSession('healthcare-life-sciences.review')
  .withSessionMetadata(SessionMetadata.forTransaction('txn-1001').withEnvironment('production'))
  .addStep('evaluate_workflow', { output: { status: 'completed' } })
  .withMetadata(ClinicalConditionStatusMeta.otelAttribute, ClinicalConditionStatus.active)
  .withMetadata(DiagnosticObservationStatusMeta.otelAttribute, DiagnosticObservationStatus.registered)
  .withMetadata(CareAppointmentStatusMeta.otelAttribute, CareAppointmentStatus.proposed)

await session.complete();
  • SDK: emit the OTel attribute shown on this page during the decision workflow.
  • Policy: reference the matching `opa_policy_path` in governance rules.
  • Evidence: surface the same label and value in the portal and exported record so reviewers are not translating between systems.

For a step-by-step getting-started walkthrough specific to this vertical, open the Healthcare & Life Sciences SDK quick start. For the full core API reference, continue with TypeScript, Python, or .NET.

Ready to connect your first workflow?

Register a free Builder account for full SDK and REST API access, enter the live demo if you want to see the portal first, or request a coverage workshop if your team wants a guided review of this vertical before implementation starts.

Live demo →Get API access →Request coverage workshop →

Highlighted Enum Categories

EnumOTel AttributeValues
ClinicalConditionStatus
HL7 FHIR R6 condition-clinical ValueSet codes. Used in the Condition resource .clinicalStatus element. These exact hyphenated-lowercase codes must be used for FHIR API compliance.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.condition.clinical_statusactive, recurrence, relapse, inactive, remission, resolved, unknown
DiagnosticObservationStatus
HL7 FHIR R6 ObservationStatus codes. The exact code values required in Observation.status. Agentic diagnostic agents writing to FHIR must use these codes precisely.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.observation.statusregistered, preliminary, final, amended, corrected, cancelled, entered-in-error, unknown
CareAppointmentStatus
HL7 FHIR R6 AppointmentStatus codes used in Appointment.status. Agentic scheduling agents must use these exact values to maintain FHIR conformance.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.appointment.statusproposed, pending, booked, arrived, fulfilled, cancelled, noshow, entered-in-error
EncounterStatus
HL7 FHIR R6 EncounterStatus codes used in Encounter.status. Critical for care coordination and billing agents.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.encounter.statusplanned, in-progress, on-hold, discharged, completed, cancelled, discontinued, entered-in-error
ProcedureStatus
HL7 FHIR R6 EventStatus codes used in Procedure.status.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.procedure.statuspreparation, in-progress, not-done, on-hold, stopped, completed, entered-in-error, unknown
ProcedureProgressState
HL7 FHIR ProcedureProgressStatusCodes — granular operative and peri-procedural states. Used in Procedure.statusReason for active procedures.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.procedure.progress_statein-operating-room, prepared, anesthesia-induced, open-incision, closed-incision, in-recovery-room
MedicationRequestStatus
HL7 FHIR R6 MedicationrequestStatus codes used in MedicationRequest.status. AI medication management agents must use these codes precisely.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.medication_request.statusactive, on-hold, ended, stopped, completed, cancelled, entered-in-error, draft
DiagnosticReportStatus
HL7 FHIR R6 DiagnosticReportStatus codes. AI diagnostic agents (radiology AI, pathology AI) must write results using these exact status codes.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.diagnostic_report.statusregistered, partial, preliminary, modified, final, amended, corrected, appended
AdverseEventSeverity
HL7 FHIR AdverseEventSeverity codes and FDA 21 CFR Part 803 adverse event severity categories. Used by patient safety AI agents for adverse event detection and reporting.
Workflow area: Clinical Operations & FHIR Interoperability
healthcare.adverse_event.severitymild, moderate, severe, life-threatening, fatal
PriorAuthorizationStatus
Status of a prior authorisation request under CMS-0057-F. Agentic PA systems must track and surface these status values through the CMS-mandated Prior Authorization API.
Workflow area: Prior Authorisation & Utilisation Management
healthcare.prior_auth.statusreceived_pending_review, information_requested_incomplete, pended_for_clinical_review, peer_to_peer_review_requested, approved, approved_with_modifications, denied_not_medically_necessary, denied_experimental_investigational
PADenialReasonCode
Standardised denial reason codes that CMS-0057-F requires payers to include in PA denial responses and surface through the Prior Authorization API. These must be machine-readable and structured in the FHIR ClaimResponse.
Workflow area: Prior Authorisation & Utilisation Management
healthcare.prior_auth.denial_reasonnot_medically_necessary, experimental_investigational_protocol, benefit_not_covered_plan, step_therapy_required, service_requires_different_provider_type, frequency_limit_exceeded, quantity_limit_exceeded, age_limit_not_met
DaVinciWorkflowStep
Step in the HL7 Da Vinci electronic prior authorisation workflow. These values track the CRD, DTR, and PAS stages that an ePA orchestration agent moves through.
Workflow area: Prior Authorisation & Utilisation Management
healthcare.prior_auth.davinci_workflow_stepcrd_coverage_requirement_check, crd_card_returned_pa_required, crd_card_returned_pa_not_required, crd_card_returned_documentation_needed, dtr_questionnaire_retrieved, dtr_ehr_prefill_complete, dtr_adaptive_form_launched, dtr_documentation_complete

This reference page is rendered from the mirrored JSON file inside the docs app, not from a hand-written website model.

If you need the machine-readable asset for offline review, automation, or internal diffing, use the mirrored JSON download above.

Next: open the corresponding SDK reference under SDK documentation and then compare it with the public-site industry page to see how the same vocabulary is framed commercially.

Last updated on