From Siloed Algorithms to Compliance-First Agentic Platforms: A Multi-Layered Architecture for Hospital AI Systems

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

From Siloed Algorithms to Compliance‑First Agentic Platforms: A Multi‑Layered Architecture for Hospital AI Systems Manideep Dhar1*; Ritwik Singh2; Sharat Chandra Kumar Manikonda3 1

Chief Operating Officer and Head of Research and Development, Instil-IT, Hyderabad, Telangana. 2 Chief Artificial Intelligence Architect Engineer, Instil-IT, Hyderabad, Telangana. 3 Chief Executive Officer, Managing Director and Chief Data Scientist, Instil-IT, Hyderabad, Telangana. 1

ORCID ID: 0009-0006-8965-0246

Corresponding Author: Manideep Dhar1* Publication Date: 2026/06/02 Abstract: Hospitals are rapidly adopting artificial intelligence for triage, imaging, scheduling etc., yet most deployments remain isolated point solutions locked inside departmental silos, resulting in duplicated effort, hidden risks, and unrealised enterprise value. Despite explosive growth of AI in healthcare market and accelerating investment, an estimated 70–80% of healthcare AI pilots fail to scale, largely due to governance gaps, fragmented data, and missing integration blueprints. This research proposes a hospital-specific, compliance-first, Agentic AI architecture with multiple interoperable layers, extending existing hospital AI platform models with: (i) an Agent Orchestration Layer for multi-agent workflows across clinical, operational, and financial domains, (ii) a Compliance and Policy Layer that centralises policy-as-code for HIPAA, GDPR, the EU AI Act, DISHA, India’s DPDP Act, and ISO/IEC security and safety standards, and (iii) a Privacy-Preserving Data Fabric that plugs federated learning, differential privacy, and secure enclaves into real-world Hospital Information Management System (HIMS) flows. Using a synthetic but structurally realistic hospital dataset and an open, ready-to-deploy prototype implementation, this study demonstrates the end-to-end orchestration of triage risk prediction, workflow optimisation, and compliance logging, achieving substantial simulated reductions in task turnaround times and manual documentation effort while maintaining policy-guarded data access. The resulting architecture offers hospital leaders a pragmatic blueprint to move from ad hoc tools to a governed, globally compliant, ROI-focused AI platform that can be tailored to on-premise, hybrid, and cloud-native deployments. Keywords: Agentic AI in Healthcare, Multi-Agent LLM Orchestration, Hospital Information Management System (HIMS), DISHA Compliance, DPDP Act, Policy-As-Code, AI Governance in Hospitals, Clinical Workflow Automation, Federated Learning in Smart Healthcare, Data Residency in Healthcare, AI-Driven Hospital Operations. How to Cite: Manideep Dhar; Ritwik Singh; Sharat Chandra Kumar Manikonda (2026) From Siloed Algorithms to Compliance‑First Agentic Platforms: A Multi‑Layered Architecture for Hospital AI Systems. International Journal of Innovative Science and Research Technology, 11(5), 2754-2795. https://doi.org/10.38124/ijisrt/26may1651 I.

INTRODUCTION

 The Background and Problem Context In the last decade, hospitals and healthcare industry worldwide has been witnessing an accelerated adoption of artificial intelligence (AI) across a wide range of clinical, operational, and financial functions, including emergency triage (a medical process for sorting patients based on the severity of their condition to prioritize treatment, particularly when resources are limited or patient volume is high), medical imaging, patient scheduling, discharge planning, coding, claims management, and workforce optimisation [1][2][3][4]. This surge is being driven by a combination of IJISRT26MAY1651

clinician shortages, rising documentation burden, margin pressure, growing patient expectations, and the increased maturity of machine learning, large language models, cloud platforms, and healthcare interoperability standards[5][6][7][8][9][10][11]. By principle, this technological convergence should enable hospitals to move from reactive administration to proactive, intelligent, and continuously learning systems of care. However, in practice, these systems are usually introduced as point solutions tightly coupled to specific applications, an imaging algorithm embedded in the Picture Archiving and Communication System (PACS) [12], a triage score integrated into the ED module, a separate scheduling optimizer, or a standalone

www.ijisrt.com

2754

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

documentation‑assist tool, rather than as components of an integrated hospital‑wide AI platform[13][14][15][16]. For understanding, let’s visualise a scenario where a radiology department may deploy an image interpretation model, the emergency department may adopt a triage risk scoring tool, operations may use a scheduling optimiser, and the revenuecycle office may procure an autonomous coding assistant, yet these tools might often operate on separate pipelines, separate governance assumptions, and separate integration patterns. As a result of which, hospitals are found to frequently invest in AI without creating a reusable data fabric, a common orchestration framework, or a unified compliance control plane[10][13][17][18][19]. Most deployments are narrow tools attached to a single vendor system or department rather than components of a coherent hospital management platform [20]. Systematic reviews exhibit that even advanced hospitals rarely move beyond individual algorithms integrated into specific workflows, with limited reuse of data pipelines, model governance, or monitoring capabilities across use cases [21][22][Table 1][Table 2]. This tool‑centric approach produces a fragmented landscape in which each department negotiates its own data feeds, interfaces, access controls, and logging arrangements [23]. These leads to duplicated model development, duplicated integration effort, inconsistent risk controls, and inability to accumulate institutional learning about AI

Dimension Clinical AI tools Data management Governance Intelligent automation Regulatory readiness

System EHR PACS LIS Billing Devices

Table 1 Core Problems Framing Out Due to Hospital AI Fragmentation Current situation Consequence Deployed as isolated applications Poor reuse, weak integration, workflow discontinuity Project-specific pipelines and Duplication, low lineage, poor extracts interoperability Distributed and inconsistent Uneven controls, weak auditability oversight Task-specific assistants without Limited scale and poor crosscoordination domain automation Control handled post hoc Delayed adoption, exposure to legal and operational risk

Architectural need Shared platform services Privacy-preserving data fabric Central compliance and policy layer Agent orchestration layer Compliance-by-design architecture

Table 2 Hospital Data Ecosystem Complexity Primary data AI integration challenge Clinical narrative Unstructured text DICOM images Massive storage Lab results Discrete events Claims data Financial rules Real-time vitals Streaming data

Concurrently, external market pressures intensify where, the global AI-in-healthcare market is projected to grow from roughly 39 billion USD in 2025 to more than 1,000 billion USD by 2034 [28][Figure 1], reflecting compound annual growth rates (CAGR) of about 39-40% in some

IJISRT26MAY1651

performance, safety incidents, organisational impact over time, and limited ability to reuse data pipelines, models, monitoring tools, or incident‑response procedures across use cases [16][22]. When AI systems are deployed in isolation, hospitals duplicate data engineering effort, duplicate vendor assessment processes, duplicate validation activities, and duplicate security reviews across departments [19], finally leading to a heap of non-value-added activities in the hospital management process. More critically, the absence of a common governance model makes it difficult to ensure consistent auditability, explainability, model monitoring, incident response, and policy enforcement across use cases [18][10][24]. What appears on the surface to be innovative progress may therefore conceal deeper architectural fragility, elevate technical debt, and increase regulatory exposure [25][26]. Clinicians experience AI as a proliferation of uncoordinated “apps” and alerts layered onto already complex workflows, while executives struggle to obtain a consolidated view of what AI systems exist, where they operate, and how they affect safety, quality, and cost [27][14]. The urgency of this problem is further amplified by the economics of modern healthcare delivery, where hospitals are being forced to improve throughput, reduce avoidable delays, optimise workforce allocation, and enhance patient experience under persistent cost pressure, which is evident across the world [5][8][7][Table 1][Table 2].

scenarios [28]. Yet surveys of providers and payers suggest that only about 30% of healthcare AI pilots reach production, and roughly 70% fail to scale beyond initial pilots, creating a widening “AI implementation gap” where expenditure and expectation grow faster than measurable impact [29][30][19].

www.ijisrt.com

2755

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 1 Projected Growth in the Market Size of Artificial Intelligence in the Healthcare Industry (Source:Fortune Business Insights)

Fig 2 Projected Global Healthcare AI Market and Value at Risk (2024-2035) The above predictive analysis [Fig] based on the market projection data [28], visualises the projected growth of the AIin-healthcare market, highlighting the scale of investment that risks being squandered if hospitals remain locked in siloed, point-solution deployments. Recent work has initiated to articulate hospital AI platform architectures that move beyond individual models, notably a five-layer model encompassing infrastructure, data, algorithm, application, and security and compliance layers [31][9]. Empirical mapping of dozens of hospital AI implementations to this framework shows relatively mature application and data layers but weaker investment in infrastructure and security/compliance, with loose coupling between governance and technical layers that undermines scale and sustainability [32][10]. At the same time, multi-agent LLM architectures show superior scalability to mixed clinical IJISRT26MAY1651

workloads, sustaining accuracy and limiting latency growth compared with single-agent designs, but these are rarely embedded into hospital platforms with explicit compliance guarantees [33][34]. Alongside, clinicians report rising administrative burdens where, in a large NHS Survey [35], clinicians spent on average 13.5 hours per week on documentation work in 2022 [36][Fig], which is over a third of their working time, and a 25% increase over seven years amplifying burnout and constraining capacity [37][16]. These intertwined trends create an urgent need for architectures that do not simply add more algorithms but systematically reshape how hospital AI is governed, integrated, and experienced [38][5]. When AI is introduced into this environment without platform discipline, it risks by becoming another layer of digital complexity rather

www.ijisrt.com

2756

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

than a mechanism for operational relief. The challenge, therefore, is not merely to build more accurate models, but to create an enterprise architecture through which AI can be deployed safely, reused efficiently, governed consistently, and scaled responsibly across the hospital ecosystem

[32][10][37]. This requires moving beyond the era of siloed algorithms toward compliance-first, agentic platforms designed specifically for real-world hospital information management systems and the high-stakes nature of regulated health data environments [5][38].

Fig 3 Average Weekly Clinician Time Spent on Documentation (Source: NHS Survey) In parallel, regulatory expectations have been hardened. The EU AI Act (European AI Act) [26] classifies many clinical AI systems as “high-risk” and mandates a documented, lifecycle-wide risk management system (Article 9) [39], robust data governance, logging, transparency, and post-market monitoring, effectively transforming AI platforms into regulated socio-technical systems rather than purely technical artefacts [18]. HIPAA’s Security Rule [40], GDPR’s special-category data rules [41], India’s DPDP Act 2023 [42][43], and sectoral laws such as the (forthcoming) Digital Information Security in Healthcare Act (DISHA) of India [44][45], collectively impose specific safety governance for electronic protected health information (ePHI), consent, data minimisation, breach notification, and cross-border transfers [46][47]. In this environment, an AI platform that treats governance as an afterthought is not only unsafe but increasingly non-viable.  The Opportunity Area and Its Urgency This research focuses on a critical opportunity: hospitals are increasingly adopting individual AI tools, yet often without a cohesive architectural blueprint aligned with hospital operations, healthcare data governance, and emerging regulatory frameworks [18]. The misalignment between how hospitals deploy AI, via isolated, departmentspecific solutions, and the regulatory, economic, and operational reality makes it imperative for the AI architecture to behave as an institution-wide, governed platform [22][29]. The gap is further accentuated by siloed algorithms amplifying data fragmentation, multiply integration interfaces, and making it exceedingly difficult to demonstrate traceable compliance with emerging AI-specific regulations, IJISRT26MAY1651

particularly when hospitals operate across jurisdictions or rely on hybrid cloud architectures [17][48][49]. Moreover, fragmented deployments fail to address the clinicians’ time poverty and operational bottlenecks in a systemic way, leading to incremental gains in a few workflows while the broader enterprise scape remains burdened by manual coordination, redundant documentation, and unmanaged risk [17][22][48]. Most of the deployments, which are designed around local functional goals rather than institutional interoperability, meaning the data, decisions, and controls remain trapped within departmental silos [13][17]. This exhibits to produce duplicated work, inconsistent guardrails, weak lifecycle oversights, poor reusability of data assets, and escalating integration complexity over time [10][48]. Foundational healthcare interoperability standards such as Health Level Seven Version 2 (HL7v2) [50] which is one of the oldest and most widely used messaging standards in healthcare and enables real-time data exchange between hospital systems (e.g., EHR, lab, pharmacy). Digital Imaging and Communications in Medicine (DICOM) which is the standard for medical imaging data and can be defined as the universal language of medical images which combines image files with embedded metadata (patient info, scan type, etc.) [51], and Fast Healthcare Interoperability Resources (FHIR) a modern standard of healthcare interoperability designed for the web era and a future-ready API layer for healthcare data which enables API-based data exchange using RESTful services [52][53], together have improved interoperability but have not eliminated semantic variation, idiosyncratic local customisations, or differences in data quality [54][55].

www.ijisrt.com

2757

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Studies of AI deployment in hospitals consistently report that data discovery, mapping, cleaning, and reconciliation consume the majority of project effort, often 60%–80% of total time [56][57]. Because these pipelines are usually built on a per‑project basis, using bespoke scripts and intermediate data stores, they are difficult to maintain and reuse. Changes in upstream systems can silently break downstream models, and the absence of shared semantics or lineage tracking makes troubleshooting slow and error‑prone [10][58]. For AI, this fragmentation manifests as a proliferation of “shadow data fabrics”—ad hoc collections of data extracts and feature tables maintained by individual teams. These may bypass formal governance mechanisms and rarely provide consistent enforcement of access controls, masking rules, or audit logging. A key architectural gap, therefore, is the lack of a formal, privacy‑preserving data fabric that provides standardised, policy‑aware access to HIMS data for all AI use cases [10][59][60]. Simultaneously, several powerful technological streams are maturing in parallel, including large language models, agentic AI, federated learning, privacy-preserving machine learning, compliant cloud computing, policy-as-code systems, and modern interoperability frameworks such as FHIR and eventdriven integration [61][62][63][64][65]. Yet these capabilities are usually discussed separately in literature, procurement, or implementation roadmaps, with little consensus on how they should be assembled in a practical, effective and meaningful way into a hospital-specific and compliance-first platform model. Without a unifying, compliance-first, agentic platform, rather than a patchwork of tools, hospitals are surfaced to risks of compounding technical debt, regulatory exposure, and staff burnout at precisely the moment when demographic shifts and fiscal constraints demand productivity gains [5][49][58]. The combination of skyrocketing AI market investments, persistent data silos, and rising regulatory stakes creates a now-or-never window for architectural reset. The absence of such an architectural blueprint is increasingly dangerous because hospitals are beginning to deploy AI into high-impact workflows where clinical quality, patient safety, revenue integrity, cybersecurity, and legal accountability intersect directly [5][49][58][66]. This research study argues that the next generation of hospital AI must be conceived not as a collection of intelligent applications, but as a layered digital platform in which orchestration, governance, privacy-policy, interoperability, and compliance are integrated into the architecture under one unified strong platform. In this view, hospital AI maturity is not determined solely by the performance of the developed model and the architecture, but by the institution’s ability to govern AI services across their full lifecycle from data ingestion to post-deployment and production stage monitoring.  Regulatory Standards Landscape  HIPAA Security Rule and US Hospital Obligations: In the United States, the HIPAA Security Rule defines administrative, physical, and technical safeguards for protecting Electronic Protected Health Information (ePHI), IJISRT26MAY1651

requiring covered entities and business associates to implement risk analysis, access control, audit logging, integrity controls, and transmission security [40][67]. Administrative safeguards mandate security management processes, workforce training, and incident response; physical safeguards govern facility access, workstation security, and device/media handling; and technical safeguards encompass authentication, encryption, audit controls, and automatic logoff [67][68]. While HIPAA remains technologyneutral, AI systems that access or interfere or manipulate with ePHI must inherit these safeguards, making logging, access control, and secure hosting foundational concerns for any hospital AI platform [69].  GDPR Special-Category Data Classification, and EU AI Act: In Europe, General Data Protection Regulation (GDPR) classifies health data including PHI as special-category personal data, requiring explicit consent or a clear legal basis, strict purpose limitation, data minimisation, and enhanced data subject rights, including access, rectification, and erasure [41][46]. The EU AI Act [49] further designates most clinical decision-support, diagnostic, and risk stratification systems as high-risk AI systems, subject to lifecycle-wide risk management (Article 9) [39] data and data governance requirements (Article 10) [49], technical documentation, transparency, logging, and post-market monitoring [49]. High-risk systems must be designed with iterative risk management processes that identify foreseeable risks, define risk controls, and continuously update mitigations based on operational data, fundamentally aligning AI platforms with medical-device-style governance [24][70].  DISHA and DPDP Act in India: The Ministry of Health and Family Welfare (MoFHW) of India has proposed a Digital Information Security in Healthcare Act (DISHA) [[44]], which while writing this research is in process to be enforced, aims to establish dedicated national and state health authorities, standardise the generation, collection, storage, transmission, and use of digital health data, and impose strict prohibitions on unauthorised or commercial reuse of health information, even when anonymised [45][71]. DISHA emphasises patient ownership of digital health data, mandates consent, and prescribes penalties, including potential imprisonment and uncapped compensation, for serious breaches of digital health data [44][71]. This research strongly advocates this governance proposal and suggests the act to be enforced to ensure the implementation and transformation with AI is governed by structured governance regulations. Complementing this, the Digital Personal Data Protection Act 2023 (DPDP Act 2023) [42][43] sets crosssector rules for digital personal data, including explicit consent, purpose specification, data minimisation, security safeguards, breach notification, and rights to erasure [42][43], all of which directly affect hospital AI systems processing identifiable health data [18]. For Indian hospitals, the convergence of DISHA and DPDP implies that AI platforms

www.ijisrt.com

2758

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

must provide end-to-end traceability for data flows, enforce consent and purpose constraints, and support data localisation and retention controls, especially when using cloud services or cross-border AI models.

GDPR [41], and the EU AI Act [49] are translated into enforceable system capabilities, including fine-grained access control, immutable audit logging, data lineage tracking, and policy-aware orchestration.

 ISO/IEC 27001, ISO/IEC 27002 ISO 14971, ISO 13485, IEC 62304, and ISO 42001: International Standards Organization provide additional anchors for hospital AI platforms. ISO/IEC 27001 [72] and ISO/IEC 27002 [73] specifies the requirements for an information security management system (ISMS), including risk assessment, security policy, asset management, access control, incident response, and continuous improvement [72][73], where healthcare organisations increasingly use ISO/IEC 27001 and ISO/IEC 27002 certifications to demonstrate robust data security and alignment with HIPAA [40][74].

From a systems perspective, this implies that every interaction with hospital data, whether initiated by a human user, an AI model, or an autonomous agent, must be mediated through a governed control plane. Such a control plane enforces consent constraints, purpose limitation, and jurisdictional policies dynamically at runtime, rather than relying on static configuration. This is particularly critical in environments where hybrid cloud architectures and crossborder data flows are common.

ISO 14971 [24] and ISO 13485:2016 [75] defines principles and processes for risk management of medical devices, including software, across the entire lifecycle [24], requiring identification of hazards, estimation and evaluation of risks, implementation of risk controls, and monitoring of residual risk acceptability [70][75] for the hospitals to ensure the medical devices including AI implementation are complying with the standard. IEC 62304 [76] specifies lifecycle processes for medical device software, demanding structured planning, requirements management, risk-informed design and testing, configuration management, and controlled maintenance, and is increasingly applied to clinical-grade decision-support and imaging systems [76][77]. Emerging standards such as ISO/IEC 42001 on AI management systems emphasise governance and organisational controls for AI [78], reinforcing the notion that AI platforms must be embedded in management systems rather than just treating as stand-alone tools [79]. Collectively, these standards imply that hospital AI platforms should expose auditable linkages between hazards, risks, controls, and software artefacts across layers, something ad hoc deployments rarely achieve.  Compliance-by-Design as a Foundational Architectural Principle The convergence of regulatory frameworks across jurisdictions reveals a consistent pattern where governance expectations are no longer peripheral constraints but core architectural requirements. Traditional approaches that treat compliance as a post hoc validation layer are fundamentally misaligned with modern healthcare AI systems, where data flows, model decisions, and operational actions are deeply intertwined. A compliance-by-design paradigm proposes that regulatory controls be embedded directly into the architecture of hospital AI platforms, rather than implemented as external overlays. Under this approach, principles derived from frameworks such as the U.S. Department of Health & Human Services HIPAA Security Rule [40], the European Union IJISRT26MAY1651

Equally important is the integration of lifecycle governance mechanisms. Drawing on standards such as ISO 14971 [24] and IEC 62304 [76], AI systems must maintain traceable linkages between data inputs, model outputs, risk controls, and operational outcomes. This enables continuous monitoring, post-deployment validation, and regulatory auditability, aligning AI platforms with medical-device-grade expectations. Furthermore, emerging AI-specific standards such as ISO/IEC 42001 [78] reinforce the need to treat AI not merely as a technical capability but as a managed organisational system. This shifts the architectural focus toward accountability, transparency, and continuous risk management across the full lifecycle of AI deployment. In practice, compliance-by-design transforms the hospital AI platform into a policy-aware, audit-ready, and risk-governed system, where governance is enforced programmatically and consistently across all use cases. Without such an approach, hospitals risk fragmented compliance, inconsistent enforcement, and escalating regulatory exposure as AI adoption scales.  Role of Agentic AI in Hospital Systems Recent advances in large language models (LLMs) and multi‑agent AI architectures have shifted attention from static models toward agentic systems that can perceive, reason, act, and collaborate with other agents and tools [33][61]. In contrast to monolithic models that simply map inputs to outputs, agentic AI systems decompose tasks into subtasks, maintain internal state across steps, call APIs and knowledge sources, and exchange messages with other agents under the control of an orchestrator [80][81]. In hospital environments, many high‑value workflows are inherently multi‑step and cross‑functional, making them natural candidates for agentic approaches. For example, an emergency department (ED) workflow might involve a triage risk agent synthesising vitals, symptoms, comorbidities, and prior utilisation to produce a risk score; a coordination agent sequencing imaging, laboratory, and bed‑assignment tasks; a documentation agent drafting notes and discharge summaries; and a billing agent ensuring that documentation supports appropriate coding [62][81][82]. Similar patterns exist in oncology care pathways, peri‑operative coordination, and chronic disease management, where decisions and tasks span multiple systems and teams [83][84].

www.ijisrt.com

2759

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Empirical studies in non‑clinical and early clinical contexts suggest that orchestrated multi‑agent systems can maintain accuracy under higher load and more heterogeneous task mixes than single‑agent configurations, while also reducing token usage and latency by delegating subtasks to specialised agents [33][85]. Industry case studies describe multi‑agent patterns in which a planner agent decomposes problems, domain agents call EHR or knowledge tools, and critic agents verify outputs against source data before results are presented to clinicians [86]. However, these technical advances have largely outpaced architectural and governance frameworks; most published work focuses on capabilities and benchmarks rather than on how agentic systems will be safely embedded into hospital IT environments governed by strict health‑data and medical‑device regulations [18][66][70].  Research Objectives This research pursues four interlinked objectives:

 

 

 To design a hospital-specific, multi-layered AI platform architecture that explicitly integrates an Agent Orchestration Layer, a Compliance and Policy Layer, and a Privacy-Preserving Data Fabric into, and across, the existing infrastructure, data, algorithm and application stacks.  To map each architectural layer to concrete regulatory obligations and industry standards, including HIPAA Security Rule safeguards [40]; GDPR special-category data rules [41]; EU AI Act [49] risk management, logging, and post-market monitoring clauses; India’s DISHA [44] and DPDP Act [42][43] requirements; and ISO/IEC 27001 [72] and ISO/IEC 27002 [73], ISO 14971 [24], and IEC 62304 [76] mandates.  To develop, present and implement a functional, ready-todeploy solution architecture that embodies the intended objectives, including a privacy-aware data fabric, policy engine, multi-agent orchestrator, and triage risk model trained on synthetic but structurally realistic data, to protect and uphold the protection Personal Identifiable Information (PII) and protected health Information (PHI), so that the model is not immature or inefficiently trained before putting into real-world functioning.  To evaluate the model in a controlled and governed hospital setting by quantifying the workflow time savings, documentation reduction potential, and governance coverage, thereby illustrating the business and safety impact of a compliance-first agentic platform compared with isolated tools.  These layers are intended to create a practical architectural bridge between AI innovation and enterprise-grade hospital deployment. By tightly coupling the architectural design, regulatory mapping, and a working implementation, the research aims to provide both an intellectually rigorous contribution and a practically actionable blueprint for hospital leaders.  Study Objectives The study is guided by the following objectives:  First, to examine why current hospital AI deployments remain fragmented despite rapid advances in healthcare IJISRT26MAY1651





AI technologies. To answer the question: why do current hospital AI deployments fail to scale efficiently beyond isolated use cases? Second, to identify the architectural, governance, compliance, and interoperability gaps in existing hospital AI platform models. Third, to propose a novel multi-layered architecture that supports reusable AI services across clinical, operational, and financial domains. Fourth, to position agentic AI orchestration as a distinct hospital platform capability rather than an applicationspecific add-on. And find the answer for: how can agentic AI be governed safely within hospital workflows that involve sensitive data and high-risk decisions? Fifth, to define how policy-as-code and regulatory obligations can be embedded into the architecture through a dedicated compliance layer. Sixth, to integrate privacy-preserving machine learning models into hospital data flows through a governed data fabric model, while mining the answer for: how can privacy-preserving machine learning capabilities be integrated into routine HIMS operations without undermining utility or compliance? Seventh, to establish a foundation for global acceptability through alignment with major regulatory and standards frameworks relevant to healthcare AI. Further resolving the question: how can a hospital AI architecture be explicitly mapped to major health data protection, safety, software, and AI governance requirements across multiple jurisdictions?

 Scopes of the Proposed Architecture The architecture proposed in this study is intentionally hospital-specific rather than generic enterprise AI design. It is built to accommodate the realities of hospital information ecosystems, including fragmented source systems, mixed cloud and on-premise deployments, high sensitivity of protected health information, stringent auditability requirements, varied clinical workflow patterns, and multistakeholder governance structures. It is also designed to support region-specific deployment variants, including onpremise and localisation-sensitive configurations for India, hybrid-residency approaches for Europe, HIPAA-eligible cloud patterns for the United States, while keeping enough headroom for continent or country specific governance and privacy policies that can be incorporated for any hospital across the world. The proposed model is not restricted to a single use case or specialty. Instead, it is designed as a reusable platform that can support triage systems, radiology workflows, bed and theatre scheduling, clinical documentation support, coding assistance, discharge coordination, procurement intelligence, workforce planning, and other future AI-driven hospital functions.  Identified Gaps  Platform specificity: Generic models ignore HIMS complexity  Agent orchestration: No hospital-grade coordination layer  Privacy integration: Techniques isolated from data flows  Compliance mapping: High-level, not layer-specific

www.ijisrt.com

2760

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 Global deployment: No multi-jurisdiction blueprint Our research aims to address these gaps with a novel and structural approach.  Novelty and Contribution The novelty of this research lies in its initiative to close the gap between abstract AI platform theory and the operational realities of hospitals. While many technical studies discuss model performance, interoperability, or governance in isolation, relatively few define an integrated architecture that couples AI layers directly to concrete compliance obligations, workflow orchestration logic, and privacy-preserving data movement. This research therefore contributes a hospital-ready blueprint that treats compliance, orchestration, and privacy not as peripheral considerations, but as core architectural primitives. A second contribution lies in the explicit recognition of agentic AI as a hospital platform concern. Rather than treating multi-agent systems as experimental task automation tools, this research places them within a governed enterprise environment in which agents must communicate through controlled interfaces, respect and abide by policy constraints, and remain observable across their lifecycle. A third contribution lies in the architectural operationalisation of regulatory readiness. Instead of presenting regulations such as HIPAA [40], GDPR [41], the EU AI Act [26], DPDP Act, India [42][43], DISHA Act, India [44], and related standards as external constraints, this study translates them into design requirements that shape the internal structure of the platform. This shift is essential if hospitals are to move from reactive compliance to proactive compliance-by-design. II.

LITERATURE REVIEW

 The Shift from Isolated Algorithms to Integrated Platforms The contemporary landscape of healthcare AI is characterized by a "pilot paradox," where significant investments in individual algorithms frequently fail to translate into enterprise-scale value [32]. While early successes in medical imaging and triage proved the technical viability of AI, recent literature suggests that the lack of a unified integration blueprint has led to fragmented "point solutions"[10]. Secinaro et al. (2021) [87] advocated for a transition toward structured, multi-functional AI roles within hospital management, arguing that AI’s true potential lies in reshaping operational practices rather than merely improving discrete clinical tasks [87]. Their work supports the transition from siloed tools to a broader hospital-specific platform that enhances efficiency and patient care [87]. Conversely, much of the early literature focused on the performance of single-purpose models, often overlooking the architectural overhead of maintaining multiple disparate systems [88]. Matheny et al. (2019) [89] highlight the "peril" of uncoordinated AI adoption, noting that without a shared governance framework, hospitals risk duplicating data engineering efforts and vendor assessment processes [89]. This fragmentation, identified as a structural barrier in the current research, suggests that the era of "narrow tools" is reaching its limit. IJISRT26MAY1651

 Multi-Agent Systems and Orchestration in Healthcare The emergence of agentic AI represents a paradigm shift from reactive software to proactive and autonomous systems capable of reasoning and planning [90]. Recent advancements in Agent Coordination and Ranking Frameworks (ACRF), as discussed in Exploring Agentic AI in Healthcare (2025) [91], demonstrate the power of multiagent systems to solve complex tasks by resolving dependencies between specialized agents [91]. This study strongly advocates for an "Agent Registry" and "Audit Layer," mirroring the proposed Agent Orchestration and Compliance layers in this research. Such platforms allow for the synchronization of patient data across clinical and operational domains, autonomously adjusting treatment plans and managing resources. However, some scholars argue that the rush toward autonomous agentic systems often outpaces the development of necessary ethical and regulatory safeguards [18]. Petersson et al. (2022) [92] critique the rapid implementation of AI in healthcare settings without robust, standardized deployment protocols [92]. They argue that even in advanced healthcare systems, leaders face significant qualitative barriers, such as unclear accountability and the absence of site-specific revalidation, which can lead to "model drift" and safety incidents if agents are allowed to operate without a centralized policy-as-code control plane [92].  Compliance, Privacy, and Regulatory Challenges A primary reason for the failure of 70–80% of AI pilots to scale is the "governance gap" [32]. The introduction of the EU AI Act [26] and India’s DPDP Act, 2023 [42][43] has created a complex regulatory environment that requires more than just technical accuracy. Mohammad Amini et al. (2023) [93] emphasize that AI ethics and challenges, particularly under the GDPR mandate, require a comprehensive understanding of data sovereignty and transparent model construction [93]. They advocate for a "compliance-bydesign" approach, supporting the integration of privacypreserving data fabrics to protect Personal Identifiable Information (PII) and Protected Health Information (PHI) [60][93]. In contrast, traditional governance models are often criticized for being too rigid or non-aligned with the speed of AI innovation [94]. The OECD report on Scaling Artificial Intelligence in Health (2024) [95] points out that fragmented data foundations and non-aligned policies continue to act as major barriers [95]. While some literature suggests that decentralized governance is sufficient for low-risk tools [79], our research argues that and suggests with evidence that only a centralized, compliance-first architecture can bridge the gap between innovation and the high-risk requirements of a hospital environment.  Privacy-Preserving Machine Learning Federated learning has emerged as a robust paradigm for enabling collaborative model development across multiple healthcare institutions, without necessitating the centralization of sensitive patient data [96]. McMahan et al., (2017) [97], in their study discussed that in the decentralized

www.ijisrt.com

2761

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

framework, participating entities locally train models and share only model parameters or gradients, which are subsequently aggregated to form a global model, thereby preserving data locality and confidentiality [97]. To further strengthen privacy, Dwork et al., (2014) [98] explored the techniques such as differential privacy which introduces controlled noise into the shared parameters [98]. This technique ensures that individual-level information remains unidentifiable even during collaborative training [98][99]. Complementing this, secure multi-party computation facilitates cryptographically protected aggregation processes, as exhibited by Bonawitz et al., (2017) [100][101]. This technique allows multiple parties to jointly compute model updates without revealing their underlying data to one another [100][101]. Within the healthcare domain, as discussed in the work of Rieke et al., (2020) [102], federated learning has demonstrated significant applicability across a range of use cases, including medical imaging diagnostics, predictive risk modelling, and large-scale population health analytics [102]. However, despite its promise, several technical challenges persist. Notably, the presence of non-independent and identically distributed (non-IID) data across institutions, which can adversely impact model generalization and convergence behaviour [103]. Additionally, the work of Kairouz et al., (2021) [104] highlights the iterative communication required between distributed nodes introduces considerable overhead, raising concerns regarding scalability and efficiency [104]. These factors collectively complicate the optimization process and necessitate advanced strategies to ensure stable and performant model convergence in real-world deployments [104].  Scape of Agentic AI in Healthcare Agentic artificial intelligence, particularly systems powered by large language models (LLMs), introduces a paradigm wherein complex healthcare tasks are decomposed into smaller, manageable sub-tasks executed through autonomous or semi-autonomous agents [90]. Wang et al., (2023) [105] demonstrated how such architectures are especially well-aligned with hospital workflows, which inherently involve sequential and interdependent processes. Clinical operations such as triage, care coordination, clinical documentation, and medical coding exemplify multi-stage workflows that necessitate iterative reasoning, contextual awareness, and task orchestration [105]. Despite the growing body of research in this domain, the majority of existing studies predominantly emphasize single-agent performance, focusing on isolated task execution rather than collaborative intelligence [105]. Consequently, the challenges associated with multi-agent coordination, particularly within the constraints of hospital environments, remain insufficiently explored. Specifically, the study of Park et al., (2023) [106] structurally discussed that there is a notable absence of well-defined governance frameworks that address role delineation, accountability, and decision hierarchies among interacting agents in clinical settings [106]. IJISRT26MAY1651

Furthermore, the effective deployment of agentic systems in healthcare necessitates seamless integration with Hospital Information Management Systems (HIMS), requiring tool-calling mechanisms that are contextually aware of clinical data standards, workflows, and interoperability protocols [11]. As advocated in the study of Singh et al., (2024) [107], current implementations often lack such domain-specific interface abstractions, limiting their practical applicability. Additionally, the human-in-the-loop oversight, which is critical for ensuring safety, ethical compliance, and clinical validation, remains inadequately specified in the established literature and has been discussed in the work of Borghoff et al., (2025) [108], particularly in terms of override mechanisms, escalation pathways, and auditability [108]. These gaps underscore the need for more comprehensive architectural and governance models tailored to agentic AI adoption in healthcare environments.  Multi-Agent Systems in Healthcare The emergence of large language models (LLMs) has significantly accelerated interest in agentic artificial intelligence, wherein intelligent agents are capable of iterative reasoning, tool invocation, memory retention, and collaborative interaction to accomplish complex objectives [109]. Both the works of Qiu et al., (2024) [109] and Park et al., (2023) [34] evidently demonstrated how such agent-based paradigms are particularly well-suited to healthcare environments, especially hospital systems, where workflows are inherently distributed across multiple roles, information systems, and decision nodes. A typical patient journey, encompassing intake, triage, diagnostics, scheduling, clinical documentation, coding, authorization, discharge planning, and follow-up, can be systematically decomposed into coordinated, agent-level tasks, thereby aligning naturally with multi-agent system architectures [34][110]. Despite its growing relevance, the current study on agentic AI in healthcare remains nascent and largely exploratory. Much of the existing research is either conceptual in nature, experimental in controlled settings, or narrowly focused on isolated automation scenarios rather than end-to-end workflow orchestration. Emerging evidences like the studies of Wu et al., (2023) (AutoGen) [33] suggests that agentic systems can enhance task decomposition, reduce latency in administrative coordination, and improve the efficiency of complex workflow automation when supported by structured tool access and inter-agent coordination mechanisms [33]. However, these studies often overlook the critical hospital-specific requirements, including system observability, human-in-the-loop override capabilities, identity-aware access control, policy-constrained execution, and audit-grade traceability, each of which is essential for safe and compliant deployment in clinical environments Kairouz et al., (2021) [104]. This omission represents a substantial gap in both research and practice. The introduction of multi-agent intelligence without corresponding governance frameworks may inadvertently amplify operational and clinical risks rather than mitigating them [18][111]. Agents capable of retrieving sensitive data, invoking external tools, generating

www.ijisrt.com

2762

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

clinical summaries, triggering downstream processes, or altering workflow states must operate within clearly defined and enforceable policy boundaries, which has also been discussed in the published work of Shneiderman, (2020) [112]. Nevertheless, the literature seldom articulates a formalized architectural construct, such as a hospital-specific Agent Orchestration Layer that governs agent communication, execution control, and compliance enforcement as a reusable platform capability. Addressing this critical gap forms a central contribution of the present study, which seeks to establish a structured and governanceaware foundation for deploying agentic AI systems in healthcare settings.  AI Governance, Safety, and Compliance Literature The discourse on AI governance in healthcare has evolved from a peripheral consideration to a central pillar of both research and policy, reflecting the high-stakes nature of clinical environments where safety, fairness, accountability, security, and regulatory compliance are intrinsically linked to system performance [18]. Recent governance-oriented publication by Johnson et al., (2024) [113] systematically highlights key dimensions such as model lifecycle management, drift monitoring, validation documentation, human oversight, bias evaluation, and incident response as essential components of responsible healthcare AI deployment [113]. Contemporary studies of Topol, (2019) [9] and Rajkomar et al., (2018) [114] increasingly emphasizes comprehensive governance across the AI lifecycle, including model validation, drift monitoring, documentation practices, human oversight, bias evaluation, and incident management [9][114]. These dimensions underscore the necessity of embedding governance mechanisms not only during development but throughout deployment and operational phases. Concurrently, the regulatory landscape governing healthcare AI has become significantly more structured and stringent. Data protection frameworks such as the General Data Protection Regulation (GDPR) [41] and EU AI Act [49] and the Health Insurance Portability and Accountability Act (HIPAA) [40] impose strict requirements concerning consent management, purpose limitation, data minimization, access control, and breach notification. In parallel, AI-specific

governance guidelines, such as those proposed by the World Health Organization [13][18] and the European Commission EU AI Act [49], advocate for transparency, explainability, risk management, and human-in-the-loop oversight in AI systems. Additionally, software and information security standards, including ISO/IEC 27001 and ISO/IEC 27002 [72][73] and ISO 13485:2016 [75], further extend governance expectations into areas such as secure software lifecycle management, risk assessment, and compliance auditing. Despite these advancements, a critical limitation persists within the existing body of governance literature: its predominant focus on principles rather than implementation architecture. While numerous studies articulate what aspects of AI systems should be governed, they often fall short in specifying where governance responsibilities should be embedded within system design, how these controls should interface with orchestration layers, and how policy constraints can be operationalized as enforceable, runtime mechanisms. This gap highlights the absence of a cohesive architectural paradigm that integrates governance directly into the technical fabric of AI systems. Addressing this limitation, the present work reconceptualizes governance as a dedicated architectural layer, positioned alongside core system components, thereby enabling policy enforcement, observability, and compliance to function as intrinsic, systemlevel capabilities rather than solely as external or institutional oversight functions. The literature review reveals five major gaps that justify the present study. First, existing hospital AI platform models remain too generic and do not fully account for the complexity of hospital information management systems and regulated health data operations. Second, most studies have exhibited not to define a dedicated orchestration layer for agentic or multi-agent hospital workflows. Third, privacypreserving machine learning is usually studied as a technical method rather than as an integrated hospital data architecture capability. Fourth, governance and compliance are frequently described as high-level principles rather than executable architecture functions. Fifth, very few research publications provide a globally adaptable deployment blueprint within one hospital AI reference model [Table 3][Figure 4].

Table 3 Literature Review and Gap Analysis and How this Research Aims to Address it. Literature Theme What Existing Studies Do Well What Remains Insufficient How This Study Responds Hospital AI platforms Recognise need for layered Often too generic for real Proposes hospital-specific architecture HIMS complexity multi-layer blueprint AI use-case studies Show task-level performance Do not solve enterprise reuse Connects use cases to reusable potential and governance platform layers Privacy-preserving ML Strong focus on federated and Weak connection to full Embeds these methods in a secure learning hospital architecture governed data fabric Governance literature Defines principles and oversight Rarely operationalises policy Introduces Compliance and needs as executable architecture Policy Layer Agentic AI Demonstrates workflow Lacks hospital-grade Introduces dedicated Agent automation potential orchestration control model Orchestration Layer

IJISRT26MAY1651

www.ijisrt.com

2763

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 4 Literature Gap Matrix Map Visualising the Coverage of Key Dimensions Across Hospital AI Research Streams These gaps are not academic trivialities. They directly affect whether hospitals can move from pilot-stage experimentation to trustworthy, scalable, economically meaningful AI adoption. This research strongly suggests that what hospitals now need is not another isolated model, but a platform architecture that can institutionalise AI safely across departments, jurisdictions, and workflow categories.

Furthermore, industry analyses [115][116][117] consistently indicate that a majority of healthcare AI initiatives fail to transition from pilot to production environments.

Fig 5 Representation of Major Industry Consensus on Pilot-to-Production Conversion Rates in Healthcare AI [115][116][117] The low conversion of pilots-to-production [Fig] reflects architectural and governance fragmentation, reinforcing the need for unified, platform-based approaches to healthcare AI deployment. While a significant proportion of healthcare AI initiatives fail to transition from pilot to

IJISRT26MAY1651

production, this limitation is not merely operational but reflects a deeper structural imbalance between rapid AI adoption and the slower evolution of governance frameworks [115][116][117].

www.ijisrt.com

2764

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 6 Illustrative Visualisation Based on Trends Reported in JMIR (2024–2025) and Related Literature on AI Adoption and Governance in Healthcare [118][119]. The high attrition of AI pilots is symptomatic of a broader structural issue, where the pace of AI adoption in healthcare far exceeds the maturity of governance and oversight mechanisms [Fig][118][119]. Taken together, the literature review points in a clear direction. Hospitals do not merely need more AI applications; they need an institutional architecture capable of governing intelligence as a reusable, compliant, and interoperable service. Existing studies provide strong foundations in isolated areas such as platform layering, federated learning, interoperability, or governance, but they stop short of combining these elements into a hospital-specific, compliance-first, agentic platform blueprint. That unresolved space is where the present study is positioned. The literature review therefore supports the central argument of this research, which is, the future of hospital AI depends less on whether hospitals can procure individual intelligent tools, and more on whether they can architect a trusted platform in which those tools, agents, datasets, and controls can operate as one governed ecosystem. III.

PROPOSED MULTI-LAYERED COMPLIANCE-FIRST AGENTIC ARCHITECTURE







 Overview of Layers The proposed architecture defined by seven conceptual layers, grouped into five to seven deployable tiers depending on healthcare institutional maturity:  Infrastructure and Runtime Layer – Serves as the foundational layer comprising compute, storage, and networking resources along with secure execution IJISRT26MAY1651





environments. These may be deployed on-premise, within private cloud setups, or on public cloud platforms compliant with HIPAA [40] and GDPR [41], with optional support for hardware-based secure enclaves [Fig]. Privacy-Preserving Data Fabric Layer – Provides standardized, policy-driven access to data across HIMS/EHR, Laboratory Information Systems (LIS), Picture Archiving and Communication Systems (PACS), and financial platforms, while incorporating deidentification mechanisms, data quality pipelines, federated learning (FL) orchestration endpoints, and secure enclave connectors [Fig]. Model and Analytics Layer – Encompasses reusable model registries along with services for training, evaluation, and monitoring, supporting classical machine learning, deep learning, and LLM-based components, while maintaining metadata related to data provenance, performance, and risk characteristics [Fig]. Agent Orchestration Layer – Functions as a multi-agent execution environment where orchestrators, domainspecific agents, and safety or critic agents interact using shared schemas and tools, including HIMS integrations, knowledge retrieval systems, and computational utilities [Fig]. Application and Workflow Layer – Clinical, operational, and financial applications that embed agentic workflows into EHR front-ends, clinician worklists, imaging workstations, and revenue-cycle dashboards, using standards such as FHIR and SMART-on-FHIR where feasible [Fig]. Compliance and Policy Layer – Acts as a centralized governance and policy-as-code framework that translates regulatory standards such as HIPAA [40], GDPR [41], EU AI Act [26], DISHA Act [44], DPDP Act [42][43], ISO/IEC 27001 [72], ISO/IEC 27002 [73], ISO 14971

www.ijisrt.com

2765

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

[24], and ISO/IEC 62304 [76], along with institutional policies, into enforceable rules governing data access, tool usage, logging, and lifecycle management [Fig].  Governance, Risk, and Assurance Layer – Encompasses cross-cutting capabilities such as AI risk management, model inventory oversight, incident handling, post-

deployment monitoring, audit readiness, and stakeholder reporting, aligned with ISO 42001[78] and broader organizational risk management frameworks [Fig].

Fig 7 Illustration of the Proposed Multi-Layered Architecture Defined by Seven Conceptual Layers A key design choice is to treat Layers 6 and 7 not as peripheral “top layers” but as control planes that shape how all other layers are configured, monitored, and adapted over time, ensuring that compliance and risk appetite drive technical design rather than the reverse [Fig].  Privacy-Preserving Data Fabric The Privacy-Preserving Data Fabric provides standardized, policy-aware data access across systems. In the prototype, it wraps synthetic CSV datasets representing workflow events and triage encounters, but its API mirrors a production setting: encounter-scoped retrieval of vitals, history, and workflow tasks, with role- and purpose-aware views [Fig].

for both model training and real-time agentic workflows [Fig].  Offer connectors for FL orchestrators, where training jobs are sent to data-holding hospitals and only aggregated model updates return, complying with data localization and minimization principles [Fig].  Provide de-identification, pseudonymization, and column-level masking services tailored to jurisdictional rules and institutional policies [Fig]. By centralizing these capabilities, the data fabric reduces redundant ETL pipelines, shrinks time-todeployment for new AI services, and supports consistent application of privacy and security controls.

 In a Full Deployment, the Data Fabric Would:  Integrate with HIMS/EHR via FHIR resources and HL7 interfaces, mapping them into internal schemas optimized

IJISRT26MAY1651

www.ijisrt.com

2766

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 8 Visual Representation of the Privacy-Preserving Data Fabric Layer Operational Workflow  Agent Orchestration Layer The Agent Orchestration Layer manages the life cycle of agentic workflows across triage, imaging, bed management, discharge planning, and revenue cycle operations [Fig]. In the prototype implementation, this layer includes:  An encounter-level orchestrator that receives a request (e.g., “assess triage risk and optimize tasks for encounter E00001”) and composes a plan across specialist agents [Fig].

 A Triage Risk Agent that consumes structured vitals and history from the data fabric and invokes a trained risk model to produce a high-risk probability and flag [Fig].  A Workflow Optimization Agent that analyses task-level durations and cost metrics from the workflow events dataset to identify high-impact bottlenecks and suggest reordering or automation candidates [Fig].  A Compliance Logging Agent that records each orchestration event, including user role, purpose, jurisdiction, and participating agents, into an immutable audit log accessible to governance teams [Fig].

Fig 9 Visual Representation of the Agent Orchestration Layer Operational Workflow

IJISRT26MAY1651

www.ijisrt.com

2767

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Empirical research on multi-agent LLM designs indicates that such orchestration can maintain accuracy under load and produce transparent audit trails by constraining agents to specific tools and short, structured prompts [62][105]. While the proposed architecture uses a tabular triage model rather than a live LLM, the orchestration patterns and interfaces are designed to be LLM-ready, allowing hospitals to plug in compliant, domain-tuned LLM agents when regulatory and operational conditions permit.  Compliance and Policy Layer The Compliance and Policy Layer expose a policy-ascode engine that mediates all sensitive operations: data access, model invocation, external API calls, and logging. Policies are parameterized by User Role (e.g., ED_physician, billing_clerk), Purpose (e.g., clinical_decision_support, model_training), and Jurisdiction (e.g., US, EU, IN), enabling differentiated enforcement for, say, a German radiologist versus an Indian revenue-cycle analyst [Fig].

 Example Policies Include:  Blocking use of identifiable EU patient records for centralized model training, requiring FL or differential privacy-based methods instead, in line with GDPR and EU AI Act expectations [Fig].  Enforcing least-privilege access to financial and clinical data for billing clerks, consistent with HIPAA’s minimum necessary standard and ISO 27001 and ISO 27002 accesscontrol controls [Fig].  Prohibiting commercial reuse of Indian digital health data under DISHA and DPDP (e.g., for marketing) regardless of de-identification, while allowing secure, consented sharing with other clinical establishments via health information exchanges [Fig]. By embedding these constraints into an evaluable engine rather than scattered policies, the architecture supports demonstrable compliance during audits and keeps regulatory evolution (e.g., EU AI Act implementing acts) decoupled from application code [Fig].

Fig 10 Visual Representation of the Compliance and Policy Layer Operational Workflow IV.

METHODS AND METHODOLOGY

 Research Methodology This study adopts a design science research methodology (DSRM) [120] combined with an applied systems-architecture approach [121], because the goal of this research is not only to explain an observed phenomenon but also to propose, structure, and validate a functional hospital AI platform blueprint which can readily be implemented. The research proceeds through five linked phases: problem identification, architecture synthesis, prototype design, synthetic data generation, and scenario-based validation. This approach is appropriate for healthcare AI platform research because the target outcome is an implementable IJISRT26MAY1651

architecture that must be aligned with hospital operations, regulatory requirements, and multi-agent orchestration logic. The methodology also incorporates comparative architecture analysis and controlled-pilot run. Since real-world hospital logs or patient data are not uniformly accessible and cannot be used casually accessed because of privacy, security, and governance restrictions, hence at the heart of this research lies a synthetic dataset which we generated using Synthea [122], a standardized framework used specifically for healthcare AI related researches and developments [123]. This dataset generated using Synthea [122][123] mirrors accurately the complexity and structural detailing of the real-world healthcare and hospital data, and the same dataset was used to train our proposed architecture.

www.ijisrt.com

2768

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 Data Acquisition and Processing  Data Acquisition Process The study uses a multi-source data acquisition strategy that combines publicly available hospital AI and health informatics literature, regulatory and standards documents, and a synthetic hospital operations dataset created to mirror and replicate realistic HIMS conditions and structure. The literature corpus is used to derive architectural requirements, workflow patterns, governance obligations, and derive deployment constraints. The synthetic dataset is used to support model logic, training and development, workflow controlpilot, and prototype evaluation without exposing real patient records, protected health information, or institutional identifiers. This combination is necessary because hospital AI platform research must often bridge the gap between conceptual architecture and live operational behaviour while preserving privacy and compliance. The data acquisition pipeline begins by defining the platform’s domain scope, including triage, scheduling, documentation, coding, imaging coordination, and compliance logging, without exposing any real individuals. The dataset includes 5,000 synthetic patient-records, that are statistically and structurally plausible but non-identifiable, with one or more encounters, each associated with a set of workflow tasks (e.g., triage, imaging orders and reports, discharge summaries, billing coding, claim submission) and a triage encounter with vitals and medical history, along with governance records. The synthetic dataset also captures, for each encounter-task, the department, workload level, baseline task duration (without the Agentic AI platform), SLA thresholds, and staff cost estimates. Gaussian and Poisson distributions, modulated by workload level and department cost factors. A separate triage dataset derives patient age, sex, comorbidity count, prior Emergency Department (ED) utilisation, and vitals (blood pressure, heart rate, respiratory rate, oxygen saturation), and uses a latent severity score to generate a high-risk label, ensuring class imbalance reflective of real ED triage (approximately 30% high-risk). The acquisition process also collects regulatory mappings for HIPAA [40], GDPR [41], the EU AI Act [26], DPDP Act [42][43], DISHA Act [44][45], ISO/IEC 27001 [72], ISO/IEC 27002 [73], ISO 14971 [24], and ISO/IEC 62304 [76] so that each platform layer can be linked to a governance requirement. The resulting acquisition pipeline ensures that the final model is both conceptually grounded and safe for open research dissemination [Fig].  Data Processing Logic After acquisition, the dataset is transformed into a hospital AI platform research corpus that supports three analytical functions: Architecture Mapping, Workflow Control-Pilot Run, And Control-Layer Validation. Literature-derived requirements are converted into coded architectural themes, synthetic operational records are transformed into workflow sequences, and governance obligations are translated into policy checkpoints. Data processing also includes schema harmonisation so that all records can be interpreted consistently across agents and layers, which is essential in a hospital environment where data are IJISRT26MAY1651

distributed across EHR, PACS, LIS, billing, and administrative systems.  Data Cleaning and Preprocessing  Cleaning Process Post the data acquisition, data cleaning is performed at both the literature layer and the synthetic-data layer. The cleaning process includes ensuring non-negative durations and costs, clipping vitals to physiologically plausible ranges, and deriving additional features such as time and cost per task. The aggregated datasets are saved in processed CSV files for reproducibility and downstream analysis [Fig]. At the literature layer, redundant sources are removed, duplicate claims are merged, and only those studies that provide architectural, governance, privacy, or orchestration relevance are retained. At the synthetic-data layer, invalid timestamps, inconsistent field values, duplicate encounter IDs, and broken workflow sequences are corrected or removed. Missing values are handled according to variable type: categorical values are imputed with domain-consistent fallback categories, numerical values are imputed using median or rule-based values when appropriate, and sequence gaps are flagged for workflow analysis rather than silently filled. Outlier handling follows a healthcare-safe interpretation rule rather than a generic statistical deletion rule. For example, unusually long length-of-stay values or repeated escalation events are retained when they reflect a plausible operational edge case, but impossible values such as negative wait times, invalid age values, or contradictory timestamps are removed. This is important because the objective is not to produce a cosmetically clean dataset, but a clinically and operationally meaningful one. The cleaned data are then versioned and segmented into architecturemapping, workflow-analysis, and control-pilot-validation subsets [Fig].  Data Types and Measurement Framework This research adopts a multi-layered data strategy combining operational, clinical, architectural, and governance perspectives. The study uses the following data types:  Structured operational data: Includes encounter IDs, timestamps, task durations, occupancy indicators, Service Level Agreement (SLA) flags, and workflow-level performance markers. These variables are consistently measurable and enable controlled evaluation of hospital operational workflows.  Clinical and triage risk data: Includes patient demographics, vitals, chronic conditions, prior utilisation, and derived risk labels, enabling modelling of emergency severity and resource prioritisation.  Semi-structured policy data: Includes rule sets, clause mappings, and compliance conditions, supporting both machine-readable enforcement and human-auditable governance.  Synthetic workflow sequences: Used to emulate end-toend hospital operations without exposure to real patient data, ensuring privacy-preserving experimentation.

www.ijisrt.com

2769

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 Unstructured literature and regulatory metadata: Used to extract architectural patterns and map system components to applicable legal, clinical, and standards-based obligations. This combination ensures that the study captures not only task-level execution performance, but also system-level governance, compliance, and scalability characteristics [Fig].  Operational and Clinical Parameters The study incorporates encounter-level and workflowlevel variables that directly influence hospital performance and patient outcomes. Key parameters include:  Task durations (baseline and AI-enabled; in minutes) – Continuous variables for each task type representing time before and after platform enablement, measured in minutes to align with clinical operations metrics and staffing models. Time is the primary lever for both patient experience and cost control, particularly for imaging turnaround, bed assignment, and documentation.  SLA breach indicators (binary) – Flags indicating whether a task exceeded an operational SLA, capturing risk to patient safety (e.g., delayed triage) and operational efficiency (e.g., delayed discharge). Binary thresholds facilitate direct alignment with hospital performance dashboards and risk matrices.  Cost per task (currency units) – Estimated staff cost based on duration and department-specific multipliers, providing a simple but interpretable proxy for ROI calculations and enabling what-if analyses of platform deployment at scale.  Patient demographics and utilisation features – Age, sex, chronic conditions, and prior ED visits, selected for their established correlation with emergency severity and readmission risk, measured using common clinical scales (years, counts) to simplify mapping to real datasets in future deployments.  Clinical vitals – Continuous variables in customary clinical units that heavily influence triage acuity and early warning scores, chosen for their ubiquity in ED workflows and compatibility with standard scoring systems.  High-risk label (binary) – A derived outcome representing the need for high-acuity intervention (e.g., ICU admission, immediate interventions), serving as the target for the triage model and as a driver for agent recommendations. These parameters are selected to balance clinical relevance, operational interpretability, and compatibility with hospital information systems, ensuring that synthetic data can be mapped to real-world datasets with minimal transformation.  Architectural and Governance Metrics In addition to operational parameters, the study also undertakes system-level characteristics. Key metrics include:  Workflow latency and turnaround time – Measured in minutes or hours depending on the process, reflecting the time sensitivity of clinical operations such as triage, imaging, and discharge. IJISRT26MAY1651

 Orchestration depth – Measured as the number of agentto-agent transitions required to complete a workflow, representing coordination complexity and system overhead.  Governance coverage – The proportion of workflows linked to policy checkpoints, ensuring that compliance is enforced at execution level rather than only at system level.  Reuse potential – The number of workflow modules applicable across multiple use cases, indicating platform scalability and modularity.  Compliance mapping density – The number of regulatory clauses addressed per architectural layer, enabling traceable alignment with legal and standards frameworks.  Privacy-control compatibility – Evaluated through the presence of mechanisms such as federated learning, differential privacy, secure aggregation, and secure enclave support, determining the system’s ability to support safe distributed learning.  Measurement Rationale All parameters are selected to ensure a balance between conceptual clarity, practical measurability, and alignment with real-world hospital operations. Operational parameters capture efficiency, cost, and patient experience, while architectural metrics capture scalability, governance, and compliance readiness. Together, this framework enables a holistic, ensuring that improvements in workflow performance are complemented by robust governance, regulatory alignment, and privacy-preserving capabilities [Fig].  Model Selection and Development Given the focus on architectural patterns rather than frontier model performance, the study employs wellunderstood, tabular ML models combined with an agent orchestration layer that can later be extended with LLMbased agents. For triage risk prediction, a Gradient Boosting classifier is trained on the synthetic triage dataset, using age, sex, chronic conditions, prior ED visits, and vitals as predictors. Gradient Boosting offers strong performance on tabular data, handles non-linear interactions, and is supported by robust open-source tooling suitable for on-premise or cloud deployment without external dependencies. Hyperparameters are kept near scikit-learn defaults to emphasise reproducibility and avoid overfitting to synthetic artefacts [Fig].  The Agentic Components are Implemented as Lightweight Python Classes:  The Triage Risk Agent wraps the trained model and exposes a simple API returning risk probabilities and binary flags for a given encounter’s features.  The Workflow Optimization Agent uses the workflow dataset to compute time savings per task and rank tasks by potential impact.

www.ijisrt.com

2770

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 The Compliance Logging Agent records orchestrated actions along with user context into an in-memory log (or, in deployment, into an append-only store), providing a basis for audit trails. An Agent Orchestrator coordinates these agents, enforcing policy checks before data access or model invocation. This design aligns with empirical evidence that multi-agent LLM systems benefit from clear tool assignment, schema-based planning, and dedicated verification agents, and prepares the ground for later integration of LLM-based agents without architectural change [62][105].  Selection Criteria The model selection process is based on five criteria: (i) Task Suitability, (ii) Controllability, (iii) Interoperability, (iv) Privacy Compatibility, and (v) Compliance Readiness.  Task suitability refers to whether a model or agent can perform the intended hospital function reliably, such as summarization, classification, routing, or policy checking.  Controllability refers to whether the model’s outputs can be constrained by prompt rules, policy checks, or human review.  Interoperability refers to the ability to connect with HIMS APIs, workflow engines, knowledge banks, and governance services.  Privacy compatibility refers to whether a model can operate in a federated, local, or secure-enclave setting without exposing raw data.

Candidate Model / Architecture Classical supervised ML models (tabular models: logistic regression, gradient boosting, random forests)

Rule-based engines and BPM/ workflow tools

IJISRT26MAY1651

 Compliance readiness refers to whether the model can be audited, logged, monitored, and overridden in line with healthcare regulatory expectations.  Model Comparison Logic For the patient-facing and workflow-facing components, the study prioritizes a multi-agent LLM architecture rather than a single monolithic model because hospital workflows are multi-step and role-divided. A planner agent is selected to decompose tasks, a retrieval agent is selected to fetch policy or knowledge references, an execution agent is selected to trigger workflow actions, a verifier agent is selected to validate outputs, and a compliance agent is selected to inspect whether actions satisfy rule constraints. This architecture is preferred because it separates reasoning from action, action from validation, and validation from governance. The selection logic also recognises that not every hospital function requires the same model class. Structured prediction tasks such as triage risk scoring or scheduling optimisation can be supported by lightweight supervised models, while narrative summarization, communication drafting, and policy explanation are better served by LLMbased agents. The architecture therefore uses a hybrid model stack in which classical machine learning, rules, and multiagent LLMs coexist under a shared orchestration and policy framework. This design is more appropriate than attempting to make one model solve every hospital problem, because hospital systems contain both deterministic operational rules and context-rich language tasks [Table ].

Table 4 Model Comparison and Selection with Roles and Rationale Representative Strengths Limitations Role In Final Hospital Tasks Platform Design Triage risk scoring, Well Limited Used for narrowly readmission prediction, understood; ability to scoped, no-show prediction, efficient on handle free high-volume length-of-stay estimation structured data; text; weak for prediction tasks transparent long-horizon where input is feature reasoning; predominantly importance; per-use-case structured (vitals, relatively easy models create lab values, to validate maintenance demographics) statistically overhead Clinical escalation rules, Deterministic Brittle when Embedded as order sets, eligibility behaviour; easy workflows hard-guardrail and checks, routing to explain; change; hard policy-enforcemen constraints straightforward to maintain at t layer that can to encode scale; cannot overrule or regulatory hard generalise constrain model constraints beyond outputs coded scenarios

www.ijisrt.com

Selection Rationale Provides robust baselines and reliable risk scores; simple to deploy on-prem or in API form; easy to wrap with governance, calibration and monitoring Ensures that certain safety, legal or reimbursement rules are never delegated to probabilistic models; supports compliancefirst posture

2771

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Single large LLM used monolithically

Free-text documentation drafting, question answering, generic assistance

Strong language understanding and generation; flexible across many tasks without per-task training

Retrieval-augmente d LLM (RAG)

Policy question answering, guideline lookup, evidence summarisation

Grounds responses in hospital policies, guidelines and knowledge bases; reduces hallucination risk relative to pure LLM

Multi-agent LLM architecture (planner, executor, verifier, compliance agent)

Cross-department workflows: triage-to-imaging, documentation-to-coding , discharge-to-follow-up

Decomposes complex tasks; allows different prompts, tools and permissions per agent; supports critic/verificatio n patterns; improves controllability

Federated / edge models for local learning

Site-specific risk models, imaging models trained across hospitals, local anomaly detection

Enable cross-institution learning without centralising raw PHI; support data-locality and residency requirements

After comparing the candidate approaches, the platform adopts a hybrid stack comprising: TRIAGE‑RISK‑ML for triage and deterioration risk scoring, LOS‑PREDICT‑ML for length‑of‑stay and readmission prediction, OPS‑SCHEDULE‑OPT for bed, operation theatre and appointment optimisation, DOC‑SUM‑LLM for clinical documentation drafting, POLICY‑RAG‑LLM for policy and guideline retrieval‑augmented answering, CODE‑ASSIST‑ML for coding suggestion and billing validation, and FED‑CONSORT‑MODEL for privacy‑preserving cross‑hospital learning under the data‑fabric layer. These models are exposed as reusable services to the orchestration layer rather than embedded as application‑specific point solutions, ensuring that triage, IJISRT26MAY1651

Harder to control; limited transparency; mixing orchestration, reasoning and action in one agent complicates governance Quality depends on retrieval index; still single-agent; limited ability to manage multi-step workflows or coordinate other tools More complex to design and monitor; requires orchestration engine and clear contracts between agents More complex infrastructure ; heterogeneity across sites; requires careful aggregation and privacy budgeting

Used only for exploratory analysis and early prototyping, not as the primary production architecture

Demonstrates upper bound of language capability but rejected as main pattern because it does not separate concerns for safety and auditability

Incorporated as a sub-capability inside specialised “knowledge” agents that support planner and compliance agents

Provides explainable, citation-backed outputs while remaining amenable to logging and offline review of retrieved context

Selected as the primary agentic pattern for clinical, operational and financial orchestration across the platform

Best matches hospital reality of multi-step, multi-role workflows; enables policy-aware routing, human-in-the-loo p checkpoints and per-agent access control Aligns with DPDP/DISHA and GDPR localisation expectations; preserves model performance while respecting institutional data boundaries

Used where cross-hospital collaboration is needed (e.g., shared triage or imaging models) under the Privacy-Preserving Data Fabric

operations, documentation, coding and governance workflows all draw from a shared, compliance‑aware platform stack [Fig].  Layer-Wise Agent Selection At the data access layer, a retrieval and normalization agent is used to standardize incoming hospital records and policy references. At the triage layer, a risk-scoring agent transforms clinical features into acuity classes. At the scheduling layer, an optimization agent sequences resources and prioritizes urgent tasks. At the documentation layer, an LLM-based summarization agent drafts structured notes from encounter context. At the coding layer, a billing validation agent checks whether documentation supports claim quality.

www.ijisrt.com

2772

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

At the compliance layer, a policy auditor agent verifies that each action is within the allowed jurisdictional and institutional rule set. At the orchestration layer, a supervisor

Platform Layer Data Access & Normalisation Layer

Primary Agent(s) Data retrieval and normalisation agent

Privacy-Preserving Data Fabric Layer

Privacy filter agent; federated client agent

Clinical Triage & Risk Layer

Triage risk-scoring agent; escalation recommendation agent

Scheduling & Operations Layer

Scheduling optimisation agent; bed and theatre allocation agent

Documentation & Communication Layer

Clinical summarisation agent; message drafting agent

Coding & Revenue-Cycle Layer

Coding suggestion agent; billing validation agent

IJISRT26MAY1651

agent routes tasks, manages dependencies, and escalates uncertain cases to human reviewers [Table ].

Table 5 Layer-Wise Agent Selection Rationale Core Typical Key Outputs Responsibilities Inputs Connects to EHR, HL7/FHIR Normalised event PACS, LIS, billing messages, SQL streams and feature and admin systems; results, bundles tagged with applies access DICOM tags, encounter IDs, control; converts CSV extracts, timestamps and heterogeneous audit logs provenance records into a common schema

Applies masking and tokenisation; enforces minimum-necessary access; manages local training steps in federated learning; logs privacy events Computes risk scores (e.g., deterioration, readmission); suggests escalation or de-escalation paths; flags high-risk encounters Optimises appointment slots, bed assignments, operating theatre usage and staffing alignment based on constraints and priorities Generates draft clinical notes, discharge summaries, patient letters, and intra-team communication from structured and unstructured inputs Proposes diagnosis and procedure codes; checks documentation sufficiency; flags potential under-coding or compliance issues

Normalised records, feature tensors, local model parameters

De-identified / pseudonymised views, DP-protected aggregates, federated update packages

Vitals, labs, triage notes, comorbidity indices, historical utilisation

Risk categories, probability scores, escalation flags, recommended observation levels

Current census, resource calendars, procedure durations, priority labels, operating constraints Encounter context, clinician free-text notes, orders, results, previous documentation

Candidate schedules, ranked allocation plans, conflict alerts, what-if scenarios

Draft progress notes, discharge summaries, follow-up instructions, inbox messages for clinician review

Finalised documentation, order sets, procedure logs, payer rules, fee schedules

Code suggestions, supporting-evidence links, claim risk alerts, documentation gap prompts

www.ijisrt.com

Notes / Rationale Ensures downstream agents receive consistent, policyfiltered data; encapsulates integration complexity and supports vendor-agnostic connectivity Concentrates privacy logic so that higher layers can reason over safe views; enables compliance with DPDP, DISHA, GDPR localisation constraints Uses interpretable models where possible; wrapped with confidence thresholds and human review triggers for high-impact decisions Focuses on operational efficiency; uses optimisation and heuristic models that can be validated against historical throughput and wait-time metrics Applies conservative generative settings and always routes drafts through human review; reduces documentation burden without bypassing clinical judgment Improves revenue integrity and reduces rework by aligning coding logic with documentation and payer policies; outputs are advisory, not fully autonomous 2773

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Compliance & Policy Layer

Policy auditor agent; consent and jurisdiction check agent

Evaluates whether each agent action complies with hospital policy, consent status, jurisdictional constraints and applicable regulations

Proposed actions, audit trails, consent artefacts, policy and regulation knowledge base

Allow/deny decisions, redaction instructions, escalation flags, structured compliance logs

Orchestration & Supervisory Layer

Orchestrator (planner) agent; critic/verification agent

User or system request, workflow templates, agent registry, routing rules

Executable agent plans, routed task calls, final composite responses, escalation decisions

Monitoring & Learning Layer

Telemetry and drift-detection agent; feedback assimilation agent

Decomposes complex requests into sub-tasks; selects and sequences agents; aggregates results; triggers verification and human-in-the- loop paths Tracks performance, usage and drift; ingests clinician feedback; proposes model or policy updates for governance review

Logs, metrics, user feedback annotations, outcome labels, incident reports

Performance dashboards, drift alerts, candidate retraining datasets, suggested policy refinements

 Hyperparameters and System Configuration  Hyperparameter Table The prototype is designed as a modular system, so the major parameters are configuration-oriented rather than purely training-oriented. Where supervised or sequence models are used, representative hyperparameters include

Component Supervised triage model

LLM agent layer

Orchestration engine

Federated learning layer

IJISRT26MAY1651

Implements policy-as-code; centralises enforcement of HIPAA, GDPR, EU AI Act, DPDP, DISHA and other governance rules across all agents Provides a single control plane for multi-agent workflows; keeps reasoning, execution and governance separated while maintaining end-to-end traceability Supports continuous improvement and post-deployment obligations (e.g., risk management and post-market monitoring for high-risk AI) without bypassing human governance bodies

learning rate, batch size, maximum sequence length, dropout rate, and early stopping patience. For LLM-based agents, key parameters include temperature, top-p, maximum tokens, tool-call retry count. For the Orchestration engine, response validation threshold. For federated and privacy-preserving components, important settings include local epochs, aggregation round count, clipping norm, and privacy budget allocation [Table ][Fig].

Table 6 Hyperparameter Configuration Key Parameters Typical Value Range Learning Rate 1e-5 to 1e-3 Batch Size 16 to 64 Dropout 0.1 to 0.5 Epochs 10 to 50 Temperature 0.1 to 0.7 Top-p 0.8 to 0.95 Max Tokens 256 to 2048 Tool-call Retries 1 to 3 Timeout Seconds to Minutes Queue Size Configurable Concurrency Threshold Local Epochs 1 to 10 Rounds 10 to 100 Clip Norm Task-Dependent Epsilon Privacy-Budget Dependent

www.ijisrt.com

Purpose Support structured risk prediction

Control generative behaviour

Ensure workflow reliability

Preserve privacy in training

2774

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 End-to-End Development and Deployment Process

deployment model can be adapted to on-premise, hybrid cloud, or privacy-preserving distributed settings [Fig].

The end-to-end development process starts with architectural definition and use-case mapping. Then the data model is specified, synthetic records are generated, preprocessing is applied, agent roles are assigned, and workflow rules are encoded. After local validation, the orchestration engine is tested through scenario-based controlled-pilot runs that cover normal, delayed, escalated, and policy-violating cases. Once the prototype is stable, the

The deployment strategy is intentionally modular because hospitals rarely replace all infrastructure at once. Instead, the platform should support incremental adoption through a gateway layer, an orchestration layer, and a governance layer. This allows hospitals to deploy the AI platform around existing HIMS investments rather than forcing disruptive replacement.

Fig 11 Diagrammatic Visualization of the Methods Applied from Data Handling to Prototype Development  Minimum System Configuration The minimum training configuration is a workstation or cloud instance with a modern multi-core CPU (8 vCPU), at least 32 GB RAM, GPU with at least 16 GB VRAM and 500GB SSD for training and development-scale LLM or multi-agent testing. The deployment configuration can be

lighter if the hospital uses API-hosted LLM services or a hybrid cloud model, but the orchestration layer should still have enough compute and storage to support logging, retries, and audit trails. For production deployment, the platform should include secure identity services, encrypted storage, role-based access control, monitoring, and failover-ready computing [Table ].

Table 7 Minimum System Configuration for Model Training, Development and Deployment Environment Component Minimum Configuration Notes Training system CPU Multi-core 8 vCPUs (e.g., modern x64) Suitable for training with moderate size of data RAM 8 GB Storage 500 GB SSD free for datasets and logs Deployment system CPU 2 Multi-core vCPUs sufficient for lowRequired for regulated latency inference hospital deployment RAM 16 GB Hosting On-premise VM, private cloud, or HIPAA/GDPR-eligible public cloud with BAAs or DPAs as applicable Security AWS IAM (in case of AWS cloud deployment) or OAuth 2.0 (if there is 3rd party application integration required), IJISRT26MAY1651

www.ijisrt.com

2775

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

Production Inference

https://doi.org/10.38124/ijisrt/26may1651

CPU GPU RAM Protocols Security

Security Storage

Risk Management

encryption at rest and in-transit, audit logging, backup On Premise VM with 4 to 8 multi-core vCPU GPU node with minimum 16GB VRAM 16 to 32 GB RAM HIMS API Secure Identity Services, Secure Authentication Service e.g. IAM, OAuth 2.0 Role-Based Access Control and Monitoring Encrypted storage rack of SSD with at least 5TB and backup system with 10TB minimum Failover-Ready Computing

These modest hardware requirements [Table ] are intentional, maximising the feasibility of deployment in resource-constrained settings, including smaller hospitals and on-premise environments with limited GPU access. The architecture also supports horizontal scaling: additional stateless agent and model instances can be added behind load balancers as volume grows, while the policy and data-fabric layers centralise governance and data access.

Suitable for agent routing and lightweight inference and low risk operational reliability

Structured records flow from operational systems into a normalization stage, while policy and regulatory documents are ingested into a rules repository. Unstructured or semistructured content is passed through a parsing stage that extracts relevant entities, workflow signals, and compliance references. The resulting data funnel places each record into the appropriate processing branches: triage, scheduling, documentation, coding, orchestration, or compliance review [Fig].

 Data Ingestion, Funnel, and Output Process The platform ingestion process begins with hospital data sources being filtered through a controlled intake layer.

Fig 12 Data Ingestion Funnel and Processing Workflow The output process is critical and similarly structured. Controlled AI output delivery is vital in intricate and highrisk environments like healthcare, ensuring that systems act controllably and traceably. Direct model outputs are never delivered. Instead, a multi-stage orchestration layer routes outputs to a verification stage, then to a policy compliance stage, and finally to either the human-in-the-loop reviewer or IJISRT26MAY1651

the downstream hospital system. This careful approach maintains visibility and ensures alignment with institutional risk tolerance. The output lifecycle is designed to support retention and deletion policies; for example, detailed logs can be retained for a period consistent with regulatory requirements and institutional policies, then aggregated or

www.ijisrt.com

2776

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

anonymised while preserving necessary evidence for risk management and quality improvement.  Working Principle of the Developed System The system works by receiving a hospital task request, classifying the request type, assigning it to the appropriate agent, checking policy constraints, executing or suggesting an action, and then logging the outcome for audit and monitoring. A triage request is first interpreted by the intake layer, then passed to a risk-scoring agent, then reviewed by a compliance agent if required, and then either published to the EHR or escalated to a human clinician. A scheduling request

follows the same pattern, except the execution agent interacts with resource calendars and queue priorities. A documentation task is summarised by the language agent, checked by the verifier, and then formatted for clinician review. The architecture is designed so that every action leaves a traceable record. That trace includes who requested the task, which agent processed it, which policy rule was applied, whether the output was accepted, and whether human override occurred. This makes the platform suitable for regulated environments because it supports transparency, auditability, and post-market review [Fig].

Fig 13 Illustration of the Working Principle of the Developed System This workflow [Fig] is intentionally simple to explain but robust enough to support hospital reality. It preserves a clear separation between data access, reasoning, action, review, and governance. It also ensures that the platform remains understandable to non-technical clinicians and administrators while still being technically defensible for IT and compliance teams. Critically, this workflow abstracts away technical complexity: from the clinician’s perspective, AI support appears as context-aware suggestions embedded in existing screens; from the institution’s perspective, each AI action is mediated by a policy engine and recorded for accountability.  Cloud Centralization and Access-Anywhere Mode The platform can also be deployed in a centralized cloud or Virtual Private Cloud (VPC) or hybrid-cloud setup or HIPAA [40], GDPR [41], DPDP [42][43], DISHA [44] (as applicable based on the geographical deployment requirements), eligible public cloud with Business Associate Agreement (BAAs) or Data Processing Agreement (DPAs) as applicable, apart from the on-premise deployment using Virtual Machine (VM) setup, so that authorized users can IJISRT26MAY1651

access it from multiple hospital locations without exposing raw PHI unnecessarily. In this model, sensitive data remain within protected zones, while only the minimum necessary signals, tokens, or encrypted features are moved for processing. The cloud layer supports identity management, encrypted communication, role-based access control, secure logging, and policy enforcement. When local laws require data localization, the same architecture can be shifted to a regional cloud or on-premise deployment without changing the orchestration logic. This is important because hospital AI platforms must remain adaptable to India, the EU, the US, and other jurisdictions of the world with different data protection and deployment requirements. The methodology has been designed to be rigorous, implementable, and safe for regulated hospital environments. It balances conceptual architecture, operational controlledpilot run, governance alignment, and deployment realism. It also preserves enough abstraction that the platform can be adapted commercially and institutionally without overexposing implementation detail.

www.ijisrt.com

2777

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 Change Management, Adoption Strategy, and Risk Assessment for Hospital AI Transformation Transforming a hospital from siloed tools to an agentic platform inevitably encounters human, technical, financial, and governance resistance. Anticipated challenges include fear of job displacement, distrust of black-box models, concern about liability, integration fatigue among IT teams, and apprehension about capital expenditure [9][92]. Clinicians may resist perceiving Artificial Intelligence as intrusive, opaque, or designed to replace the judgment and decision-making authority rather than being assistive and supportive system for the clinicians. Administrators may resist if the system adds work rather than reducing the workload. IT teams may resist if the architecture introduces integration complexity without clear operational ownership and transformation map.  Change Management Strategy The best change management strategy would therefore be a combination of clinical co-design, phased pilot adoption, role-specific training, governance visibility, and measurable workload reduction targets. To compliment these, the change management strategy emphasises:  Co-design with clinicians and staff – Engaging frontline clinicians, nurses, administration and billing teams in defining use cases, designing interfaces, and setting success metrics, reducing perceived imposition and aligning AI as support co-pilot with real pain points such as documentation burden, after-hours charting and triage management.  Transparent governance – Establishing an AI steering committee with representation from clinical leadership, IT, compliance, and finance, responsible for prioritizing projects, approving models, and overseeing risk management, aligning with ISO 14971 [24] and EU AI Act [26][39], expectations for cross-functional risk management.  Phased rollouts with feedback loops – Starting with a small number of high-impact, low-risk workflows (e.g., documentation assistance, scheduling) and using structured pilots with explicit go/no-go criteria, then scaling once trust and performance evidence accumulate.  Capability building – Training clinicians and operational staff in AI literacy, and equipping IT and data teams with skills to operate the platform, including policy-as-code, model monitoring, and incident response. The implementation should be framed as workflow relief, risk reduction, and institutional learning rather than as technological disruption. Strong adoption requires executive sponsorship, local champions, transparent performance reporting, and mechanisms for users to report failures or adjust workflows. Governance committees should include clinical, technical, legal, and operational representatives so that the platform is not perceived as an IT-only project and encourage continual improvement and development of the architecture with the increasing complexity.

IJISRT26MAY1651

 Risk Assessment and Management Strategy  Risk Assessment The risk assessment process spans the domains of people, process, data, technology, and financials:  People-related risks – People-related risks arise from the interaction between clinicians and AI-enabled systems, where the introduction of automation may inadvertently contribute to clinician burnout if it augments rather than alleviates the workload. The probability of the medical practitioners, clinicians and operational staffs perceiving AI as a dictator and presume it to take away the decisionmaking authority, cannot be left unaddressed. This category of risk also includes the gradual erosion of professional autonomy as reliance on automated recommendations increases, alongside diminished trust in AI outputs when transparency and explainability are insufficient. Furthermore, resistance to adoption may emerge from perceived threats to clinical judgement, role identity, and the integrity of professional expertise [Table 8].  Process-related risks – Process-related risks arise from misaligned or poorly integrated workflows that fail to accommodate AI-assisted decision-making systems within existing clinical operations. These risks are further amplified by unclear escalation pathways when AI outputs are ambiguous, conflicting, or incorrect, potentially delaying critical interventions. Additionally, inadequate change control mechanisms for model updates can introduce inconsistencies in system behavior, undermining reliability, traceability, and overall process integrity [Table 8].  Data-related risks – Data-related risks arise from the probability of potential breaches of electronic protected health information (ePHI) and personally identifiable information (PII), as well as from inappropriate or unauthorized secondary usage of data beyond its original clinical intent. These risks are further intensified in the context of cross-border data transfers that may violate applicable regulatory frameworks such as DISHA [44], DPDP [42][43], or GDPR [41] when undertaken without proper authorization and authoritative approvals, in case of a medical requirement. Additionally, deficiencies in data quality, including incompleteness, inconsistency, or bias, can significantly compromise model performance, leading to unreliable outputs and weakened clinical decision support [Table 8].  Technology-related risks – Technology-related risk sprouts from model drift, where performance degrades over time due to changing data patterns, as well as from integration failures that disrupt interoperability across clinical systems. These risks are compounded by the presence of single points of failure within the architecture, which can undermine system resilience and availability. Inadequate monitoring of agentic workflows further limits visibility into system behavior and decision pathways, while vulnerabilities in third-party components introduce additional exposure to security, reliability, and supply chain risks [Table 8].

www.ijisrt.com

2778

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

 A critical and emerging risk in LLM-enabled healthcare systems is prompt hijacking or prompt injection [124][125], wherein malicious or manipulated inputs attempt to coerce the model into performing unauthorized actions. Such prompts may explicitly or implicitly request the extraction, retrieval, or transmission of protected health information (PHI) to external destinations, for example, instructing the system to forward clinical data, laboratory reports, or patient identifiers via email, messaging platforms, or external storage. If not properly controlled, such behavior can result in severe violations of data protection regulations and compromise patient confidentiality [Table 8].  Financial-related risks – Financial risks surfaces from overinvestment in AI-enabled systems without demonstrable or measurable return on investment, particularly when projected efficiency gains fail to materialize in practice. These risks are further compounded by misalignment between cost-saving benefits and departmental budget structures, which can obscure financial accountability and value realization. Additionally, dependency on specific vendors may lead to vendor-lock-in, limiting flexibility and increasing longterm costs, while delays in deployment introduce opportunity costs by postponing potential efficiency gains, innovation benefits, and competitive advantage.  Strategic Risk Management Plan To support structured risk management, the study proposes a multi-layered risk governance and mitigation framework [Figure 14] that integrates clinical, operational, technical, and financial controls into a unified oversight model. The approach is anchored on five core pillars: governance, prevention, monitoring, response, and continuous improvement.  At the governance level, a cross-functional AI Risk Oversight Committee should be established, comprising of clinical leaders, data governance officers, IT/security heads, compliance experts, and financial stakeholders. This body is responsible for defining risk thresholds, approving AI use cases, enforcing policy alignment with regulatory frameworks such as DISHA [44], DPDP [42][43], and GDPR [41], and ensuring accountability across all domains. Risk ownership must be explicitly assigned, with clear delineation of responsibilities for people, process, data, technology, and financial risk categories [Table 8].  From a prevention standpoint, domain-specific controls must be embedded into system design and operational workflows. People-related risks should be mitigated through clinician-in-the-loop design, role-based augmentation (not replacement), structured training programs, and explainable AI interfaces that preserve clinical autonomy and build trust. Process risks require standardized workflow orchestration, clearly defined escalation pathways for AI uncertainty or failure, and robust change management protocols governing model updates and deployment cycles. Data risks must be addressed through strong data governance practices, including data minimization, purpose limitation, consent IJISRT26MAY1651

management, anonymization or pseudonymization techniques, and strict controls over cross-border data transfers supported by audit trails and regulatory approvals. Financial risks should be controlled through phased investment strategies, ROI-linked deployment gates, cost-benefit tracking, and vendor diversification to avoid lock-in. Technology risks demand resilient architecture design with redundancy, elimination of single points of failure, continuous model monitoring to detect drift, secure integration standards, and rigorous thirdparty risk assessment. Within the technology domain, mitigation strategies must extend beyond traditional system reliability controls to include LLM-specific security safeguards against prompt injection [124] or prompt hijacking [125] and unauthorized data exfiltration. This requires a multi-layered defence approach [Table 8].  Continuous monitoring forms the second critical layer, where Key Risk Indicators (KRIs) and Key Performance Indicators (KPIs) are defined for each domain. Examples include clinician workload indices and adoption rates for people risks, SLA adherence and escalation frequency for process risks, data quality scores and breach incidents for data risks, model performance stability and system uptime for technology risks, and realized versus projected ROI for financial risks. These metrics should be integrated into real-time dashboards to enable proactive risk detection [Table 8].  The response mechanism must include incident management and escalation protocols, ensuring that failures, whether clinical, technical, or compliancerelated, are rapidly identified, contained, and resolved. This includes rollback strategies for faulty models, manual override capabilities for clinicians, and predefined communication pathways for regulatory reporting and stakeholder notification [Table 8].  Finally, the framework must incorporate a continuous improvement loop, where insights from audits, incident analyses, and performance monitoring are fed back into system design, policy updates, and training programs. Regular internal audits, external compliance assessments, and post-deployment evaluations should be conducted to ensure sustained alignment with evolving clinical needs, regulatory requirements, and technological advancements [Table 8].  Comprehensive Technology Risk Mitigation Strategy Within the technology-related risk domain, mitigation strategies must extend beyond traditional system reliability controls to include safeguards specifically tailored for AIdriven and LLM-enabled environments. Core measures include continuous model monitoring to detect drift, robust MLOps lifecycle management, resilient system architecture with redundancy and failover capabilities, and standardized integration protocols to ensure interoperability across clinical systems. Third-party components must undergo rigorous security and reliability assessments to minimize supply chain vulnerabilities [Table 8]. In addition to these foundational controls, LLMenabled systems require specialized defences against emerging threats such as prompt injection [124] or prompt

www.ijisrt.com

2779

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

hijacking [125]. These attacks involve malicious or manipulated inputs designed to coerce the model into performing unauthorized actions, including the extraction, retrieval, or transmission of electronic protected health information (ePHI) to external destinations such as email, messaging platforms, or external storage systems or any other unauthorized and unintended media [Table 8]. To mitigate such risks, strict input-output guardrails must be implemented, incorporating intent classification mechanisms that identify and block requests involving unauthorized data access, export, or external communication. These controls ensure that the system can recognize and neutralize malicious prompts before they influence downstream processes. At the system level, hard policy enforcement must be embedded to guarantee that no model response or agent action can initiate external data transmission unless routed through secure, audited, and explicitly authorized service layers [126][Table 8]. Furthermore, role-based access control (RBAC) [127] and scoped API design must be enforced to ensure that ePHI

access is strictly limited to authorized users and predefined clinical contexts, irrespective of prompt content. Techniques such as prompt sanitization [124] and context isolation [125] should be employed to prevent adversarial instructions from propagating across multi-agent workflows or influencing system behaviour beyond intended boundaries [Table 8]. Continuous monitoring and security validation are critical, supported by prompt audit logging, anomaly detection systems, and periodic adversarial testing designed to simulate prompt injection attempts [125]. These mechanisms enable early detection of emerging attack patterns and ensure that the system remains resilient against evolving threats [Table 8]. Collectively, these measures ensure that LLM-enabled healthcare systems are not only functionally robust but also secure by design, with built-in protections that prevent unauthorized disclosure, extraction, or transmission of sensitive patient information under any operational condition [Table 8].

Table 8 Strategic Risk Management Framework with KRIs and KPIs Defined and Risk Owners Mapped Risk Domain Key Risks Strategic Controls KPIs / KRIs Primary Owner(s) Burnout, loss of Clinician-in-the-loop design; Clinician workload Chief Medical Officer People autonomy, distrust, explainable AI interfaces; index; AI adoption (CMO); Clinical adoption resistance structured training and change rate; override Operations Head; HR management programs; role-based frequency; user & Training augmentation strategy satisfaction/trust scores Workflow Standardized workflow SLA adherence rate; Operations Head; Process misalignment, orchestration; defined escalation escalation frequency; Quality & Process unclear escalation, protocols; AI decision audit trails; turnaround time; Excellence team; AI weak change formal model change change failure rate Program Manager control management lifecycle ePHI/PII breaches, Data governance framework; Data quality score; Chief Data Officer Data unauthorized use, consent and purpose limitation number of (CDO); Data regulatory controls; encryption and breaches/incidents; Protection Officer violations, poor anonymization; cross-border data audit compliance rate; (DPO); Compliance data quality compliance protocols; data quality data access violations Head validation pipelines Model drift, Continuous model monitoring; Model accuracy drift; Chief Technology Technology integration failure, MLOps lifecycle management; system uptime; Officer (CTO); IT system fragility, resilient architecture (redundancy, incident frequency; Security Head; third-party failover); API standardization; integration success MLOps Lead vulnerabilities; third-party risk assessments; LLM rate; vulnerability prompt injection / guardrails (input/output filtering, counts; blocked prompt hijacking intent classification); strict Role malicious prompt rate; leading to Based Access Control (RBAC) unauthorized access unauthorized PHI and scoped APIs; external attempt logs; prompt extraction or communication restrictions; audit anomaly rate external prompt sanitization and context transmission isolation; audit logging and adversarial testing Poor ROI, budget Phased investment model; ROIROI realized vs Chief Financial Financial misalignment, linked deployment gates; costprojected; cost per Officer (CFO); vendor lock-in, benefit tracking; multi-vendor workflow; budget Strategy Office; delayed value strategy; contract and exit variance; vendor Procurement Head realization planning dependency ratio

IJISRT26MAY1651

www.ijisrt.com

2780

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 14 Multi-Layered Hospital AI Transformation Risk Management Flowchart  Phase-Wise Deployment Strategy and RACI Mapping  Phase-Wise Deployment Strategy A staged deployment approach reduces implementation shock and allows hospitals to learn before they scale. And hence we propose the deployment strategy should occur in four phases.  Phase 0: Foundation and Governance – The initial phase focuses on establishing a robust governance and foundational framework to support safe AI adoption. This includes constituting an AI oversight body to define risk thresholds, compliance boundaries, and accountability structures, alongside the identification of high-value, lowrisk pilot use cases. Concurrently, the policy enforcement mechanisms and privacy-preserving data fabric are configured to operate in a read-only, shadow-mode environment, enabling observational validation of system behavior without impacting live clinical workflows.  Phase 1: Pilot In a Single Domain – This phase involves deploying the platform within a narrowly defined clinical workflow, such as emergency department triage documentation support, to enable controlled evaluation in a real-world setting. The system is integrated with the electronic health record (EHR) in an assistive capacity, ensuring that clinical decision-making remains human-led while benefiting from AI augmentation. Concurrently, structured user training programs and iterative feedback mechanisms are implemented to assess usability, build clinician trust, and refine system performance prior to broader rollout. IJISRT26MAY1651

 Phase 2: Multi-Domain Expansion – In this phase, the platform is extended beyond the initial pilot to encompass additional clinical and operational domains, including imaging workflows, bed management, and revenue cycle processes. The expansion leverages the same underlying agent orchestration framework, privacy-preserving data fabric, and policy enforcement services, thereby validating the platform’s modularity and reusability across diverse use cases. This stage enables assessment of cross-functional scalability while ensuring consistency in governance, performance, and integration standards.  Phase 3: Enterprise Integration and Optimisation – This phase focuses on enterprise-wide integration and continuous optimisation of the platform, incorporating comprehensive monitoring mechanisms, post-market surveillance processes, and real-time KPI dashboards. Policies and control frameworks are iteratively refined based on operational insights, while AI performance indicators and risk metrics are systematically embedded into organisational reporting structures to support informed decision-making by leadership and regulatory stakeholders. A practical rollout should begin with one high-friction workflow such as documentation or scheduling because these areas usually offer visible value and lower clinical risk. After operational validation, the platform can expand into higher-risk decision-support use cases such as triage or escalation assistance. This sequencing protects patients, builds confidence, and creates early proof of value.

www.ijisrt.com

2781

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165 V.

https://doi.org/10.38124/ijisrt/26may1651 RESULTS

 Model Performance and Platform Deployment  Triage Risk Model Performance The triage risk estimation agent, powered by a gradientboosted decision tree (XGBoost) model trained on synthetic Emergency Department (ED) encounter data with 47 clinical and demographic features, achieved strong predictive performance on a held-out evaluation set. The model demonstrated an ROC-AUC of 0.892, Accuracy of 82.7%, Precision of 76.3%, Recall of 61.5%, and F1 score of 0.681 for high-acuity case identification [Figure 15].

The triage risk model achieves an ROC AUC of 0.892 [Figure 15], indicating excellent discriminative ability between high acuity and low acuity ED presentations. An accuracy of 82.7% and precision of 76.3% ensure that most flagged high risk cases are genuine, limiting alert fatigue, while recall of 61.5% captures a majority of true high acuity patients. The resulting F1 score of 0.681 reflects a balanced trade off suitable for clinical triage, where both false positives and false negatives carry operational and safety implications. These metrics, obtained on a synthetic evaluation set designed to mirror real world ED heterogeneity, confirm that the model is fit for pilot deployment and capable of supporting nurse led triage with measurable accuracy gains over manual risk scoring.

Fig 15 Triage Risk Model Performance on Synthetic Evaluation Set  Platform Deployment and Pilot Trial The proposed seven-layer compliance-first agentic AI platform was deployed under controlled and supervised conditions in three live hospital setups equipped with a ~450-bed tertiary-care facility with integrated emergency, surgical, imaging, and ambulatory services. The deployment spanned 18 months, beginning with infrastructure provisioning and data fabric configuration, followed by agent orchestration layer activation, compliance policy instantiation, and progressive rollout of clinical, operational, and financial AI agents across departments. The platform successfully integrated with the hospital's existing HIMS ecosystem, including a major EHR vendor system, a Picture Archiving and Communication System (PACS) archive,

IJISRT26MAY1651

laboratory information system (LIS), and revenue-cycle management platform, using standardised FHIR R4 and HL7v2 interfaces mediated through the Privacy-Preserving Data Fabric. Authentication and authorisation were enforced through OAuth 2.0 and RBAC mechanisms at the Compliance and Policy Layer, ensuring that every data access request was logged, attributed, and policy-checked before execution.  Workflow Time Reduction and Operational Efficiency Integration of the agentic platform into end-to-end hospital workflows produced measurable time reductions across eight core operational tasks, validated through time-motion studies conducted during the supervised pilot phase.

www.ijisrt.com

2782

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 16 Comparison Visualization of Task Duration with and Without Agentic AI Platform The comparative task-duration analysis reveals that the agentic platform delivers time savings in triage assessment time which decreased by 30% (from 67 to 47 minutes average per shift), bed assignment coordination by 56% (from 48 to 21 minutes), imaging order placement by 7% (from 32 to 19 minutes), and discharge summary generation by 31% (from 195 to 135 minutes per case) [ Fig]. Billing and coding verification dropped by 36%, and claims submission coordination by 26%, reflecting the efficiency of agent-mediated documentation review and automated billingrule application [ Fig].  Financial Return on Investment A five-year total-cost-of-ownership (TCO) and return-oninvestment (ROI) analysis was conducted comparing the siloed point-solution deployment model against the proposed Agentic AI platform architecture [Fig]. The analysis incorporated initial infrastructure investment, recurring cloud and licensing costs, data engineering and integration effort, governance and compliance overhead, and operational savings from workflow efficiency and documentation burden reduction. The ROI projection reveals a fundamental economic divergence between deployment models. Siloed tools exhibit escalating cumulative costs year-over-year (indexed 100 → 168

IJISRT26MAY1651

by Year 5) [Fig] due to per-project integration effort, duplicated governance infrastructure, and lack of reuse across AI use cases. Each new tool demands its own data pipeline, access control configuration, audit logging setup, and regulatory validation cycle, compounding both technical debt and compliance risk. In contrast, the Agentic AI platform architecture front-loads investment in Years 1–2 to establish the data fabric, orchestration layer, and policy-as-code infrastructure, but then experiences declining marginal costs as each new AI agent leverages shared services [Fig]. By Year 3, the platform cost curve is predicted to cross below the siloed baseline; by Year 5, cumulative cost savings would exceed USD 8.2 million, which is nearly 67% relative to continued siloed deployment, for the pilot hospital, with ROI gains indexed to 113 points above baseline [Fig]. This crossover pattern is characteristic of platform economics and confirms that hospital AI investment must be evaluated on a multi-year, portfolio basis rather than per-tool business cases. Operational savings derived primarily from documentation burden reduction (valued at USD 3.1 million over five years based on clinician time reclaimed), reduced integration and maintenance labour (USD 2.8 million), and lower governance and compliance overhead due to centralised, automated policy enforcement (USD 2.3 million). Revenue-cycle improvements from more accurate coding and faster claims submission contributed an additional USD 1.4 million in net present value [Fig].

www.ijisrt.com

2783

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Fig 17 5-Year ROI Projection: Siloed v/s Agentic AI Platform Deployment  Regulatory Compliance Coverage and Governance Maturity The Compliance and Policy Layer was pre-configured with policy-as-code rulesets mapping to HIPAA Security Rule administrative, physical, and technical safeguards, GDPR special-category data processing requirements (Articles 6, 9, 32, 35), EU AI Act high-risk system obligations (Articles 9–15, including risk management, data governance, logging, transparency, and human oversight), India DPDP Act consent and purpose limitation clauses [44][45], and DISHA draft [44] provisions on health data ownership and crossborder transfer restrictions.

Compliance coverage was assessed through automated policy audits, manual technical documentation review, and third-party regulatory gap analysis. The platform achieved 95% coverage of HIPAA Security Rule safeguards, 92% of GDPR technical and organisational measures, 88% of EU AI Act high-risk obligations, 90% of DPDP Act requirements, 85% of DISHA draft clauses, 94% of ISO/IEC 27001 controls, and 87% of ISO 14971 risk management requirements [Fig].

Fig 18 Regulatory Compliance Coverage: Siloed Tools vs Agentic AI Platform IJISRT26MAY1651

www.ijisrt.com

2784

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

The compliance coverage comparison demonstrates that policy-as-code architecture is not merely a convenience feature but a structural compliance enabler. Siloed tools achieve 15–42% coverage across regulatory frameworks because compliance obligations are addressed reactively, perproject, and inconsistently, with no enterprise visibility into which controls apply to which models or data flows [Fig]. The agentic platform, by contrast, treats compliance as a reusable architectural service, encoding regulatory clauses as enforceable rules in the Compliance and Policy Layer that apply automatically to every agent, every data access, and every model inference. Coverage above 85% across all frameworks [Fig], including the stringent EU AI Act high-risk provisions and India's emerging DPDP and DISHA regime, positions the platform as deployment-ready in multijurisdictional hospital networks without requiring per-

country architectural redesign. The residual 5–15% gap [Fig] reflects obligations that require human judgment (e.g., clinical validation, ethics board review) or that apply at organisational rather than technical levels, and these are explicitly documented in governance playbooks provided with the platform.  Integration Complexity and Technical Debt Reduction One of the platform's most consequential but least visible benefits is the reduction in integration effort and technical debt accumulation as the AI portfolio scales. In siloed deployments, each new AI tool requires bespoke data extraction, transformation, and loading (ETL) pipelines, separate access control and authentication configuration, independent logging and monitoring infrastructure, and project-specific governance validation.

Fig 19 Integration Effort Required: Siloed vs Agentic AI Platform Approach (Effort Units) Integration effort is the hidden tax of siloed AI deployment, in simple terms, and this comparison [Fig] quantifies its magnitude. Data integration, the task of connecting a new AI tool to EHR, PACS, LIS, and billing systems, consumes 85 effort units in the siloed model [Fig] because each tool negotiates its own API contracts, data formats, and error-handling logic. The Agentic AI platform, on the other hand, reduces this to 25 units by exposing a single, standardised data fabric interface that every agent uses, eliminating per-project negotiation [Fig]. Access control similarly drops from 78 to 18 units because the Compliance and Policy Layer provide OAuth 2.0 and RBAC as shared services rather than per-tool IAM configurations [Fig], as in the pilot implementation the deployment was done without AWS IAM. Audit trail setup, policy enforcement, workflow routing, and model governance all follow the same pattern: high per-project cost in siloed deployments, near-zero marginal cost in the Agentic AI model once the shared infrastructure is in place [Fig]. The cumulative effect is a 70– IJISRT26MAY1651

80% reduction in integration effort for each new AI agent added to the portfolio, which directly translates to faster timeto-deployment, lower engineering cost, and reduced risk of configuration drift and governance gaps. This is the economic mechanism that produces the ROI crossover observed in [Fig]. The platform model standardises these integrations through the Privacy-Preserving Data Fabric (providing unified, policy-aware data access), the Agent Orchestration Layer (providing standardised agent registration and interagent messaging), and the Compliance and Policy Layer (providing centralised access control, logging, and lifecycle governance). Effort-unit analysis shows that data integration effort drops by 71% (from 85 to 25 units), access control by 77% (78 to 18), audit trail configuration by 77% (65 to 15), and policy enforcement setup by 78% (55 to 12) when moving from siloed to platform deployment [Fig].

www.ijisrt.com

2785

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

This reduction in integration complexity directly mitigates technical debt accumulation, a persistent problem in hospital AI portfolios where each new tool increases the number of point-to-point integrations and the fragility of the overall system. The platform architecture, by establishing a small, stable set of integration contracts that all agents honour, converts the scaling problem from quadratic where each tool potentially interacts with every other tool, to linear where each tool interacts with the platform itself.  Clinician Experience and Documentation Burden Clinician experience was assessed through time-insystem logging, task-completion surveys, and semistructured interviews conducted at baseline and at 6, 12, and 18 months post-deployment. Documentation burden, the primary driver of clinician dissatisfaction with hospital information systems, decreased by an average of 4.2 hours per clinician per week, representing a 31% reduction relative to baseline. The reduction was most pronounced for discharge summaries where 56 minutes saved per case, for progress note generation the reduction was 22 minutes per case, and for coding validation it was 18 minutes per case, all of which benefited from the LLM-powered draft generation, autopopulation from structured EHR data, and agent-mediated review against policy and billing rules. Clinicians reported that AI-generated drafts were "clinically accurate and required only minor edits" in 78% of cases, and that the platform's integrated interface reduced context-switching compared to the baseline fragmented-tool environment. Survey responses indicated a statistically significant improvement in perceived system usability. System Usability Scale score increased from 58.3 to 74.6 with p < 0.001, and a reduction in self-reported technology-related stress, where the burnout inventory technology subscale decreases from 3.8 to 2.9 on a 5-point scale with p < 0.01. Qualitative themes from interviews highlighted the value of "having AI that works across workflows rather than in isolated pockets" and "not needing to learn a new interface for every new tool."  Privacy-Preserving Methods in Production The Privacy-Preserving Data Fabric was instantiated with three privacy-enhancing technologies: federated learning client support for cross-site model training without centralising patient records, differential privacy noise injection for aggregate analytics queries; and hardware-based secure enclave processing for high-sensitivity inference tasks. During the pilot, a federated learning experiment was conducted in collaboration with two peer hospitals to train a readmission risk model across institutions without sharing raw encounter data. The federated model achieved ROC-AUC 0.83, compared to 0.81 for a hospital-specific model trained on local data alone, demonstrating that cross-site learning improves generalisation without compromising data localisation requirements. Differential privacy was applied to all aggregate reporting queries with Epsilon = 2.0, providing formal privacy guarantees while maintaining clinically acceptable accuracy for operational dashboards. Secure IJISRT26MAY1651

enclave processing was used for a small subset of high-risk inferences such as HIV status prediction, psychiatric risk scoring etc., where regulatory or ethical considerations demanded hardware-level isolation, with < 15% latency overhead relative to standard GPU inference. These methods, while not universally applied to every workflow, validate that the architecture can accommodate privacy-preserving techniques as pluggable components when regulatory, ethical, or institutional requirements demand them, an essential capability for deployment in jurisdictions with strict data localisation laws or in multiinstitutional research networks.  Agent Orchestration and Multi-Agent Workflow Execution The Agent Orchestration Layer coordinated 12 domainspecific agents across clinical (triage risk, imaging order prioritisation, discharge planning), operational (bed assignment, staffing optimisation), and financial (coding validation, claims submission) workflows. Agents were registered with capability declarations and tool manifests, allowing the orchestration layer to dynamically route tasks based on agent availability, patient context, and priority rules encoded in the Compliance and Policy Layer. Multi-agent workflows were validated through end-toend pathway testing: an ED encounter, for example, triggered sequential activation of the triage risk agent (acuity assessment), bed assignment agent (resource allocation), imaging order agent (diagnostic pathway), lab processing agent (specimen tracking), documentation agent (note generation), coding agent (billing validation), and claims agent (payer submission). The orchestration layer maintained session state, ensured that outputs from upstream agents were available as inputs to downstream agents, enforced interagent access policies, and logged all decisions and data flows for post-hoc audit. Critic-agent verification was applied selectively to high-stakes outputs: discharge summaries were reviewed by a critic agent that checked clinical coherence, billing code alignment with documented diagnoses, and medication reconciliation completeness before release to the EHR. This verification step reduced discharge summary error rate, defined as requiring substantive clinician correction, by 42% relative to single-agent generation. The orchestration layer's event-driven architecture, implemented using Apache Kafka message queues and FastAPI-based agent endpoints, demonstrated efficient horizontal scalability: agent instances were auto-scaled based on queue depth, and the system sustained peak loads of 340 concurrent patient encounters without degradation in response time or agent availability.  Cross-Jurisdictional Deployment Readiness The platform's architectural design explicitly accommodates regional deployment variants to meet jurisdiction-specific data residency, consent, and regulatory requirements.

www.ijisrt.com

2786

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

For India, the architecture supports on-premise deployment with data localisation, ensuring that patient health information subject to DPDP [42][43] and DISHA [44] regulations never leaves Indian infrastructure. The Compliance and Policy Layer enforces explicit, granular consent requirements and supports patient data subject access requests as mandated by DPDP. For the European Union, the architecture supports hybrid cloud deployment with data residency controls, ensuring that special-category health data processing complies with GDPR Articles 6 and 9 [41], and that high-risk AI systems meet EU AI Act Articles 9–15 [46][49] regulations including risk management, logging, transparency, and post-market monitoring. The platform's audit trail and model card generation capabilities directly support technical documentation requirements under Article 11 [49]. For the United States, the architecture supports HIPAAeligible cloud deployment (AWS GovCloud, Azure Government, Google Cloud Healthcare API) with Business Associate Agreements (BAAs) in place, and enforces HIPAA Security Rule administrative, physical, and technical safeguards through the Compliance and Policy Layer. This regional flexibility, implemented not through separate codebases but through policy configuration and deployment topology choices, positions the platform as a globally deployable reference architecture rather than a region-locked solution.  LLM Integration with ERP, HCM, and HRIS Systems Beyond clinical workflows, the agentic platform demonstrated successful integration with enterprise resource planning (ERP), human capital management (HCM), and human resources information systems (HRIS) to automate administrative and operational tasks. LLM-powered agents were deployed for staff scheduling optimisation, payroll exception handling, supply chain demand forecasting, and vendor contract compliance monitoring. The scheduling agent integrated with the hospital's HCM system (Workday) to ingest shift preferences, union contract rules, and staffing model requirements, and used constraint-satisfaction algorithms augmented by LLMgenerated natural language explanations to produce equitable, compliant schedules, with 23% fewer manual adjustments required compared to baseline human-generated schedules. The supply chain agent queried the ERP system (SAP S/4HANA) for historical consumption data and used timeseries forecasting combined with LLM-based supplier communication to reduce stockout incidents by 34% and excess inventory carrying cost by 19%. Integration with these systems was mediated through the same Privacy-Preserving Data Fabric and Compliance and Policy Layer used for clinical workflows, ensuring that HR and financial data access was role-restricted, logged, and policy-compliant. This unification of clinical and administrative AI under a single governance model is a novel IJISRT26MAY1651

contribution of this architecture, addressing a gap in existing hospital AI literature that treats clinical and operational AI as separate problem domains. VI.

CONCLUSION AND DISCUSSION

 Architectural Contribution and Novelty The primary contribution of this research is the definition of a hospital-specific, compliance-first, sevenlayered Agentic AI architecture that extends the five-layer foundational model with an Agent Orchestration Layer, a Compliance and Policy Layer, and a Privacy-Preserving Data Fabric, and the demonstration that this architecture is technically implementable, operationally viable, and economically superior to siloed point-solution deployment at hospital scale. The architecture is novel in three specific ways. First, it treats agent orchestration as a first-class architectural concern, providing standardised registration, capability discovery, inter-agent messaging, and session-state management as platform services rather than applicationspecific logic. This positions the platform to accommodate the rapidly evolving landscape of LLM-powered multi-agent systems while maintaining governance and auditability. Second, it embeds compliance not as a post-hoc checklist but as a reusable, technically enforced layer that encodes HIPAA [40], GDPR [41], EU AI Act [46][49], DPDP [42][43], and DISHA [44] obligations as executable policy rules applied uniformly across all agents and data flows. This policy-ascode approach is well-established in cloud-native infrastructure (AWS IAM, Azure Policy, Kubernetes RBAC) but has not previously been systematically applied to healthcare AI governance. Third, it defines a privacypreserving data fabric that provides a single, policy-aware interface to heterogeneous HIMS data sources while supporting federated learning, differential privacy, and secure enclave processing as pluggable components rather than separate research tools. This positions the architecture to meet current and anticipated data localisation, consent, and crossborder transfer regulations without requiring per-jurisdiction redesign. These contributions are validated not only through conceptual argumentation but through functional prototype implementation, controlled pilot deployment, and quantified operational and financial outcomes.  Comparison with Existing Hospital AI Platform Literature Maimaitiaili et al. (2024) [128] suggested five-layer architecture identified infrastructure, data, algorithm, application, and security/compliance as essential layers but did not specify how compliance should be technically implemented or how multi-agent orchestration should operate. The present work extends that foundation by defining the technical contracts, APIs, and data flows that make compliance and orchestration reusable platform services. McKinsey's 2025 [129] analysis of hospital AI strategy argues that platform architecture will differentiate successful

www.ijisrt.com

2787

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

AI adopters from those whose investments remain fragmented, but provides only high-level recommendations without technical specification. This research operationalises that insight through a detailed architectural blueprint, regulatory clause mapping, and deployment results. The federated learning and privacy-preserving ML literature, surveyed comprehensively by Dasaradharami Reddy and Gadekallu (2023) [130], Li et al., (2020) [131] and Banabilah et al., (2022) [132] demonstrates that FL, differential privacy, and secure computation are technically mature but rarely integrated into HIMS-scale architectures with governance and compliance controls. Our research closes that gap by showing how these methods can be embedded as governed components of a hospital AI platform. The agentic AI literature documents impressive multiagent performance in controlled settings but provides limited guidance on HIMS integration, auditability, or regulatory alignment. The Agent Orchestration Layer proposed here directly addresses these gaps. Economically, this research aligns with McKinsey, 2025 [129] and IBM Healthcare AI, 2024 [133] value analyses that identify workflow integration and administrative automation as the largest value pools, but goes further by quantifying how architectural choices, platform vs. siloed, determine whether those value pools are accessible.  Implications for Hospital AI Strategy The results demonstrate that hospital AI investment decisions must be evaluated at the portfolio and platform level rather than per-tool, and that architectural choices made early in the adoption curve will determine long-term ROI, scalability, and compliance posture. Hospitals that continue to deploy AI as isolated point solutions will face escalating integration costs, duplicated governance effort, and systemic compliance risk as their portfolios grow. The economic crossover observed in this study, where platform TCO falls below siloed baseline by Year 3 and delivers 67% cost advantage by Year 5, suggests that hospitals should prioritise platform investment even if it delays individual tool deployments in the short term. The value of reusable data pipelines, shared governance infrastructure, and marginal-cost-near-zero agent deployment compounds over time and cannot be captured by project-level business cases that evaluate tools in isolation. For hospital leadership, the strategic implication is clear: AI governance and infrastructure are not IT functions to be delegated and forgotten, but core strategic capabilities that will determine competitive position, regulatory resilience, and workforce sustainability over the next decade.  Regulatory and Compliance Implications The compliance coverage results validate that policyas-code architecture is not aspirational but immediately necessary as healthcare AI regulation matures. The EU AI Act's 2026 [49] implementation deadline for high-risk systems, GDPR's [41] strengthening enforcement posture, IJISRT26MAY1651

and India's evolving DPDP [42][43], DISHA [44] framework all demand that hospitals have centrally managed, auditable, version-controlled governance mechanisms that apply uniformly across all AI deployments. Hospitals that rely on per-project, per-vendor compliance assessments will struggle to demonstrate enterprise-level oversight to regulators, auditors, and boards. The Compliance and Policy Layer proposed here provides that oversight capability while also reducing the per-project compliance burden by encoding obligations once and applying them everywhere. The architecture's regional deployment variants, onpremise for India, hybrid cloud for EU, HIPAA-eligible cloud for US, demonstrate that cross-jurisdictional compliance is achievable without maintaining separate codebases or governance models, which is essential for multinational hospital networks and for platforms intended to be globally marketable.  Workforce and Clinician Experience Implications The 31% reduction in documentation burden and 4.2 hours per week reclaimed per clinician is not merely a productivity gain but a workforce-retention and patient-safety intervention. Research by Shanafelt et al. (2016) [134] and subsequent studies has established that documentation burden is a primary driver of physician burnout, turnover intention, and reduced patient interaction quality. The architecture’s ability to integrate documentation assistance, workflow routing, and compliance logging into a single human-governed system, rather than adding yet another interface that clinicians must learn, directly addresses the root cause: cognitive overload from fragmented digital workflows. The qualitative feedback from pilot participants, emphasising relief at "not needing to learn a new interface for every new tool," confirms that platform integration delivers user-experience value that siloed tools cannot. For hospital chief medical officers and chief nursing officers, this result implies that AI adoption should be evaluated not only on clinical accuracy or operational efficiency but on its impact on clinician workload, interface fragmentation, and cognitive burden. Platforms that reduce context-switching and consolidate workflows will improve adoption and retention while tools that add interfaces and alerts without integration and human governance will increase burnout regardless of their underlying AI performance.  Cloud Computing, Database Management, and LongTerm Sustainability The platform's reliance on cloud-native infrastructure, containerised agent microservices, managed Kubernetes orchestration, object storage for model artifacts, serverless functions for event-driven workflows, and managed database services for audit logs, positions it to benefit from ongoing cloud provider innovation in ML infrastructure, security, and compliance.

www.ijisrt.com

2788

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

Major cloud vendors (AWS, Azure, Google Cloud) are rapidly expanding HIPAA-eligible, GDPR-compliant, and region-specific infrastructure offerings, including confidential computing enclaves, hardware security modules (HSMs), and compliance certifications that align with healthcare regulatory frameworks. The platform's abstraction of infrastructure concerns through the Privacy-Preserving Data Fabric and Compliance and Policy Layer means that hospitals can adopt new cloud capabilities, such as GPUoptimised inference, real-time streaming analytics, or quantum-resistant cryptography, without redesigning application logic. Database management strategy is similarly futureoriented. The platform uses a polyglot persistence model: relational databases (PostgreSQL) for structured clinical data and audit logs, document stores (MongoDB) for unstructured clinical notes and model metadata, and graph databases (Neo4j) for care pathway and referral network analytics. This approach allows each data type to be stored in the system best suited to its access patterns and query requirements, while the Privacy-Preserving Data Fabric provides a unified, policyaware query interface that abstracts underlying database heterogeneity. Long-term sustainability depends on three factors: vendor ecosystem participation, standards adoption, and community governance. The platform's open API specifications and FHIR/HL7 compliance position it for integration with commercial EHR, PACS, and revenue-cycle vendors, reducing the risk of vendor lock-in and enabling hospitals to swap components without architectural redesign. Active participation in emerging standards bodies, such as the HL7 FHIR AI Working Group and the IEEE P2933 Clinical IoT Data and Device Interoperability working group, will ensure that the platform evolves in alignment with industry consensus rather than as a proprietary closed system.  Advocacy from Related Research The architecture's emphasis on platform integration over point solutions finds strong support in recent healthcare AI research. Topol, E. (2019) [9] analysis of AI in medicine argued that fragmented AI tools risk worsening rather than alleviating clinician workload unless they are designed as integrated decision-support layers within existing workflows. The present work operationalises that principle through the Agent Orchestration Layer and unified interface design. Char et al.'s (2020) [[135]] framework for AI ethics in healthcare emphasises that fairness, accountability, and transparency cannot be achieved through post-hoc audits but must be embedded in technical architecture. The Compliance and Policy Layer directly implements this vision by making policy enforcement and audit logging architectural rather than procedural. Obermeyer et al.'s (2019) [[136]] study of algorithmic bias in healthcare risk prediction demonstrated that seemingly neutral algorithms can perpetuate systemic inequities when trained on biased data or deployed without oversight. The platform's centralised model governance and drift-monitoring IJISRT26MAY1651

capabilities provide the technical infrastructure necessary to detect and mitigate such biases at scale. Kelly et al.'s (2019) [22] systematic review of AI in radiology found that most published algorithms remain in research settings because they lack the governance, integration, and regulatory validation pathways required for clinical deployment. The present architecture directly addresses these barriers by providing governance and integration as reusable platform services. Price et al.'s (2019) [137] analysis of HIPAA and AI concluded that existing regulatory frameworks are adequate if properly implemented, but that most healthcare organisations lack the technical capabilities to implement them systematically. The Compliance and Policy Layer provides those capabilities. Collectively, these studies reinforce the central thesis of this research: hospital AI requires not better algorithms but better architecture, and that architecture must prioritise governance, integration, and compliance as first-class concerns rather than afterthoughts.  Indirect Strategic Implications for Healthcare Organisations While this research is presented as a technical and regulatory contribution, its strategic implications for healthcare organisations, and for vendors, consultancies, and investors in the healthcare AI market, are profound. Hospitals and health systems that adopt platform-based AI architectures early will establish structural advantages in cost, compliance, and clinical capability that will be difficult for late adopters to overcome. The economic crossover and cumulative ROI gains documented in this study suggest that the next three to five years represent a critical window during which architectural choices will lock in long-term competitive position. For AI vendors, the shift from point solutions to platform integration implies a fundamental business model change: success will depend less on algorithm performance in isolation and more on interoperability, governance, and ease of integration with hospital platforms. Vendors that provide agents or modules designed to plug into standardised orchestration layers will gain adoption; those that insist on proprietary, standalone deployment will face declining market access as hospitals consolidate around platforms. For consultancies and system integrators, the demand for AI implementation services will shift from per-project integration (which the platform obsoletes) to platform design, governance configuration, and change management, which infers to higher-value, longer-term engagements that require deep healthcare domain expertise and regulatory fluency. For investors and private equity firms evaluating healthcare AI companies, the distinction between point solutions and platform-ready components is becoming a critical valuation factor. Companies with architectures

www.ijisrt.com

2789

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

aligned to the model proposed here which is modular, policyaware, FHIR/HL7-compliant, cloud-native and will be better positioned for scaling and acquisition, while those with monolithic, proprietary, or governance-weak architectures will face integration barriers that limit addressable market. These implications are not speculative. The pattern observed in adjacent industries such as cloud infrastructure, enterprise software, e-commerce, is that platform economics and network effects strongly favour early architectural standardisation, and that firms that delay platform adoption face compounding disadvantage. Healthcare AI is entering that phase now. DISCLAIMER  Regulatory and Certification Obligations Implementation of AI systems in clinical environments may trigger regulatory review, certification, or approval requirements depending on jurisdiction, use case, and risk classification. The architecture's compliance coverage assessments reflect design-time policy alignment and do not substitute for formal regulatory submissions, third-party audits, or certification processes required by the FDA (US), EMA (EU), CDSCO (India), or other national authorities. Healthcare organisations would solely be responsible for determining which regulatory obligations apply to their deployments and for securing all necessary approvals, certifications, and Business Associate Agreements (BAAs) prior to production use.  Intellectual Property and Open Source Certain components of the platform may be subject to patents, copyrights, or open-source licenses. Implementers are responsible for conducting intellectual property due diligence and securing all necessary licenses, permissions, and agreements before deployment. The architecture's reliance on commercial cloud services, EHR vendor APIs, and LLM models may introduce licensing, vendor lock-in, or data sovereignty considerations that must be evaluated on a case-by-case basis.  Funding and Financial Declaration This research has been conducted independently and was not commissioned, sponsored, or funded by any external organisation, institution, commercial entity, or governmental body. The results and inferences, architectural propositions, and analyses presented herein are solely those of the authors and Instil-IT, Hyderabad, India. And are not influenced by any financial or institutional interests. Any references to specific technologies, vendors, standards, or frameworks are made purely for research purposes and should not be construed as endorsements, affiliations, or preferential recommendations.

study. He led the formulation of the research problem, statistical data analysis, architectural vision, governance framework, compliance-oriented design principles, and the overall structure of the proposed hospital AI platform. He also designed the security architecture and framework, privacypreserving governance architecture, and regulatory alignment strategy underpinning the proposed compliance-first agentic platform. Ritwik Singh contributed as the chief architectural engineer for AI development and ensured that the model development lifecycle remained aligned with applicable technical, operational, and compliance requirements throughout the implementation process. He played a pivotal role in AI system engineering, integration architecture design, and interoperability planning, leading the development of integration modules to ensure seamless connectivity and compatibility with existing Hospital Information Management Systems (HIMS) platforms and enterprise healthcare environments. He also led the deployment and pilot implementation while monitoring the performance and the challenges that surfaced to make necessary changes in the coding. Sharat Chandra Manikonda contributed as the project owner, principal data scientist, and supervised the AI systems development. He led the technical implementation strategy, model engineering workflows, deployment and implementation strategist, orchestration feasibility analysis, and prototype implementation governance. He also contributed to the operationalisation of the architecture, including system integration planning, workflow optimisation logic, and deployment-readiness assessment for real-world hospital environments. All authors collaboratively contributed to the research, design, analysis, validation, and refinement of the proposed architecture, integrating their respective domain expertise to ensure the study’s technical depth, operational relevance, and governance alignment. REFERENCES [1].

[2].

[3].

AUTHOR CONTRIBUTIONS Manideep Dhar contributed as the principal research conceptualizer, principal author, and research planner for this IJISRT26MAY1651

[4].

www.ijisrt.com

Y. Shokrollahi, S. Yarmohammadtoosky, M. M. Nikahd, P. Dong, X. Li, and L. Gu, (2023). A comprehensive review of generative AI in healthcare. arXiv. https://arxiv.org/abs/2310.00795 Y. L. E. Thompson, G. M. Levine, W. Chen, B. Sahiner, Q. Li, N. Petrick, et al., “Applying queueing theory to evaluate wait-time-savings of triage algorithms,” Queueing Syst., vol. 108, no. 3-4, pp. 579–610, 2024., doi:10.1007/s11134-024-09927w D. R. T. Knight, C. A. Aakre, C. V. Anstine, B. Munipalli, P. Biazar, G. Mitri, et al., “Artificial intelligence for patient scheduling in the real-world health care setting: A metanarrative review,” Health Policy Technol., vol. 12, no. 4, p. 100824, 2023., doi: 10.1016/j.hlpt.2023.100824 A. Tang, R. Tam, A. Cadrin-Chênevert, W. Guest, J. Chong, J. Barfett, et al., Applications of artificial 2790

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

[5].

[6].

[7]. [8]. [9].

[10].

[11]. [12].

[13].

[14].

[15].

[16].

[17].

[18].

https://doi.org/10.38124/ijisrt/26may1651

intelligence in the radiology workflow: Process streamlining and optimization. Radiographics / Radiology. ScienceDirect, 2023., doi:10.1053/j.ro.2023.02.003 World Health Organization, (2020). Global strategy on human resources for health: Workforce 2030. https://www.who.int/publications/i/item/97892415111 31 T. D. Shanafelt, L. N. Dyrbye, C. Sinsky, O. Hasan, D. Satele, J. Sloan, et al., “Relationship between clerical burden and characteristics of the electronic environment with physician burnout and professional satisfaction,” Mayo Clin. Proc., vol. 91, no. 7, pp. 836– 848, Jul. 2016., doi:10.1016/j.mayocp.2016.05.007 McKinsey & Company, (2022). The future of US healthcare: What’s next for the industry post-COVID19. https://www.mckinsey.com/industries/healthcare Deloitte, (2023). 2023 Global health care outlook. https://www2.deloitte.com E. J. Topol, “High-performance medicine: The convergence of human and artificial intelligence,” Nat. Med., vol. 25, no. 1, pp. 44–56, Jan. 2019., doi:10.1038/s41591-018-0300-7 D. Kreuzberger, N. Kühl, and S. Hirschl, “Machine learning operations (MLOps): Overview, definition, and architecture,” IEEE Access, vol. 11, pp. 31866– 31879, 2023., doi:10.1109/ACCESS.2023.3262138 Health Level Seven International, (2019). FHIR Release 4 (R4). https://www.hl7.org/fhir/ H. K. Huang, PACS and imaging informatics: Basic principles and applications, 2nd ed., Wiley-Blackwell, 2010, https://openlibrary.org/works/OL1901151W/PACS_a nd_imaging_informatics World Health Organization, (2019). WHO guideline: Recommendations on digital interventions for health system strengthening. https://www.who.int/publications/i/item/9789241550 505 McKinsey & Company, (2021). The future of healthcare: Finding the opportunities that lie beneath the uncertainty. https://www.mckinsey.com/industries/healthcare J. He, S. L. Baxter, J. Xu, J. Xu, X. Zhou, and K. Zhang, “The practical implementation of artificial intelligence technologies in medicine,” Nat. Med., vol. 25, no. 1, pp. 30–36, Jan. 2019., doi:10.1038/s41591018-0307-0 A. L. Kellermann and S. S. Jones, “What it will take to achieve the as-yet-unfulfilled promises of health information technology,” Health Aff. (Millwood), vol. 32, no. 1, pp. 63–68, Jan. 2013., doi:10.1377/hlthaff.2012.0693 J. Adler-Milstein, A. J. Holmgren, P. Kralovec, C. Worzala, T. Searcy, and V. Patel, “Electronic health record adoption and hospital performance: Timerelated effects,” Health Aff. (Millwood), vol. 36, no. 8, pp. 1417–1425, 2017., doi:10.1377/hlthaff.2017.0430 World Health Organization, (2021). Ethics and governance of artificial intelligence for health.

IJISRT26MAY1651

[19]. [20].

[21].

[22].

[23].

[24].

[25].

[26].

[27].

[28].

[29].

[30].

www.ijisrt.com

https://www.who.int/publications/i/item/9789240029 200 Deloitte, (2022). Scaling AI in healthcare: From pilot to enterprise value. https://www2.deloitte.com J. He, S. L. Baxter, J. Xu, J. Xu, X. Zhou, and K. Zhang, “The practical implementation of artificial intelligence technologies in medicine,” Nat. Med., vol. 25, no. 1, pp. 30–36, Jan. 2019., doi:10.1038/s41591018-0307-0 M. Nagendran, Y. Chen, C. A. Lovejoy, A. C. Gordon, M. Komorowski, H. Harvey, et al., “Artificial intelligence versus clinicians: Systematic review of design, reporting standards, and claims of deep learning studies,” BMJ, vol. 368, p. m689, Mar. 25 2020., doi:10.1136/bmj.m689 C. J. Kelly, A. Karthikesalingam, M. Suleyman, G. Corrado, and D. King, “Key challenges for delivering clinical impact with artificial intelligence,” BMC Med., vol. 17, no. 1, p. 195, Oct. 29 2019., doi:10.1186/s12916-019-1426-2 J. Adler-Milstein and A. K. Jha, “HITECH Act drove large gains in hospital electronic health record adoption,” Health Aff. (Millwood), vol. 36, no. 8, pp. 1416–1422, Aug. 1 2017., doi:10.1377/hlthaff.2016.1651 International Organization for Standardization, (2019). ISO 14971: Medical devices—Application of risk management to medical devices. https://www.iso.org/cms/%20render/live/en/sites/isoo rg/contents/data/standard/07/27/72704.html D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, et al., (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems (NeurIPS). https://papers.nips.cc/paper/5656-hidden-technicaldebt-in-machine-learning-systems European Commission, (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). https://eurlex.europa.eu/eli/reg/2024/1689/oj T. D. Shanafelt, L. N. Dyrbye, C. Sinsky, O. Hasan, D. Satele, J. Sloan, et al., “Relationship between clerical burden and characteristics of the electronic environment with physician burnout,” Mayo Clin. Proc., vol. 91, no. 7, pp. 836–848, Jul. 2016., doi:10.1016/j.mayocp.2016.05.007 Fortune Business Insights, (2026). Artificial intelligence (AI) in healthcare market size, share & industry analysis, by platform, application, end-user, and regional forecast, 2026–2034. https://www.fortunebusinessinsights.com/industryreports/artificial-intelligence-in-healthcare-market100534 McKinsey & Company, (2021). Scaling AI: It’s not just about the technology. https://www.mckinsey.com/capabilities/quantumblac k/our-insights/scaling-ai-its-not-just-about-thetechnology Gartner. (2020). Gartner AI in organizations survey. https://www.gartner.com/en/newsroom/press-

2791

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

[31].

[32].

[33].

[34].

[35].

[36].

[37].

[38].

[39].

[40].

[41].

[42].

[43].

[44].

https://doi.org/10.38124/ijisrt/26may1651

releases/2020-02-25-gartner-says-37-percent-oforganizations-have-implemented-ai-in-some-form S. Srinivasan and J. Swaminathan, (2022). A layered architecture for artificial intelligence in healthcare. IEEE Engineering in Medicine and Biology Magazine. https://ieeexplore.ieee.org/document/9777261 McKinsey & Company, (2021). The state of AI in 2021. https://www.mckinsey.com/capabilities/quantumblac k/our-insights/the-state-of-ai-in-2021 Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, et al., (2023). AutoGen: Enabling next-gen LLM applications via multi-agent conversation frameworks. https://arxiv.org/abs/2308.08155 J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein, (2023). Generative agents: Interactive simulacra of human behavior. ACM UIST 2023. https://arxiv.org/abs/2304.03442 Nuance Communications, Inc., & Ignetica. (2022). The burden of clinical documentation in NHS trusts. https://www.nuance.com/content/dam/nuance/en_uk/ collateral/healthcare/white-paper/wp-the-burden-ofclinical-documentation-in-nhs-trusts-en-gb.pdf Freedom of Speech Online, (2015). Accuracy and completeness of clinical documentation.http://www.freedomspeech.co.uk/s/Accuracy_and_completeness_of_clini cal_documentation_2015_FOS.pdf C. Sinsky, L. Colligan, L. Li, M. Prgomet, S. Reynolds, L. Goeders, et al., “Allocation of physician time in ambulatory practice: A time and motion study in 4 specialties,” Ann. Intern. Med., vol. 165, no. 11, pp. 753–760, Dec. 6 2016., doi:10.7326/M16-0961 T. D. Shanafelt, L. N. Dyrbye, C. Sinsky, O. Hasan, D. Satele, J. Sloan, et al., “Relationship between clerical burden and characteristics of the electronic environment with physician burnout,” Mayo Clin. Proc., vol. 91, no. 7, pp. 836–848, Jul. 2016., doi:10.1016/j.mayocp.2016.05.007 European Commission, (2021). Proposal for a regulation laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). https://eurlex.europa.eu/legalcontent/EN/TXT/?uri=CELEX:52021PC0206 U.S. Department of Health & Human Services, (2013). Summary of the HIPAA Security Rule. https://www.hhs.gov/hipaa/forprofessionals/security/laws-regulations/index.html European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). https://eurlex.europa.eu/eli/reg/2016/679/oj Government of India, (2023). Digital Personal Data Protection Act, 2023. https://www.meity.gov.in/writereaddata/files/Digital_ Personal_Data_Protection_Act_2023.pdf Ministry of Electronic and Information Technology, (2023). Explanatory note on the Digital Personal Data Protection Act, 2023. https://www.meity.gov.in Ministry of Health and Family Welfare, (2018). Digital Information Security in Healthcare Act (DISHA) – Draft. https://main.mohfw.gov.in

IJISRT26MAY1651

[45]. N. I. T. I. Aayog, (2020). National Digital Health Blueprint. https://www.niti.gov.in [46]. European Data Protection Board, “Guidelines on consent under,” Regulation, vol. 2016, no. 679, 2020. Available: https://edpb.europa.eu [47]. U.S. Department of Health & Human Services, (2013). Breach notification rule. https://www.hhs.gov/hipaa/for-professionals/breachnotification/index.html [48]. E. Rojas, J. Munoz-Gama, M. Sepúlveda, and D. Capurro, “Process mining in healthcare: A literature review,” J. Biomed. Inform., vol. 61, pp. 224–236, Jun. 2016., doi:10.1016/j.jbi.2016.04.007 [49]. European Union. (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). https://eurlex.europa.eu/eli/reg/2024/1689/oj [50]. Health Level Seven International, (2019). HL7 Version 2 product suite. https://www.hl7.org/implement/standards/product_bri ef.cfm?product_id=185 [51]. National Electrical Manufacturers Association, (2023). Digital Imaging and Communications in Medicine (DICOM) standard. https://www.dicomstandard.org/current [52]. Health Level Seven International, (2019). FHIR Release 4 (R4). https://www.hl7.org/fhir/ [53]. J. C. Mandel, D. A. Kreda, K. D. Mandl, I. S. Kohane, and R. B. Ramoni, “SMART on FHIR: A standardsbased, interoperable apps platform for electronic health records,” J. Am. Med. Inform. Assoc., vol. 23, no. 5, pp. 899–908, Sep. 2016., doi: 10.1093/jamia/ocv189 [54]. T. Benson and G. Grieve, Principles of health interoperability: SNOMED CT, HL7 and FHIR, 4th ed., Springer, 2021., doi:10.1007/978-3-030-56883-5 [55]. M. G. Kahn, J. S. Brown, A. T. Chun, B. N. Davidson, D. Meeker, P. B. Ryan, et al., “Transparent reporting of data quality in distributed data networks,” EGEMS (Wash. DC), vol. 4, no. 1, p. 1232, 2016., doi:10.13063/2327-9214.1232 [56]. CrowdFlower Inc, (2016). The data scientist report: 2016. https://visit.figure-eight.com/rs/416-ZBE142/images/CrowdFlower_DataScienceReport_2016. pdf [57]. T. Dasu and T. Johnson, Exploratory data mining and data cleaning. Wiley, 2003., doi: 10.1002/0471448354 [58]. D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, et al., (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems (NeurIPS).https://papers.nips.cc/paper/5656-hiddentechnical-debt-in-machine-learning-systems [59]. IBM, (2021). Data fabric architecture: A unified approach to data integration.https://www.ibm.com/cloud/learn/datafabric [60]. National Institute of Standards and Technology, (2020). NIST Privacy Framework: A tool for improving privacy through enterprise risk management (Version 1.0). https://www.nist.gov/privacy-framework

www.ijisrt.com

2792

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

[61]. R. Bommasani, D. A. Hudson, E. Adeli, R. Altman, S. Arora, S. von Arx, et al., (2021). On the opportunities and risks of foundation models. https://arxiv.org/abs/2108.07258 [62]. Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, et al., (2023). AutoGen: Enabling next-gen LLM applications via multi-agent conversation frameworks. https://arxiv.org/abs/2308.08155 [63]. B. McMahan, E. Moore, D. Ramage, S. Hampson, and B. Aguera y Arcas, (2017). Communication-efficient learning of deep networks from decentralized data. https://arxiv.org/abs/1602.05629 [64]. Amazon Web Services, (2022). What is event-driven architecture? https://aws.amazon.com/event-drivenarchitecture/ [65]. Cloud Native Computing Foundation, (2020). Policy as code (OPA and cloud-native governance). https://www.cncf.io [66]. J. He, S. L. Baxter, J. Xu, J. Xu, X. Zhou, and K. Zhang, “The practical implementation of artificial intelligence technologies in medicine,” Nat. Med., vol. 25, no. 1, pp. 30–36, Jan. 2019., doi:10.1038/s41591018-0307-0 [67]. U.S. Department of Health & Human Services, (n.d.). Security standards for the protection of electronic protected health information (45 CFR Part 164 Subpart C). https://www.ecfr.gov/current/title-45/subtitleA/subchapter-C/part-164/subpart-C [68]. National Institute of Standards and Technology, (2008). An introductory resource guide for implementing the HIPAA Security Rule (NIST SP 80066 Rev. 1). https://csrc.nist.gov/publications/detail/sp/800-66/rev1/final [69]. D. McGraw, “Building public trust in uses of Health Insurance Portability and Accountability Act deidentified data,” J. Am. Med. Inform. Assoc., vol. 20, no. 1, pp. 29–34, Jan. 1 2013., doi:10.1136/amiajnl2012-001028 [70]. U.S. Food and Drug Association. (2021). Artificial intelligence/machine learning (AI/ML)-based software as a medical device (SaMD) action plan. https://www.fda.gov/media/145022/download [71]. National Health Authority, (2021). Health Data Management Policy. https://abdm.gov.in:8081/uploads/health_data_manag ement_policy.pdf [72]. International Organization for Standardization, (2022). ISO/IEC 27001:2022—Information security, cybersecurity and privacy protection—Information security management systems—Requirements. https://www.iso.org/standard/82875.html [73]. International Organization for Standardization, (2022). ISO/IEC 27002:2022—Information security, cybersecurity and privacy protection—Information security controls. https://www.iso.org/standard/75652.html [74]. National Institute of Standards and Technology. (2018). Framework for improving critical infrastructure cybersecurity (Version 1.1)., doi:10.6028/NIST.CSWP.04162018 IJISRT26MAY1651

[75]. International Organization for Standardization, (2016). ISO 13485:2016—Medical devices—Quality management systems—Requirements for regulatory purposes. https://www.iso.org/standard/59752.html [76]. International Electrotechnical Commission, (2006). IEC 62304:2006—Medical device software— Software lifecycle processes. https://www.iec.ch/dyn/www/f?p=103:85:0::::FSP_L ANG_ID:25 [77]. International Medical Device Regulators Forum, (2013). Software as a medical device (SaMD): Key definitions. https://www.imdrf.org/documents/software-medicaldevice-samd-key-definitions [78]. International Organization for Standardization, (2023). ISO/IEC 42001:2023—Artificial intelligence— Management system. https://www.iso.org/standard/81230.html [79]. National Institute of Standards and Technology, (2023). AI risk management framework (AI RMF 1.0). https://www.nist.gov/itl/ai-risk-managementframework [80]. T. Schick, J. Dwivedi-Yu, R. Dessì, R. Raileanu, M. Lomeli, E. Hambro, et al., (2023). Toolformer: Language models can teach themselves to use tools. https://arxiv.org/abs/2302.04761 [81]. S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, et al., (2023). ReAct: Synergizing reasoning and acting in language models. https://arxiv.org/abs/2210.03629 [82]. American Medical Association, (2022). Augmented intelligence in health care. https://www.amaassn.org/practice-management/digital/augmentedintelligence-health-care [83]. National Academies of Science Engineering and Medicine. (2019). Integrating social care into the delivery of health care: Moving upstream to improve the nation’s health., doi:10.17226/25467 [84]. World Health Organization, (2009). WHO guidelines for safe surgery 2009. https://www.who.int/publications/i/item/9789241598 552 [85]. Y. Du, S. Li, A. Torralba, J. B. Tenenbaum, and I. Mordatch, (2024). Improving factuality and reasoning in language models through multiagent debate.https://arxiv.org/abs/2305.14325 [86]. Microsoft, (2023). AutoGen: Multi-agent conversation framework (technical report & blog). https://www.microsoft.com/enus/research/project/autogen/ [87]. S. Secinaro, D. Calandra, A. Secinaro, V. Muthurangu, and P. Biancone, “The role of artificial intelligence in healthcare: A structured literature review,” BMC Med. Inform. Decis. Mak., vol. 21, no. 1, p. 125, Apr. 10 2021., doi:10.1186/s12911-021-01488-9 [88]. A. Esteva, B. Kuprel, R. A. Novoa, J. Ko, S. M. Swetter, H. M. Blau, et al., “Dermatologist-level classification of skin cancer with deep neural networks,” Nature, vol. 542, no. 7639, pp. 115–118, Feb. 2 2017., doi:10.1038/nature21056

www.ijisrt.com

2793

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

[89]. M. Matheny, S. T. Israni, M. Ahmed, and D. Whicher, Eds. Artificial intelligence in health care: The hope, the hype, the promise, the peril. National Academy of Medicine, 2019., doi: 10.17226/25563 [90]. M. Wooldridge, An introduction to multiagent systems, 2nd ed., Wiley, 2009., doi: 10.1002/9780470519462 [91]. P. N. Srinivasu, G. L. Aruna Kumari, S. Ahmed, and A. Alhumam, “Exploring Agentic AI in Healthcare: A study on its working mechanism,” Front. Med. (Lausanne), vol. 12, p. 1753443, Jan. 28 2026., doi:10.3389/fmed.2025.1753443 [92]. L. Petersson, I. Larsson, J. M. Nygren, P. Nilsen, M. Neher, J. E. Reed, et al., “Challenges to implementing artificial intelligence in healthcare: A qualitative interview study with healthcare leaders in Sweden,” BMC Health Serv. Res., vol. 22, no. 1, p. 850, Jul. 1 2022., doi:10.1186/s12913-022-08215-8 [93]. M. Amini, et al., “Artificial intelligence ethics in healthcare: Challenges and opportunities under GDPR,” J. Med. Syst., vol. 47, p. 102, 2023., doi:10.1007/s10916-023-01934-6 [94]. World Economic Forum, (2022). Shaping the future of artificial intelligence governance. https://www.weforum.org/reports/shaping-the-futureof-artificial-intelligence-governance [95]. Organisation for Economic Co-operation and Development, (2024). Scaling artificial intelligence in health: Lessons for policy and practice.https://www.oecd.org/health/scalingartificial-intelligence-in-health.htm [96]. N. Rieke, J. Hancox, W. Li, F. Milletarì, H. R. Roth, S. Albarqouni, et al., “The future of digital health with federated learning,” NPJ Digit. Med., vol. 3, no. 119, p. 119, Sep. 14 2020., doi:10.1038/s41746-020-003231 [97]. B. McMahan, E. Moore, D. Ramage, S. Hampson, and B. Aguera y Arcas, (2017). Communication-efficient learning of deep networks from decentralized data. In Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS 2017) (pp. 1273–1282). https://proceedings.mlr.press/v54/mcmahan17a.html [98]. Dwork, C., & Roth, A. (2014). The algorithmic foundations of differential privacy. Foundations and Trends® in Theoretical Computer Science, 9(3–4), 211–407., doi:10.1561/0400000042 [99]. M. Abadi, A. Chu, I. Goodfellow, H. B. McMahan, I. Mironov, K. Talwar, et al., (2016). Deep learning with differential privacy. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (pp. 308–318)., doi:10.1145/2976749.2978318 [100]. K. Bonawitz, V. Ivanov, B. Kreuter, A. Marcedone, H. B. McMahan, S. Patel, et al., (2017). Practical secure aggregation for privacy-preserving machine learning. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 1175–1191)., doi:10.1145/3133956.3133982 [101]. A. C. Yao, (1982). Protocols for secure computations. In 23rd Annual Symposium on Foundations of IJISRT26MAY1651

Computer Science (SFCS 1982) (pp. 160–164)., doi:10.1109/SFCS.1982.38 [102]. N. Rieke, J. Hancox, W. Li, F. Milletarì, H. R. Roth, S. Albarqouni, et al., “The future of digital health with federated learning,” NPJ Digit. Med., vol. 3, no. 119, p. 119, Sep. 14 2020., doi:10.1038/s41746-020-003231 [103]. T. Li, A. K. Sahu, A. Talwalkar, and V. Smith, “Federated learning: Challenges, methods, and future directions,” IEEE Signal Process. Mag., vol. 37, no. 3, pp. 50–60, 2020., doi:10.1109/MSP.2020.2975749 [104]. Kairouz, P., McMahan, H. B., Avent, B., Bellet, A., Bennis, M., Bhagoji, A. N., Bonawitz, K., Charles, Z., Cormode, G., Cummings, R., D’Orazio, V., Eichner, H., El Rouayheb, S., Evans, D., Gardner, J., et al. (2021). Advances and open problems in federated learning. Foundations and Trends® in Machine Learning, 14(1–2), 1–210., doi:10.1561/2200000083 [105]. L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Gao, et al., (2023). A survey of large language model based autonomous agents. https://arxiv.org/abs/2308.11432 [106]. J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein, (2023). Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (UIST ’23)., doi:10.1145/3586183.3606763 [107]. A. Singh, V. Patel, and N. Kumar, “Challenges and opportunities in integrating large language models with healthcare information systems: A review,” J. Biomed. Inform., vol. 157, p. 104728, 2024., doi:10.1016/j.jbi.2024.104728 [108]. U. M. Borghoff, A. Heinzl, and R. Pareschi, “Human oversight and accountability in agentic AI systems for healthcare,” AI Soc.; Advance online publication, 2025., doi:10.1007/s00146-025-01987-4 [109]. H. Qiu, et al., “Towards artificial general intelligence via a multimodal foundation model,” Nat. Mach. Intell., vol. 6, no. 1, pp. 15–28, 2024., doi:10.1038/s42256-023-00765-7 [110]. World Health Organization, (2016). Framework on integrated, people-centred health services. https://www.who.int/publications/i/item/WHO-HISSDS-2016.19 [111]. M. Abou Ali, F. Dornaika, and J. Charafeddine, “Agentic AI: A comprehensive survey of architectures, applications, and future directions,” Artif. Intell. Rev., vol. 59, no. 1, p. 11, 2026., doi:10.1007/s10462-02511422-4 [112]. B. Shneiderman, “Human-centered artificial intelligence: Reliable, safe & trustworthy,” Int. J. Hum. Comput. Interact., vol. 36, no. 6, pp. 495–504, 2020., doi:10.1080/10447318.2020.1741118 [113]. K. W. Johnson, J. Torres Soto, B. S. Glicksberg, K. Shameer, R. Miotto, M. Ali, et al., “Artificial intelligence in healthcare: Frameworks for governance, validation, and operational oversight,” NPJ Digit. Med., vol. 7, no. 41, 2024., doi:10.1038/s41746-024-01041-2

www.ijisrt.com

2794

Volume 11, Issue 5, May – 2026

International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

https://doi.org/10.38124/ijisrt/26may1651

[114]. A. Rajkomar, J. Dean, and I. Kohane, “Machine learning in medicine,” N. Engl. J. Med., vol. 380, no. 14, pp. 1347–1358, Apr. 4 2019., doi:10.1056/NEJMra1814259 [115]. J. Lamb, (2024, July 25). Generative AI in healthcare: Adoption trends and what’s next. McKinsey & Company. https://www.mckinsey.com/industries/healthcare/ourinsights/generative-ai-in-healthcare-adoption-trendsand-whats-next [116]. A. Krishna, D. Friend, N. Gohad, and P. Reddy, (2025, November 18). The coming evolution of healthcare AI toward a modular architecture. McKinsey & Company. https://www.mckinsey.com/industries/healthcare/ourinsights/the-coming-evolution-of-healthcare-aitoward-a-modular-architecture [117]. V. I. Madai and D. C. Higgins, (2021, July 28). Artificial intelligence in healthcare: lost in translation? arXiv.org. https://arxiv.org/abs/2107.13454 [118]. M. Hassan, A. Kushniruk, and E. Borycki, “Barriers to and Facilitators of Artificial intelligence adoption in Health Care: Scoping review,” JMIR Hum. Factors, vol. 11, p. e48633, Aug. 29 2024., doi:10.2196/48633 [119]. M. F. Wibowo, A. Pyle, E. Lim, J. W. Ohde, N. Liu, and J. Karlström, “Insights into the current and future state of AI adoption within health systems in Southeast Asia: Cross-Sectional Qualitative Study,” J. Med. Internet Res., vol. 27, p. e71591, Jun. 16 2025., doi:10.2196/71591 [120]. K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research methodology for information systems research,” J. Manage. Inf. Syst., vol. 24, no. 3, pp. 45–77, 2007., doi:10.2753/MIS0742-1222240302 [121]. W . Jeanne, Ross, Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business School Press. https://store.hbr.org/product/enterprisearchitecture-as-strategy-creating-a-foundation-forbusiness-execution/8398 [122]. Synthea. https://synthetichealth.github.io/synthea/ [123]. J. Walonoski, M. Kramer, J. Nichols, A. Quina, C. Moesel, D. Hall, et al., “Synthea: An approach, method, and software mechanism for generating synthetic patients and the synthetic electronic health care record,” J. Am. Med. Inform. Assoc., vol. 25, no. 3, pp. 230–238, Mar. 1 2018., doi 10.1093/jamia/ocx079 [124]. F. Perez and I. Ribeiro, (2022). Ignore previous prompt: Attack techniques for language models. https://arxiv.org/abs/2211.09527 [125]. Open Worldwide Application Security Project, (2024). OWASP Top 10 for Large Language Model Applications 2024. https://owasp.org/www-projecttop-10-for-large-language-model-applications/ [126]. National Institute of Standards and Technology, (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://www.nist.gov/itl/airisk-management-framework [127]. R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-based access control models,” IJISRT26MAY1651

Computer, vol. 29, no. 2, pp. 38–47, 1996., doi:10.1109/2.485845 [128]. M. Maimaitiaili, C. Weng, and Y. Luo, “Artificial intelligence architecture frameworks for smart hospitals: A layered platform perspective,” J. Biomed. Inform., vol. 154, p. 104702, 2024., doi:10.1016/j.jbi.2024.104702 [129]. McKinsey & Company, (2025). The economic potential of generative AI in healthcare and hospital operations. https://www.mckinsey.com/industries/healthcare/ourinsights/the-economic-potential-of-generative-ai-inhealthcare [130]. P. Dasaradharami Reddy and T. R. Gadekallu, “Federated learning for healthcare informatics: Concepts, applications, and privacy preservation challenges,” IEEE Access, vol. 11, pp. 41265–41289, 2023., doi:10.1109/ACCESS.2023.3268447 [131]. T. Li, A. K. Sahu, A. Talwalkar, and V. Smith, “Federated learning: Challenges, methods, and future directions,” IEEE Signal Process. Mag., vol. 37, no. 3, pp. 50–60, 2020., doi:10.1109/MSP.2020.2975749 [132]. S. Banabilah, M. Aloqaily, and Y. Jararweh, “Privacypreserving healthcare data sharing using federated learning: A survey,” Sensors (Basel), vol. 22, no. 2, p. 612, 2022., doi:10.3390/s22020612 [133]. IBM Healthcare Insights, (2024). AI in healthcare: Operational efficiency, workflow transformation, and enterprise value. https://www.ibm.com/thoughtleadership/institute-business-value/en-us/report/aihealthcare [134]. T. D. Shanafelt, L. N. Dyrbye, C. Sinsky, O. Hasan, D. Satele, J. Sloan, et al., “Relationship between clerical burden and characteristics of the electronic environment with physician burnout and professional satisfaction,” Mayo Clin. Proc., vol. 91, no. 7, pp. 836– 848, Jul. 2016., doi:10.1016/j.mayocp.2016.05.007 [135]. D. S. Char, N. H. Shah, and D. Magnus, “Implementing machine learning in health care — Addressing ethical challenges,” N. Engl. J. Med., vol. 378, no. 11, pp. 981–983, Mar. 15 2018., doi:10.1056/NEJMp1714229 [136]. Z. Obermeyer, B. Powers, C. Vogeli, and S. Mullainathan, “Dissecting racial bias in an algorithm used to manage the health of populations,” Science, vol. 366, no. 6464, pp. 447–453, Oct. 25 2019., doi:10.1126/science.aax2342 [137]. W. N. Price, II and I. G. Cohen, “Privacy in the age of medical big data,” Nat. Med., vol. 25, no. 1, pp. 37–43, Jan. 2019., doi:10.1038/s41591-018-0272-7

www.ijisrt.com

2795

Related documents

• From Single Chatbots to Governed Agent Ecosystems: An Agentic AI Pattern Catalogue and Orchestration Framework for Mission-Critical Hospital Information Management Systems#973300
• A Taxonomy of Architecture Options for Foundation Model-based Agents: Analysis and Decision Model#987379
• Hierarchical Server Architecture for Agentic Science#432505
• ORCH: Organizational Principles Enable Collective Intelligence in Embodied AI#999426
• The Evolution of Design Thinking in the Age of Foundation Models: Revisiting Verganti’s Framework (2020-2025)#75398