Governance-Aware AI Workflow Infrastructure for Secure and Policy-Compliant Healthcare Analytics

Abstract

Modern healthcare analytics increasingly relies on complex AI-driven workflows operating over sensitive datasets across institutional boundaries. Ensuring secure, auditable, and policy-compliant execution of these workflows remains a significant challenge. Existing systems typically treat workflow generation, policy enforcement, and execution auditing as separate concerns, resulting in fragmented governance mechanisms. This article proposes a governance-aware workflow lifecycle architecture for AI-driven analytics workflows that integrates natural language workflow synthesis, blockchain-based policy enforcement, and auditable execution, embedding governance directly within the workflow lifecycle. In our framework, large language models translate user requests into executable analytics workflows represented using Business Process Model and Notation (BPMN). Access control policies defined in XACML are compiled into smart contracts that enforce policy compliance and record immutable audit logs on a blockchain. Sensitive datasets remain off-chain while metadata and compliance events are securely recorded. We implement a prototype platform for healthcare analytics demonstrating the generation and execution of survival analysis workflows. We further evaluate the robustness of LLM-generated workflows through an ablation study examining how prompt structure affects BPMN diagram correctness and completeness. Results highlight both the promise and limitations of automated workflow generation in regulated analytics environments. Our work demonstrates the feasibility of integrating governance mechanisms directly into AI workflow infrastructures, providing a foundation for secure and auditable analytics in sensitive domains.

I. INTRODUCTION

The growing adoption of artificial intelligence and data-driven analytics in healthcare has created unprecedented opportunities for improving clinical research and decision-making. Large-scale medical datasets, electronic health records, and genomic repositories enable sophisticated analytical workflows ranging from survival analysis to predictive modeling. At the same time, the use of such sensitive data introduces stringent requirements for security, regulatory compliance, and auditability. Healthcare analytics systems must ensure that data access policies are respected, analytical workflows comply with institutional and regulatory constraints, and all data usage can be transparently audited.

Traditional healthcare data infrastructures typically rely on centralized access control mechanisms enforced by institutional servers or identity providers. While effective in localized environments, these systems face significant limitations when analytics workflows span multiple datasets, organizations, or computational platforms. In such distributed settings, ensuring consistent policy enforcement and maintaining trustworthy audit trails becomes challenging. Moreover, modern analytics increasingly involve complex pipelines that integrate data filtering, statistical modeling, and visualization. Managing policy compliance across such workflows remains largely a manual and fragmented process, particularly when workflows span multiple institutions or cloud environments.

A second emerging challenge arises from the increasing use of automated tools for generating analytics workflows. Recent advances in large language models (LLMs) enable users to describe analytical goals in natural language and automatically generate executable pipelines. While such tools have the potential to democratize access to advanced analytics, they introduce new governance concerns. Automatically generated workflows may access restricted datasets, violate policy constraints, or execute without appropriate audit mechanisms. As a result, workflow automation must be tightly integrated with governance and policy enforcement mechanisms, particularly in sensitive domains.

These challenges motivate the need for governance-aware workflow infrastructures in which policy enforcement, auditability, and workflow execution are integrated within a unified system architecture. Rather than treating access control, workflow generation, and analytics execution as separate components, governance mechanisms should be embedded directly into the workflow lifecycle.

While this work incorporates established technologies including BPMN, XACML, blockchain smart contracts, and large language models, its primary contribution is not the introduction of a new access-control protocol or workflow language. Rather, we present a governance-aware systems architecture that integrates these previously separate capabilities into a unified workflow lifecycle, enabling automated workflow synthesis, policy enforcement, and auditable execution within a single framework for sensitive analytics.

Our system integrates three key capabilities: (i) natural language workflow synthesis using large language models, (ii) decentralized policy enforcement based on XACML-defined access rules compiled into blockchain smart contracts, and (iii) auditable execution of analytics workflows through an event-driven architecture. In our framework, users describe analytical tasks in natural language, which are translated into executable workflows represented using Business Process Model and Notation (BPMN). Access requests are evaluated through smart contracts that enforce attribute-based policies while recording immutable audit logs. Sensitive healthcare datasets remain off-chain, while metadata and policy decisions are securely logged to ensure transparency and accountability.

We implement a prototype healthcare analytics platform demonstrating the feasibility of this architecture. The system supports automated generation and execution of survival analysis workflows, including Kaplan–Meier survival curves and Cox proportional hazards models, operating over clinical datasets. To better understand the reliability of automated workflow synthesis, we conduct an empirical evaluation of LLM-generated BPMN workflows through a prompt ablation study. Our results demonstrate that while LLMs can generate valid and executable workflows under structured prompts, workflow correctness and structural detail degrade when contextual information is reduced, highlighting the importance of governance-aware workflow validation mechanisms.

The key contributions of this article are:

• We propose a governance-aware workflow lifecycle architecture that tightly couples workflow synthesis, decentralized policy enforcement, and auditable execution within a unified infrastructure for healthcare analytics.

• We develop a policy enforcement framework that translates XACML-based attribute policies into blockchain smart contracts, enabling decentralized and tamper-resistant policy compliance verification.

• We implement a prototype healthcare analytics platform supporting natural language workflow generation, policy-compliant dataset access, and auditable execution of statistical analysis pipelines.

• We evaluate the robustness of LLM-generated workflows through an ablation study examining the impact of prompt structure on BPMN workflow correctness and completeness.

Together, these results demonstrate the feasibility of integrating governance mechanisms directly into AI-driven workflow infrastructures. Such systems represent an important step toward secure, auditable, and policy-compliant analytics platforms for sensitive data environments.

II. BACKGROUND AND RELATED WORK

The proposed system lies at the intersection of several research areas including governance-aware access control systems, automated workflow generation using large language models, and secure healthcare analytics infrastructures. Prior work in these areas provides important building blocks, but existing systems typically address these concerns in isolation. Our work integrates them into a unified governance-aware workflow architecture.

A. ACCESS CONTROL IN DISTRIBUTED SYSTEMS

Access control and policy enforcement are central challenges in distributed data infrastructures, particularly in domains involving sensitive information such as healthcare [1]. Attribute-based access control (ABAC) and policy languages such as XACML have been widely used to express fine-grained access control policies in enterprise and web-service environments. Frameworks such as EPICS [2] demonstrate how such policies can be enforced across composite services, while administrative models for ABAC have been explored to support dynamic and scalable policy management [3].

More recently, blockchain technologies have been explored as a mechanism for decentralized access control and auditability. Several studies have demonstrated the use of smart contracts to enforce access policies and maintain tamper-resistant logs of authorization decisions. For example, Akhtar et al. [4], [5] propose blockchain-based mechanisms for enforcing event-driven policies in distributed business processes. Similarly, Maesa et al. [6] describe blockchain-based architectures for auditable access control systems. These approaches highlight the potential of blockchain infrastructures to provide transparency and accountability in distributed environments.

Within healthcare, blockchain-based systems have been proposed to manage secure access to electronic health records and medical data. Systems such as ACHealthChain [7] and blockchain-enabled EHR frameworks [8], [9] demonstrate how decentralized infrastructures can support secure and auditable healthcare data sharing. Other work has explored attribute-based access control for healthcare IoT environments [10], [11], [12], enabling fine-grained authorization policies for connected medical devices and data sources.

While these systems provide strong foundations for decentralized policy enforcement, they generally operate at the level of data access control and do not address the broader problem of governing complex analytics workflows generated dynamically by AI systems.

B. LLM-BASED WORKFLOW GENERATION

Recent advances in large language models have enabled automated generation of structured workflows from natural language descriptions. Systems such as FlowMind [13] and AutoFlow [14] demonstrate how LLMs can generate process pipelines or orchestration scripts from high-level task descriptions. These approaches enable users to construct complex workflows without detailed programming knowledge.

In healthcare and biomedical domains, LLM-driven workflow generation has been explored for clinical decision support and data analysis. For example, Ganjizadeh et al. [15] propose visual workflow systems for multimodal healthcare data processing, while Gaber et al. [16] investigate the use of LLMs in clinical decision support workflows. Similarly, studies such as Singhal et al. [17] demonstrate the ability of large language models to encode medical knowledge that can support automated reasoning about clinical tasks.

Although these approaches demonstrate the potential of LLMs to generate analytical workflows, they generally assume trusted execution environments and do not address governance concerns such as policy compliance, access control, and auditability of generated workflows.

C. WORKFLOW SYSTEMS FOR HEALTHCARE ANALYTICS

Visual workflow environments have long been used to enable domain experts to design complex analytics pipelines. BPMN-based systems and graphical interfaces allow users to construct workflows that combine data processing, modeling, and visualization components. Several systems have explored visual interfaces for healthcare analytics and clinical workflow management. For example, Tiramisù [18] provides visualization tools for clinical process information, while GuLiNav [19] focuses on visual representations of clinical practice guidelines. Other tools such as Lorikeet [20] support model-driven engineering for workflows involving blockchain-based services. In clinical research settings, statistical workflows such as survival analysis pipelines are widely used for analyzing patient outcomes. Studies such as Wieder et al. [21] demonstrate the importance of these methods in analyzing large healthcare datasets. However, constructing such workflows often requires significant domain expertise and technical effort.

D. POSITIONING OF THIS WORK

The proposed system builds upon these prior efforts but integrates several capabilities that have previously been addressed separately. By embedding governance mechanisms directly within the workflow lifecycle, our architecture provides a unified infrastructure for secure and policy-compliant healthcare analytics. To our knowledge, this is among the first systems to integrate LLM-driven workflow generation with decentralized policy enforcement and auditable analytics execution within a single platform. Unlike prior systems that address workflow generation, access control, or auditability independently, our contribution is the integration of these capabilities into a governance-aware execution model in which policy compliance is evaluated as part of the workflow lifecycle itself. The resulting architecture enables automatically generated workflows to be synthesized, authorized, executed, and audited within a single governance framework. Unlike work focused on new authorization protocols or cryptographic mechanisms, our emphasis is on architectural integration and lifecycle governance, demonstrating how existing technologies can be orchestrated into a coherent and deployable infrastructure for policy-compliant AI workflows.

III. GOVERNANCE-AWARE AI WORKFLOW ARCHITECTURE

This section describes the architecture of our governance-aware healthcare analytics platform. The system integrates automated workflow generation, policy enforcement, and auditable execution within a unified infrastructure designed for sensitive data environments.

A. DESIGN GOALS

The architecture is designed to satisfy several key requirements that arise in healthcare analytics environments.

Policy Compliance:

Access to healthcare datasets and analytical models must comply with institutional and regulatory policies, including constraints based on user roles, organizational affiliations, and research purposes.

Auditability:

All access decisions and workflow executions must be recorded in a tamper-resistant audit log to support regulatory compliance and post hoc analysis.

Usability:

Healthcare professionals often lack extensive programming expertise. The system must therefore support intuitive interfaces for constructing analytical workflows.

Separation of Concerns:

Governance mechanisms should be logically separated from data storage and computation, allowing sensitive data to remain off-chain while policy decisions and audit logs are securely recorded.

B. SYSTEM ARCHITECTURE OVERVIEW

Fig. 1 illustrates the overall architecture of the system. The platform consists of four primary components: a Natural Language Interface to a LLM Workflow Generator, along with a blockchain-based policy enforcement layer, and a workflow execution engine that performs analytics tasks. Users describe analytical tasks through natural language queries, such as requesting survival analysis on a clinical dataset. The LLM translates user requests into BPMN workflows which identify the required datasets, analytical models, and processing steps. Before any workflow execution occurs, access policies are evaluated through smart contracts that enforce attribute-based access rules and record audit events.

FIGURE 1.

Governance-aware architecture for policy-compliant healthcare analytics workflows.

C. GOVERNANCE AND THREAT MODEL

The proposed system operates in environments where analytics workflows access sensitive healthcare datasets across distributed infrastructures. In such settings, governance mechanisms must ensure that workflows comply with institutional policies, that unauthorized users cannot access restricted data, and that all workflow executions are auditable. Our governance model assumes the following system entities:

• Users: Researchers or analysts who request execution of analytics workflows over healthcare datasets.

• Dataset Providers: Organizations that host datasets and define access control policies governing their use.

• Model Providers: Entities that publish analytical models or computational components that may be incorporated into workflows.

• Policy Authority: Institutional authorities responsible for defining attribute-based access control policies expressed in XACML.

• Auditors: Entities responsible for verifying compliance with governance policies and regulatory requirements.

We assume that dataset providers and policy authorities are trusted to define correct policies, but that users and workflow generators may inadvertently or intentionally attempt to construct workflows that violate those policies. The system must therefore enforce policy compliance before granting access to datasets or computational resources.

The threat model focuses on the following potential risks:

• Unauthorized Data Access: A user may attempt to execute a workflow that accesses datasets without possessing the required credentials or permissions.

• Policy Bypass Through Workflow Composition: Automatically generated workflows may combine datasets, models, or filters in ways that violate institutional policies or data usage constraints.

• Access Decision or Audit Log Tampering: In centralized systems, authorization decisions and access logs may be modified or deleted, reducing accountability.

• Misuse of Automatically Generated Workflows: LLM-generated workflows may include incorrect dataset references, inappropriate model usage, or invalid process structures.

To mitigate these risks, the proposed architecture incorporates several governance mechanisms. First, attribute-based access control policies defined in XACML are compiled into smart contracts that enforce authorization decisions on a blockchain infrastructure. These smart contracts verify user credentials and policy compliance before allowing workflow components to access protected resources. Second, authorization decisions and workflow execution events are recorded on-chain, providing tamper-resistant audit trails. Finally, workflow generation and execution are mediated by a policy verification layer that ensures all requested resources satisfy governance constraints before execution proceeds.

This governance model ensures that workflow automation does not bypass institutional policies, while providing transparent and auditable records of all authorization decisions and workflow executions. Our security analysis assumes the standard security guarantees provided by the underlying cryptographic primitives and blockchain infrastructure, including authenticated communication channels, secure digital signature schemes for credential verification, and the integrity of deployed smart contracts. We further assume that dataset providers and policy authorities correctly define access policies, while users and workflow generators may behave maliciously or inadvertently construct policy-violating workflows. Under these assumptions, the proposed architecture prevents unauthorized workflow execution by requiring policy compliance before resource access and provides integrity and non-repudiation for authorization decisions through immutable blockchain audit records.

D. LLM-BASED WORKFLOW GENERATION

Automated workflow generation forms the primary user-facing component of the system. Users submit analytical queries through a natural language interface. These queries are combined with metadata describing available datasets and analytical models.

The plugin constructs a structured prompt containing several elements: descriptions of available datasets and models, examples of valid BPMN workflows, and instructions specifying the required workflow structure. The LLM processes this prompt and works with the workflow orchestrator to identify relevant resources and generate BPMN representations of candidate analytical workflows.

The generated workflows are then presented to the user through a graphical BPMN interface where they can review, modify, or refine the recommended pipeline before execution. This approach allows domain experts to interact with complex analytics pipelines without requiring direct programming expertise.

E. POLICY ENFORCEMENT VIA SMART CONTRACTS

Once a workflow has been generated, the system must verify that the requesting user is authorized to access the required datasets and models. To achieve this, the system employs attribute-based access control policies expressed in XACML and enforced through blockchain smart contracts.

As shown in Fig. 2, the user sends the workflow request and attribute list to the access control management (ACM) plugin. The plugin first retrieves the relevant policy contracts associated with the datasets and models referenced in the workflow. The user and/or attribute manager then provides the required credentials, such as institutional affiliation or professional role, which are cryptographically signed by an authorized credential provider.

FIGURE 2.

Policy enforcement workflow using blockchain-based smart contracts.

These credentials are submitted to the smart contracts deployed on the blockchain. The contracts evaluate the request according to the encoded policies and emit events indicating whether access has been granted or denied. These events are monitored by the ACM plugin which provides the permit authorization (if received) along with the blockchains transactions (to allow auditability) to the service providers. Finally, the service providers can provide access to the resources for workflow execution, if they receive the appropriate authorization.

F. EXECUTION AND AUDIT LAYER

If the smart contract emits a positive authorization decision, service providers release the required datasets and analytical models to the client. The workflow is then executed according to the BPMN pipeline generated by the LLM.

To preserve privacy, sensitive healthcare data are never stored on-chain. Instead, the blockchain records only policy compliance metadata, including access decisions, timestamps, and hashed references to the associated policies. This design ensures that audit logs remain tamper-resistant while protecting sensitive medical information.

Through this architecture, governance mechanisms become an integral component of the workflow lifecycle, enabling secure and auditable analytics across distributed healthcare data environments.

IV. POLICY ENFORCEMENT FRAMEWORK

Healthcare analytics workflows often involve datasets and models governed by complex institutional and regulatory policies. These policies typically specify conditions under which users may access resources based on attributes such as organizational affiliation, research purpose, or professional role. Enforcing such policies in distributed analytics environments requires mechanisms that are both verifiable and auditable. Our system implements a decentralized policy enforcement framework that integrates attribute-based access control policies with blockchain-based smart contracts. The framework translates high-level policy specifications into executable contracts that evaluate access requests and record compliance decisions.

Policy Representation:

Access control policies in our system are expressed using the eXtensible Access Control Markup Language (XACML), a widely used standard for attribute-based access control. XACML enables policy authors to specify conditions that determine whether a user may access a particular resource based on attributes associated with the subject, resource, action, and environment. For healthcare analytics workflows, typical policy attributes include user attributes such as institutional affiliation or professional role, resource attributes describing datasets or analytical models, and environmental conditions such as approved research purposes. Policies are associated with specific datasets and models stored in the resource catalog. When a workflow references these resources, the corresponding policies are retrieved and evaluated prior to execution.

Policy Compilation to Smart Contracts:

To enable decentralized policy enforcement, XACML policies are translated into blockchain smart contracts written in Solidity. This compilation process converts policy rules into executable logic that can evaluate access requests and generate authorization decisions. Each contract represents the policy associated with a particular dataset or analytical resource. The contract receives credential information from requesting clients and evaluates whether the attributes satisfy the required policy conditions. The contract then emits a decision event indicating whether access is permitted or denied. By encoding policy logic within smart contracts, the system ensures that authorization decisions are transparent and tamper-resistant.

Credential Verification:

Users provide credentials issued by authorized credential providers to demonstrate compliance with policy requirements. These credentials may include digital attestations of institutional affiliation, professional certification, or project approval. When a user requests access to a dataset or model referenced in a workflow, the client submits the required credentials to the corresponding smart contract. The contract verifies the provided attributes against the encoded policy rules. If the conditions are satisfied, the contract emits a positive authorization decision. Credential verification occurs without exposing sensitive user information on the blockchain. Instead, only cryptographic proofs or hashed identifiers are recorded to maintain privacy.

Event-Based Authorization:

The smart contracts generate authorization outcomes in the form of blockchain events. These events serve as verifiable notifications indicating whether the requested access has been granted or denied. Both service providers and client applications subscribe to these events. When a positive authorization event is emitted, the service providers release the requested datasets or models to the client. If access is denied, the workflow execution is halted. This event-driven design ensures that policy enforcement decisions are consistently applied across all participating components.

Audit Logging and Compliance Tracking:

In addition to enforcing access control decisions, the blockchain layer provides a tamper-resistant audit log of policy compliance events. Each authorization request produces a record containing the policy identifier, requesting entity, authorization decision, a timestamp, and references to the associated workflow. Because these records are stored on a distributed ledger, they provide a transparent and immutable record of data access decisions. This capability is particularly valuable in healthcare environments where regulatory compliance and traceability are critical. Through this policy enforcement framework, governance mechanisms become tightly integrated with the lifecycle of analytics workflows, ensuring that sensitive datasets are accessed only under approved conditions and that all policy decisions remain auditable.

V. PROTOTYPE IMPLEMENTATION AND DEPLOYMENT

We implemented a prototype healthcare analytics platform that integrates automated workflow generation, policy enforcement, and auditable execution. The prototype provides an end-to-end pipeline allowing users to construct analytics workflows through natural language queries while ensuring policy compliance for access to datasets and models.

A. SYSTEM COMPONENTS

The prototype consists of four primary components corresponding to the architectural layers described in Section III:

• LLM Workflow Interface: A natural language interface through which users describe analytical tasks.

• Workflow Orchestrator: A component responsible for translating LLM outputs into executable BPMN workflows and coordinating interactions between datasets, models, and execution environments.

• Policy Enforcement Layer: Smart contracts deployed on a blockchain test network that evaluate access control policies and record authorization decisions.

• Execution Environment: A computation environment where approved workflows are executed using healthcare datasets and analytical models.

Together, these components enable automated workflow synthesis while maintaining policy compliance/auditability. The implementation is intended as a proof-of-concept prototype demonstrating end-to-end architectural feasibility rather than production deployment. Accordingly, the emphasis is on validating integration across workflow synthesis, decentralized policy enforcement, and auditable execution.

B. LLM-BASED WORKFLOW GENERATION

The prototype uses a large language model to generate analytics workflows from natural language queries. Users submit requests describing analytical tasks such as generating survival curves or performing statistical modeling on clinical datasets.

The system constructs structured prompts containing descriptions of available datasets, metadata describing analytical models, and examples of BPMN workflow structures.

The LLM processes the prompt and produces a BPMN representation of the recommended workflow. The workflow identifies the datasets and models required to perform the requested analysis. The generated BPMN diagram is presented to the user through a graphical interface where it can be reviewed or modified before execution.

C. RESOURCE CATALOG

Datasets and analytical models available to the system are maintained in a resource catalog. Each entry in the catalog includes metadata describing dataset characteristics, associated analytical models, and applicable access control policies. The resource catalog enables the LLM to select appropriate analytical components when generating workflows and ensures that the corresponding policy constraints are retrieved during the authorization phase.

D. SMART CONTRACT DEPLOYMENT

Policy enforcement is implemented using smart contracts written in Solidity and deployed on an Ethereum test network. Each dataset or analytical model is associated with a smart contract that encodes the access control policy governing its use. When a workflow references a particular dataset or model, the client retrieves the corresponding smart contract and submits the required credentials. The contract evaluates the request according to the encoded policy rules and emits an authorization event indicating whether access is permitted. The use of a blockchain test network allows authorization decisions and policy compliance records to be stored in a tamper-resistant ledger without exposing sensitive healthcare data.

E. WORKFLOW EXECUTION

Once the smart contract emits a positive authorization decision, the workflow orchestrator retrieves the required datasets and analytical models from the service providers. The workflow is then executed according to the BPMN specification generated by the LLM. The prototype currently supports several statistical analysis tasks commonly used in healthcare research, including survival analysis workflows such as Kaplan–Meier estimation and Cox proportional hazards modeling. These workflows operate on clinical datasets stored within the resource catalog.

F. AUDIT AND PROVENANCE TRACKING

To support transparency and regulatory compliance, the system records authorization decisions and workflow execution events in the blockchain ledger. Each authorization request generates an immutable record containing the policy identifier, authorization outcome, and timestamp.

Because only policy compliance metadata is stored on-chain, the system preserves the confidentiality of sensitive healthcare data while maintaining a verifiable audit trail of analytics activities.

This prototype demonstrates the feasibility of integrating automated workflow synthesis with decentralized policy enforcement and auditable analytics execution within a single governance-aware infrastructure.

The prototype consists of approximately 4 k lines of code across the workflow orchestration layer, policy enforcement layer, and user interface. The implementation uses React for the front-end, Node.js for orchestration services, Solidity smart contracts deployed on the Ethereum Sepolia network, and Gemini-2.5-Pro for workflow synthesis.

VI. EXPERIMENTAL EVALUATION

The goal of the experimental evaluation is to assess the reliability of LLM-generated BPMN workflows under varying levels of prompt structure and contextual information. Because the proposed system relies on large language models to translate natural language queries into executable analytics workflows, understanding the robustness of workflow synthesis is critical for evaluating the feasibility of governance-aware workflow infrastructures.

To study this, we conducted an ablation analysis comparing four prompt variants with progressively reduced contextual information. In each run, the LLM was instructed to generate 17 BPMN diagrams representing a diverse set of workflow tasks. The four prompt variants were:

1. Comprehensive Prompt, including diagram examples and explicit dataset/model information with schemas.

2. No Dataset/Model Information, which removes schema descriptions and retains only dataset and model names.

3. No Diagram Examples, which removes BPMN examples but retains dataset and model metadata.

4. Basic Instructions Only, which provides only the list of diagram types and filenames with no additional context.

All experiments were conducted using the Gemini-2.5-pro model through the OpenRouter API. Each configuration was executed five times and all reported metrics represent averages across the five runs.

The evaluation metrics were inspired by the work of Li and Toxtli [22], which examined the quality of LLM-generated BPMN diagrams.

A. EVALUATION METRICS

We evaluated the generated BPMN diagrams using six metrics:

• Renderability: Whether the output is a well-formed BPMN diagram (i.e., syntactically valid XML that can be imported into a BPMN tool).

• Completeness: The proportion of expected tasks and elements present in the generated diagram.

• Level of Detail: The degree to which the diagram includes finer-grained subprocesses, conditional logic, and appropriately labeled processes.

• Arrow Correctness: The fraction of sequence flows that correctly connect the intended source and destination elements.

• Readability: A qualitative assessment of diagram clarity and visual organization.

• Inference Time: The average time required by the LLM to generate BPMN diagrams per invocation.

Renderability was assessed by parsing the generated BPMN XML. The remaining metrics were evaluated by human validators on a normalized scoring scale. Inference time was recorded through the API and averaged across experimental runs.

B. DIAGRAM CATEGORIES

To analyze the impact of structural complexity on generation quality, the generated BPMN diagrams were grouped into the following five categories based on the number of datasets, models, and filtering operations involved in the workflow:

• Default Diagram: Baseline workflows without explicit model or dataset information.

• Single Model without Filter: Workflows using a single model with one or more datasets but no filtering operations.

• Two Models without Filter: Workflows involving two analytical models (Cox Proportional Hazard Regression and Kaplan–Meier Survival Curves) and one or more datasets without filtering.

• Single Model with Filter: Workflows containing one analytical model with one to three levels of dataset filtering.

• Two Models with Filter: Workflows involving two analytical models (Cox Proportional Hazard Regression and Kaplan–Meier Survival Curves) combined with one to three levels of dataset filtering.

This categorization allows the evaluation to capture both structural complexity (#models and #datasets) and hierarchical workflow depth (#filters). Table 1 summarizes the mapping between diagram types and evaluation categories.

TABLE 1.

Diagram Types to Evaluation Categories Mapping

Category	Diagram Type
Default	Default Diagram (no dataset, no model)
Single Model without filter	Single Model + Single Dataset Single Model + Multiple Datasets Single Model + Single Dataset + 1 filter Single Model + Multiple Datasets + 1 filter
Single Model with filter	Single Model + Single Dataset + 2 filters Single Model + Multiple Datasets + 2 filters Single Model + Single Dataset + 3 filters Single Model + Multiple Datasets + 3 filters
Two Models without filter	Two Models + Single Dataset Two Models + Multiple Datasets
Two Models with filter	Two Models + Single Dataset + 1 filter Two Models + Multiple Datasets + 1 filter Two Models + Single Dataset + 2 filters Two Models + Multiple Datasets + 2 filters Two Models + Single Dataset + 3 filters Two Models + Multiple Datasets + 3 filters

C. PROMPT CONFIGURATIONS

To evaluate the effect of prompt structure, we constructed four prompt configurations.

Basic Instructions Only:

This configuration includes includes the task instructions and list of diagrams to be generated in natural language. Specifically, the prompt includes: i) list of available models and datasets; and ii) list of output BPMN diagrams and formatting instructions. This basic instructions only prompt serves as a baseline for comparison.

Basic Instructions + Models and Datasets:

The prompt in this configuration includes the basic instructions describe above as well as available models and datasets descriptions in a structured format. The model description includes model name, input and output parameters with data types, libraries used by the model, and data processing steps. Dataset description includes summarized description, source information, and schema.

Basic Instructions + Seed Diagrams:

The prompt in this configuration includes the basic instructions and up to 5 BPMN diagrams to provide the BPMN specific workflow context.

Comprehensive Prompt:

The comprehensive prompt includes the basic instructions, model and dataset descriptions, and BPMN seed diagrams. This configuration provides the LLM with maximum contextual information.

D. RESULTS

Tables 2-5 summarize the averaged performance metrics for each prompt configuration across diagram categories. Note that the values listed in each cell are the averages over five runs. Furthermore, the average scores listed in each table are actually the average over all seventeen different diagram types listed in Table 1. Fig. 3 visually depicts how various prompt configurations fare (on average across different diagram categories) across different utility metrics. Compared to the Basic Instructions Only configuration (baseline), all other prompt configurations achieved better performance across all utility metrics, with the Comprehensive Prompt configuration performing the best. Interestingly, the Basic Instructions + Seed Diagrams prompt configuration performs very closely to the comprehensive prompt in all utility categories except for the level of detail. Interestingly, the Basic Instructions + Models and Datasets prompt configuration also performs reasonably closely to the comprehensive prompt configuration in all utility categories except for readability. The detailed results are discussed below.

TABLE 2.

Average Metrics for Each Category Under the Comprehensive Prompt

Category	Renderability	Completeness	Level of Detail	Arrow Correctness	Readability
Default Diagram	1.00	1.00	1.00	1.00	1.00
Single Model with filter	1.00	1.00	0.80	1.00	1.00
Single Model without filter	1.00	1.00	0.80	1.00	1.00
Two Models with filter	1.00	1.00	0.90	1.00	1.00
Two Models without filter	0.80	0.80	0.70	0.80	0.80
Average Scores	0.98	0.98	0.84	0.98	0.98

TABLE 5.

Average Metrics for Each Category With Basic Instructions Only

Category	Renderability	Completeness	Level of Detail	Arrow Correctness	Readability
Default Diagram	0.40	0.40	0.40	0.40	0.40
Single Model with filter	0.40	0.20	0	0.40	0.30
Single Model without filter	0.40	0.30	0	0.40	0.40
Two Models with filter	0.40	0.20	0	0.40	0.33
Two Models without filter	0.40	0.20	0	0.40	0.40
Average Scores	0.40	0.22	0.02	0.40	0.34

FIGURE 3.

Utility metrics averaged over different diagram categories for various prompt configurations.

Basic Instructions Only:

The weakest performance occurred under the Basic Instructions configuration (Table 5). Renderability and arrow correctness remained moderate, but completeness and level of detail dropped substantially.

Basic Instructions + Models and Datasets:

This prompt configuration led to greater variability in results (Table 4). Renderability and arrow correctness remained relatively high, but completeness, detail, and readability declined in more complex multi-model workflows, primarily due to lack of BPMN structural context.

TABLE 4.

Average Metrics for Each Category With No Diagram Examples

Category	Renderability	Completeness	Level of Detail	Arrow Correctness	Readability
Default Diagram	1.00	1.00	1.00	1.00	0.80
Single Model with filter	0.90	0.90	0.87	0.90	0.70
Single Model without filter	1.00	1.00	1.00	1.00	0.80
Two Models with filter	0.87	0.83	0.73	0.87	0.60
Two Models without filter	1.00	0.90	0.80	1.00	0.70
Average Scores	0.92	0.89	0.84	0.92	0.68

Basic Instructions + Seed Diagrams:

Adding BPMN seed diagrams to basic instructions improves renderability, completeness, and readability. However, due to lack of models and datasets description, the Level of Detail metric has a significantly lower value compared to Basic Instructions + Models and Datasets prompt configuration (Table 3). In these cases the LLM frequently defaulted to incorrect dataset or model labeling.

TABLE 3.

Average Metrics for Each Category With No Dataset and No Model Schema

Category	Renderability	Completeness	Level of Detail	Arrow Correctness	Readability
Default Diagram	1.00	1.00	1.00	1.00	1.00
Single Model with filter	1.00	1.00	0.10	1.00	1.00
Single Model without filter	1.00	0.90	0.10	1.00	1.00
Two Models with filter	1.00	0.80	0.30	1.00	1.00
Two Models without filter	1.00	0.80	0.30	1.00	1.00
Average Scores	1.00	0.89	0.25	1.00	1.00

Comprehensive Prompt:

The Comprehensive Prompt achieved near-perfect results across most evaluation metrics (Table 2). Renderability, completeness, arrow correctness, and readability were consistently high across all diagram categories. Minor reductions were observed only in the Level of Detail metric for some multi-model workflows.

Inference Time:

We measured the average inference times across prompt configurations. The Comprehensive Prompt required the longest generation time (394 seconds), followed by the Basic Instruction + Seed Diagrams configuration (349 seconds), the Basic Instruction + Models and datasets configuration (311 seconds), and the Basic Instructions configuration (165 seconds). Clearly, richer prompts require additional reasoning steps but produce higher-quality outputs.

E. LLM VS. TEMPLATE-BASED WORKFLOW GENERATION

To contextualize the performance of LLM-based workflow generation, we compare the proposed LLM-based approach with template-driven workflow generation approach. In the template-driven approach, BPMN workflows are generated using predefined templates corresponding to common analytical tasks (e.g., survival analysis pipelines). Each template encodes a fixed structure of tasks (data loading, preprocessing, model execution, and visualization), with placeholders that are populated using the dataset and model selections specified in the user query.

Unlike the LLM-based approach, the template-driven approach does not perform semantic interpretation of the query or dynamic workflow composition. As a result, it produces syntactically valid workflows with consistent structure, but lacks flexibility in adapting to variations in task requirements, multi-model scenarios, or hierarchical filtering.

We compare this template-driven approach with the LLM prompt configurations described earlier. In particular, the Basic Instructions Only configuration serves as a lower-bound baseline for unstructured LLM prompting, while the template-based approach represents a structured but non-adaptive workflow generation strategy. For the different combinations of diagram types listed in Table 1, the template-driven approach would require a large number of predefined templates to cover the combinations of datasets, models, and filtering operations considered in this study. In contrast, the LLM-based approach with comprehensive prompting required only a few (up to 5) BPMN diagram examples to establish the necessary context for the LLM.

Conceptually, template-driven workflow generation provides strong guarantees regarding syntactic correctness and consistency because workflows are instantiated from predefined structures. However, such approaches require manual development and maintenance of workflow templates and may be less adaptable to new analytical tasks, dataset combinations, or filtering scenarios. In contrast, LLM-based workflow generation can dynamically synthesize workflows from natural language descriptions, reducing template engineering effort while introducing new challenges related to correctness and governance.

As an additional qualitative evaluation of workflow generation fidelity, we performed a workflow reconstruction study based on a published healthcare analytics paper. Rather than specifying datasets, models, or workflow structure directly, the LLM was prompted only with the analytical objective as well as the relevant data sources described in the paper. The generated workflow selected the appropriate dataset and analytical methodology and produced a BPMN workflow that reproduced the key analytical stages of the overall analytical process described in the original publication. While this evaluation is qualitative rather than quantitative, it provides further evidence that the proposed framework can synthesize workflows that are consistent with established analytical methodologies described in the literature.

F. DISCUSSION

The results reveal several consistent trends. First, prompt richness strongly influences workflow quality. The Comprehensive Prompt consistently produces the highest-quality diagrams across all evaluation metrics. When contextual information is removed, particularly dataset and model metadata, the Level of Detail metric declines substantially. Second, example BPMN diagrams play an important role in maintaining structural consistency. Lack of BPMN examples results in lower readability and reduced detail in more complex multi-model workflows. Third, workflow complexity significantly affects generation performance. Simple diagrams such as default workflows or single-model cases are consistently generated correctly, while multi-model workflows with multiple filtering levels are more prone to errors. Several qualitative issues were also observed. The LLM occasionally hard-coded specific model or dataset names, reducing diagram generalizability. Structural modeling errors were also observed, including missing join gateways following parallel splits. In BPMN modeling guidelines, joins should be represented explicitly using gateways, and omitting these elements can introduce semantic inconsistencies. Finally, some diagrams exhibited layout issues such as overlapping or crossing elements, which negatively impacted readability. Overall, the results demonstrate that LLM-based BPMN workflow generation is feasible for simple and moderately complex workflows. However, diagram quality becomes more fragile when prompts lack structured contextual information or when workflow complexity increases. These findings suggest that automated workflow synthesis should be complemented by governance mechanisms and validation checks to ensure correctness before execution. More broadly, these findings suggest that automated workflow generation and governance should be viewed as complementary rather than independent capabilities. As AI systems become increasingly responsible for constructing analytical workflows, governance mechanisms that validate, authorize, and audit generated workflows become essential for trustworthy deployment in regulated environments.

G. SYSTEM-LEVEL PERFORMANCE EVALUATION

In addition to evaluating workflow generation quality, we conducted a lightweight system-level evaluation to characterize the performance of the major architectural components. We measured (i) workflow generation latency, (ii) smart-contract-based authorization latency, and (iii) workflow execution latency using the prototype implementation described in Section V. The objective of this evaluation is not to benchmark blockchain or workflow engines, but rather to assess whether the proposed architecture introduces practical performance bottlenecks. The results (Table 6) an indication of the practical feasibility of the proposed governance-aware infrastructure.

TABLE 6.

Approximate System-Level Latency Breakdown

Component	Typical Latency
LLM Workflow Generation	165–394 s
Policy Enforcement (Smart Contract)	~1–5 s
Workflow Execution	~5–30 s

Workflow Generation Latency:

Workflow generation latency is dominated by LLM inference time. As discussed earlier, the average generation time varies across prompt configurations, ranging from ~165 seconds on average over all diagram types for the Basic Instructions configuration to ~394 seconds on average over all diagram types for the Comprehensive Prompt. This reflects the increased reasoning required when incorporating structured context such as dataset schemas and BPMN examples.

Policy Enforcement Overhead:

Policy evaluation is performed through smart contracts deployed on the Ethereum Sepolia test network. In our prototype, authorization requests are processed by submitting user credentials and policy attributes to the corresponding contract, which emits an event indicating the authorization decision.

We observe that smart contract execution introduces relatively low latency compared to workflow generation, with authorization decisions typically obtained within a few seconds, depending on network conditions and block confirmation times. This suggests that policy enforcement overhead is not a primary bottleneck in the system.

Workflow Execution Overhead:

Once authorization is granted, workflow execution proceeds in an off-chain environment using local computation resources. For the survival analysis workflows considered in this study (Kaplan–Meier estimation and Cox proportional hazards modeling), execution times are typically on the order of seconds to tens of seconds, depending on dataset size and filtering complexity.

End-to-End System Latency:

Combining these components, the overall end-to-end latency of the system is dominated by LLM-based workflow generation, followed by workflow execution, with policy enforcement contributing a relatively small fraction of total runtime. This highlights an important trade-off: richer prompts improve workflow quality but increase generation latency.

Discussion:

These results indicate that the proposed architecture is feasible for interactive analytics scenarios where workflow generation is performed infrequently relative to execution. Furthermore, the relatively low overhead of blockchain-based policy enforcement supports the use of decentralized authorization mechanisms without significantly impacting system performance.

VII. SYSTEM INTEGRATION AND INTEROPERABILITY

The proposed system is designed to facilitate seamless integration with existing healthcare analytics ecosystems and external computational services. Since the generated workflows are represented using BPMN, they are compatible with standard BPMN 2.0-compliant workflow engines, enabling straightforward integration with clinical decision support systems, healthcare information systems, and enterprise analytics platforms. Furthermore, each generated BPMN workflow is automatically mapped to an executable pipeline script within the platform, allowing direct deployment and execution on workflow orchestration environments that support BPMN-based process execution.

The architecture also supports integration with predeployed analytical models and data repositories by embedding the corresponding API endpoints within workflow tasks, thereby enabling workflows to invoke external services without requiring modifications to the underlying infrastructure. In scenarios where the required analytical models are not already deployed, the proposed system can leverage cloud-based model hosting environments, such as Hugging Face, to automatically deploy and expose models as APIs that can subsequently be incorporated into generated workflows.

In addition, the proposed system is interoperable with blockchain-based governance infrastructures through its smart contract-enabled policy enforcement framework. Generated workflows can interact with blockchain-based policy evaluation services to verify user credentials, enforce access control policies, obtain authorization decisions, and record compliance events before accessing protected datasets or analytical models. This integration enables decentralized policy enforcement, tamper-resistant audit logging, and transparent compliance verification across organizational boundaries while remaining independent of the underlying workflow execution environment.

This standards-based, service-oriented design promotes interoperability, extensibility, and the reuse of existing healthcare analytics assets across organizational boundaries while maintaining governance, policy compliance, and auditability. The proposed architecture is designed to support incremental deployment within existing institutional infrastructures. Organizations may retain their existing workflows, identity management systems, and data repositories while integrating governance-aware policy enforcement through standards-based interfaces. This enables gradual adoption without requiring replacement of existing analytics platforms.

From a scalability perspective, the architecture separates workflow synthesis, policy enforcement, and workflow execution into loosely coupled components that may be independently deployed and scaled. Because sensitive datasets remain off-chain and blockchain interactions are limited primarily to authorization decisions and audit events, the computational overhead associated with decentralized governance remains relatively modest. Future work will investigate large-scale multi-institution deployments involving larger numbers of users, datasets, and concurrent workflow executions.

VIII. LIMITATIONS, FUTURE WORK, AND CONCLUSIONS

This article presents a governance-aware architecture for policy-compliant healthcare analytics workflows. The proposed system integrates LLM-based workflow synthesis, blockchain-based policy enforcement, and auditable workflow execution within a unified infrastructure. By embedding governance mechanisms directly into the workflow lifecycle, the system ensures that access to datasets and analytical models complies with predefined policies while maintaining transparent audit trails.

While the proposed system demonstrates the feasibility of integrating LLM-based workflow synthesis with governance-aware policy enforcement, several limitations remain. Our evaluation focuses on BPMN workflow generation rather than the full lifecycle of analytics workflows, including automated validation and optimization. The current prototype relies on prompt engineering and human review to ensure the quality of generated workflows. Workflow quality is sensitive to prompt structure and contextual information. Our experimental evaluation focuses on representative healthcare analytics tasks rather than adversarial prompting scenarios. We therefore do not evaluate robustness against prompt injection attacks, intentionally malicious workflow requests, or hallucinated resource recommendations. Investigating adversarial prompt robustness, automated workflow validation, and workflow repair mechanisms represents an important direction for future research. The evaluation metrics for completeness, level of detail, arrow correctness, and readability were assessed by human evaluators and therefore may be subject to evaluator bias. Future work will investigate automated workflow validation and repair techniques that combine structural BPMN verification, policy consistency checking, dataset-schema validation, and LLM-assisted workflow correction prior to execution. Similarly, future work could also explore automated validation mechanisms that check generated workflows against dataset schemas, policy constraints, and modeling requirements before execution. Another limitation concerns the handling of complex workflow structures. The experimental results indicate that multi-model workflows with multiple filtering levels are more challenging for LLMs to generate accurately. Future work could incorporate constraint-based validation, workflow repair mechanisms, or hybrid generation approaches that combine symbolic planning with LLM-based synthesis. Finally, the current prototype focuses on healthcare analytics as a motivating domain. While this domain provides strong governance requirements, the underlying architecture is applicable to other sensitive data environments such as finance, genomics, and collaborative scientific research, which can be explored in the future.

Addressing these challenges will help advance the development of trustworthy analytics platforms in which automated workflow generation, policy compliance, and auditable execution are tightly integrated.