Skip to Content

Industry Vocabulary Reference

Healthcare & Life Sciences

Healthcare and life sciences fields cover clinical workflows, prior authorization, patient data, pharmacy, and research. Clinical Trials uses this shared vocabulary rather than a separate namespace.

v2026.07.1045 enum categories2.2 schema9 subdomains16 standards

Back to industry coverage library

This page shows selected examples and categories. Download the JSON for the complete vocabulary, including every field, permitted value, and policy pattern in this catalog.

Download vocabulary JSONOpen industry SDK quickstartStart free for 60 days 

How to use this reference

  1. Start with the core file if you need the cross-industry governance baseline.
  2. Choose an industry file for its workflow fields and permitted values.
  3. Match the OTel attributes to the policy paths your rules use, then verify the recorded fields in a test session.

Catalog context

Choose a workflow and identify the minimum data needed to explain its decisions. Record metadata without including patient information unless its use is authorized.

Risk note: Clinical review, privacy obligations, and device requirements depend on the application and its use. Keep proposed rules separate from effective requirements when defining controls.

Vocabulary file

  • Download filename: 04_vertical_healthcare_life_sciences.json
  • Kind: vertical

OTel namespaces

healthcare

Referenced standards

These references explain the catalog's context. A listed standard does not establish that a configured application meets its requirements.

  • 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, Principles and Annex 1 final; Annex 2 final Step 4 (June 2026)
  • 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 references

Subdomains

SubdomainCategoriesSample attributes
Clinical Operations & FHIR Interoperability10healthcare.clinical_trial.solution_category, healthcare.condition.clinical_status, healthcare.observation.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 Development12healthcare.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)

Control ideas

These patterns describe possible controls, not active rules. Confirm applicability, implement the control, and test its effect on the application.

Escalate prior authorization requests at the response deadline

Stop automatic closure or deferral when a prior authorization request reaches its applicable response deadline. Send the case for human review; a denial must include its specific reason.

Regulatory basis: CMS-0057-F decision timeframes: 72 hours expedited and seven calendar days standard for covered non-drug requests. These timeframes exclude federally facilitated Exchange QHP issuers.

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

Enforce before the action

Pass the request and your business action to this function. The core SDK checks policy before the action runs and again before its result is released. A deny or review decision means the action never runs.

import { Veriproof } from '@veriproof/sdk-core';
import type { GovernedResult, IndustryFact, JsonValue } from '@veriproof/sdk-core';

const veriproof = Veriproof.fromEnv();

export async function runProtectedAction<TInput extends JsonValue, TValue>(
  request: TInput,
  action: (input: TInput, signal: AbortSignal) => Promise<TValue>,
): Promise<GovernedResult<TValue, TInput>> {
  // Catalog values for this vertical. Replace them with facts from the current workflow.
  const industry: IndustryFact[] = [
    { attribute: "healthcare.clinical_trial.solution_category", policyInput: "healthcare_clinical_trial_solution_category", value: "clinical_trials" },
    { attribute: "healthcare.condition.clinical_status", policyInput: "healthcare_condition_clinical_status", value: "active" },
    { attribute: "healthcare.observation.status", policyInput: "healthcare_observation_status", value: "registered" },
  ];

  // Policy runs before action() and again before the result is released.
  // A deny or review decision means action() never runs.
  return veriproof.govern(
    "healthcare.life.sciences.evaluate",
    request,
    ({ input, signal }) => action(input, signal),
    { industry },
  );
}
  • Replace the sample values with facts from the current workflow. Rules read them under input.snapshot.industry.
  • Test both permitted and blocked actions. Confirm that a blocked action never reaches your business function.
  • Only completed, completed_with_warning, and transformed results carry a released value.

For review decisions, follow the Human Review guide to configure continuation. Observe remains available when you need to record activity without enforcing a decision.

Set up the Healthcare & Life Sciences example. See the API reference for TypeScript, Python, or .NET.

Start your Developer evaluation

Try a simulator to see a governed decision in context. To connect your own workflow, verify your work email and start Developer free for 60 days. You can also review the relevant controls with our team.

Live demo → Start free for 60 days → Request coverage workshop → 

Selected vocabulary categories

ClinicalTrialSolutionCategory

Buyer-facing solution category for Clinical Trials. It is intentionally scoped to the healthcare_life_sciences vertical and must not be used as a new SDK or industry namespace.

Workflow area: Clinical Operations & FHIR Interoperability

OTel attribute
healthcare.clinical_trial.solution_category
Permitted values
  • clinical_trials

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

OTel attribute
healthcare.condition.clinical_status
Permitted values
  • active
  • 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

OTel attribute
healthcare.observation.status
Permitted values
  • registered
  • 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

OTel attribute
healthcare.appointment.status
First 8 permitted values
  • proposed
  • 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

OTel attribute
healthcare.encounter.status
First 8 permitted values
  • planned
  • 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

OTel attribute
healthcare.procedure.status
Permitted values
  • preparation
  • 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

OTel attribute
healthcare.procedure.progress_state
Permitted values
  • in-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

OTel attribute
healthcare.medication_request.status
First 8 permitted values
  • active
  • 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

OTel attribute
healthcare.diagnostic_report.status
First 8 permitted values
  • registered
  • 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

OTel attribute
healthcare.adverse_event.severity
Permitted values
  • mild
  • 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

OTel attribute
healthcare.prior_auth.status
First 8 permitted values
  • received_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

OTel attribute
healthcare.prior_auth.denial_reason
First 8 permitted values
  • not_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

This page uses the vocabulary JSON distributed with the documentation. Check its version when comparing it with an installed SDK.

Download the vocabulary JSON for offline review or automated comparisons.

Use the SDK reference for configuration and supported APIs. Keep vocabulary selection separate from the compliance team's assessment of applicable requirements.

Last updated on