Integrating Cognitive Computing into Hospital Information Management Systems: A Comparative and Architectural Approach Using IBM Watson and Microsoft Azure

1. Introduction

Artificial Intelligence (AI) is revolutionizing the tech landscape across various industries at a rapid rate, and the healthcare industry is no exception. As much as AI has made significant strides in areas of diagnostic imaging, patient engagement, and treatment planning, its integration into traditional Hospital Information Management Systems (HIMS) remains low. Legacy systems like Meditech are likely siloed module-oriented, centralized databases, and manually entered data, leading to inefficiencies and low scalability. These constraints impair the ability to analyze data in real time, deliver personalized care, and preserve interoperability with emerging technologies[1].

To address these deficiencies, cognitive computing presents a thrilling solution. IBM Watson and Microsoft Azure, among others, possess the advanced features of Natural Language Processing (NLP), predictive analytics, and cloud-based secure storage, making them ideal candidates to revolutionize HIMS. IBM Watson provides intelligent decision-support systems and adaptive machine learning, while Microsoft Azure emphasizes interoperability, compliance, and robust data handling frameworks[2,3].

Research in this paper posits a total hybrid architecture by combining IBM Watson's strengths with those of Microsoft Azure to supplement hospital information management. Research herein compares the abilities of the two separate systems, places them into perspective by relating them to one another, and gives a recommended system architecture tailored to meet new demands of current healthcare facilities. Moreover, the paper analyzes ethical and regulatory implications and gives cost-saving phased deployment strategies to guide rollout into actual settings[4,5,6,7].

It can be seen that Artificially Intelligent systems contain the key to assist computer systems in different industries. Nevertheless, the utilization of these cognitive systems in legacy Hospital Information Management System (HIMS) is few and far between. The integration of these systems can automate hospital procedures, execute administrative tasks and enhance patient healthcare experience (Pillai, 2023). This project will discuss the possibilities of using high-end computer resources for enhancing hospital operations such as administrative services, and patient health care experiences in typical Health Information Management Systems such as Meditech, with elaborate implementation plans and analysis at each phase[8,9,10].

The healthcare sector is utilizing artificial intelligence to enhance patient care and drug therapies. IBM Watson and Microsoft Azure are the leaders in this area, proving the power of cognitive computing. International Business Machines (IBM) is a technology company that is well known for their hardware and software products like the newly developed artificial intelligence program, IBM Watson [11,12,13,14,15,16]. The program became famous because of IBM's massive research on learning and responding to intricate linguistic inputs. The program has grown to revolutionize industries in general from cybersecurity to data analysis and beyond [17].

Among the efforts to transform IBM Watson into a suitable system which can be operational in the healthcare division, one of the Artificial Intelligence developed by IBM is the IBM Watsonx Assistant AI healthcare chatbots (IBM, 2024a). It was designed with machine learning and Natural Language Processing (NLP) aiming to assist medical professionals and their staff reduce human error by leveraging the power of generative AI. Apart from possessing AI health chatbots, IBM Watson has numerous features that are significant and can make the healthcare department's system architecture more robust by implementing this system. To begin with, IBM Watson possesses the characteristics of its base which can help healthcare[18,19,20].

department to expand its data incrementally because the AI is cloud-based. That is, the department can determine how large the service will be and the space to expand is available when the department is ready. From the above first, Watson has API integration where developers can integrate some of the Watson capabilities into business applications [21,22]

Besides, there are also features that can help users with automation. The feature is called Watson Orchestrate. Its main area of expertise is automating workers' procedures and repetitive tasks via open APIs and robotics process automation connectivity [22]. With this feature, the workers at the healthcare department can focus on tasks that do not require any automations and can be less stressful in the healthcare industry. Lastly, the functionality of Watson Assistant is to help any department create smarter virtual agents to provide precise answers fast throughout applications, websites and devices, from customer service to internal IT help desks and human resource departments. Conversational AI allows consistent and intelligent customer service throughout all touchpoints and channels. Lastly, Watson Code Assistant assists the department's software developers for their future or recent developments for their system, with the AI-driven suggestions feature of IBM's Artificial Intelligence, Code Assistant broadens the scope of IT automation throughout the company as a strategic, democratized asset to all, and not just subject-matter experts[14,15].

2. Literature Review

Cognitive computing platforms have increasingly been embraced in healthcare to advance clinical decision support, data management, and patient activation. IBM Watson and Microsoft Azure are two leading platforms offering AI-based capabilities among others. The critique methodically evaluates the strengths and weaknesses of the platforms within a hospital context based on peer-reviewed literature, technical reports, and market studies[16,17,18].

IBM Watson has demonstrated outstanding capability for handling large volumes of structured and unstructured medical data. Its advanced Natural Language Processing (NLP) enables it to gain insights from clinical documents, research articles, and sensor data, contributing to faster and more accurate decision-making. Clinicians are able to quickly address patients' needs and shifting medical trends using these features. Watson's training is supported by extensive datasets, including clinical trials and case studies, reducing model bias and enhancing generalizability across populations (Brain & Webb, 1999). Unlike specialized AI solutions, Watson offers integration among diagnostic, treatment, and administrative systems, enabling interoperability and optimizing operations [19,20]

Its hybrid architecture—blending machine learning, deep learning, and rule-based algorithms—enables Watson to be reactive to medical data fluctuations [21,22,23,24]. Watson's user-friendly interface has also been praised for reducing the technological gap for clinicians [23]. Transparency and traceability in Watson's decision-making also add to its credibility, consistent with regulatory standards. The stability of IBM Watson is underpinned by success in non-healthcare fields such as finance and customer service indicating its maturity and flexibility [24,25,26].

Despite its technological promise, IBM Watson has experienced severe implementation problems. Excessive development and maintenance costs of the system have hindered its more extensive adoption. Financial strain led to the reduction of the Watson Health division and the divestiture of assets to third-party organizations. Furthermore, concerns over data privacy and exploitation of sensitive health information have made healthcare providers tread carefully in adopting Watson [27,28,29,30]. A major limitation is also the inability of Watson to handle complex unstructured clinical information. The use of artificial training data initially limited the system's ability to interpret real-world clinical subtleties, leading to compromised treatment recommendations [31,32].

Microsoft Azure has widely been praised for its scalable, compliant, and secure cloud infrastructure specifically optimized for healthcare environments. Azure Health Data Services support interoperability standards like FHIR and DICOM, which enable smooth integration of a variety of data sources like imaging, clinical, and sensor data [34,35]. This allows clinicians to have full, real-time assessments of patient health.

Azure also offers a targeted AI-driven chatbot—Azure Health Bot—which helps in triage, tracking of chronic illness, and tracking of vaccinations [36,37,38]. The system includes de-identification features built-in for Protected Health Information (PHI), which ensures compliance with privacy legislation such as HIPAA and GDPR [38]. With its analytics features (e.g., Synapse Analytics, Microsoft Fabric), Azure offers advanced processing of data, which helps in predictive analytics, clinical documentation, and care optimization [39]. Azure Health Bot facilitates live interaction with patients via NLP-enabled chat interfaces, which optimizes the efficiency of common medical inquiries (Heyduk, 2020). Microsoft's geographical reach and continuous service updates also ensure that the platform is updated to reflect current clinical practice [40].

The platform's multi-domain support and HL7 FHIR support of the platform make it flexible across various healthcare applications like telemedicine and hospital management systems [39]. The interface is intuitive for both clinicians and patients, and thus its adoption is feasible even among less tech-savvy users [40]. The explainability of Azure in chatbot rationale, as well as Microsoft's track record in software reliability, makes it a platform that can be trusted within clinical environments [41].

Despite its functionalities, Azure is challenging in terms of a steep learning curve due to its broad range of services. Organizations that have fewer technical staff may struggle to fully utilize the platform. Its complex pricing model, with separate charges for compute, storage, and data transfer, complicates budgeting and can lead to unexpected expenses (Spot by NetApp, n.d.). Vendor lock-in is another concern, as reliance on Azure-specific services may render migration to other platforms more challenging [42]. Additionally, occasional outages—although rare—can lead to mission-critical services being suspended. Azure's limited configurability can also pose challenges for healthcare organizations requiring highly tailored solutions [43].

3. Methodology

This study adopts a comparative qualitative methodology to investigate the cognitive integration of IBM Watson and Microsoft Azure within healthcare systems, and specifically in relation to traditional HIMS platforms such as Meditech. The study is in the format of a systematic literature review combined with architectural analysis and a proposed system design.

3.1. Comparative Literature Review

The study began with a wide comparative literature review to evaluate the potential of IBM Watson and Microsoft Azure in healthcare. This compared their features, strengths, and weaknesses. It was based on a variety of reliable sources such as peer-reviewed journals, whitepapers, and technical reports published by IBM and Microsoft[44,45,46]. Also, actual case studies were researched to discover the actual uses and challenges presented in implementing such cognitive systems within hospitals. Such a literature review served as the foundation for identification of gaps existing in present Hospital Information Management Systems (HIMS) and drove the development of the proposed hybrid solution.

3.2. System Architecture Evaluation

The existing hospital system architectures, as in the case of Meditech, were analyzed exhaustively to determine key limitations in scalability, interoperability, real-time analytics, and integration capabilities. The analysis revealed that traditional HIMS are founded on legacy technologies and lack the agility needed for the provision of modern healthcare. The systems were contrasted with the cognitive capabilities of IBM Watson and Microsoft Azure using architectural diagrams. This served to underscore the way that cognitive solutions would be able to solve inefficiencies in existing systems through predictive analytics[47,48], automation, and the free flow of data between departments and platforms.

3.3. Proposed System Design

Following the architectural review, the hybrid system architecture was proposed to leverage the strengths of both IBM Watson and Microsoft Azure. The system architecture integrates Watson's advanced artificial intelligence and natural language processing (NLP) for clinical decision support and analysis with Azure's secure, scalable cloud infrastructure and data interoperability features. The system envisioned here is structured into three broad layers: a user interface top layer for user interaction through dashboards and devices; a middle layer for cognitive processing and AI analytics; and a bottom layer to hold data and protect the system[49,50]. Design elements include anonymization of data, compliance with HIPAA and GDPR standards, and role-based access controls to ensure privacy and accountability.

3.4. Cost Analysis and Implementation Plan

To achieve feasibility, the expenses were executed in minute detail encompassing infrastructure, API integration, coding software, training personnel, and sustaining operations—illustrated in Malaysian Ringgit (MYR) based on prevailing exchange rates. Development and deployment were organized into four distinct phases as can be visualized through a Gantt chart. The phases include starting the project and system designing, coding the system, testing and deployment, and finally training and maintenance in the long term. This structured format provides the correct direction for how to carry out the hybrid cognitive HIMS and ensures that critical resources and timelines are adequately allocated.

4. Comparative Table of IBM Watson VS Microsoft Azure

4.1. System Architecture Design

This section of the paper will analyze a current system implemented by hospitals and provide suggestions on a more efficient system architecture that leverages cognitive systems to provide better outcomes.

Table 1. Comparison Analysis of IBM Watson and Microsoft Azure.

Comparative Topics	IBM Watson	Microsoft Azure
Features	- Watsonx Assistant AI healthcare chatbot. - Cloud-based system. - Provides API for Automation. - Adaptability across applications.	- Interoperability and Data Integration - Azure Health Bot - Privacy and Compliance - Data Analytics and AI
Benefits	- Filter though structured data. - Huge training data. - Provides system integration. - Machine Learning, Deep Learning and traditional rule-based systems. - User-friendly interface. - Accessible to multiple demographics. - Transparent, traceable and explainable responses. - Lengthy track record in business, sales and customer relations.	- Handle numerous simple processes. - NLP models help communicate with patients in real-time. - Offers constant updates and enhancements. - Multi-domain integration opportunities. - User-friendly interface - Unified data exchange in different departments. - Provides reasoning behind output. - Experienced with healthcare. - Compliance with security requirements.
Limitations	- Slow to catch up with technological enhancements. - High cost for development and maintenance. - Require significant resources. - Healthcare providers were hesitant to adopt Watson in fear of privacy violation and data exploitation. - Unable to process unstructured data accurately.	- Learning curve and intricacy. - Pay-as-you-go pricing model. - Vendor locked. - Occasional outages. - Customisation constraints.

Table 1. Comparison Analysis of IBM Watson and Microsoft Azure.

Comparative Topics	IBM Watson	Microsoft Azure
Features	- Watsonx Assistant AI healthcare chatbot. - Cloud-based system. - Provides API for Automation. - Adaptability across applications.	- Interoperability and Data Integration - Azure Health Bot - Privacy and Compliance - Data Analytics and AI
Benefits	- Filter though structured data. - Huge training data. - Provides system integration. - Machine Learning, Deep Learning and traditional rule-based systems. - User-friendly interface. - Accessible to multiple demographics. - Transparent, traceable and explainable responses. - Lengthy track record in business, sales and customer relations.	- Handle numerous simple processes. - NLP models help communicate with patients in real-time. - Offers constant updates and enhancements. - Multi-domain integration opportunities. - User-friendly interface - Unified data exchange in different departments. - Provides reasoning behind output. - Experienced with healthcare. - Compliance with security requirements.
Limitations	- Slow to catch up with technological enhancements. - High cost for development and maintenance. - Require significant resources. - Healthcare providers were hesitant to adopt Watson in fear of privacy violation and data exploitation. - Unable to process unstructured data accurately.	- Learning curve and intricacy. - Pay-as-you-go pricing model. - Vendor locked. - Occasional outages. - Customisation constraints.

4.2. Current Hospital Information Management System Architecture

Most conventional hospitals still use the current centralized Hospital Information Management System (HIMS) architecture, which relies on legacy technologies. A relational database forms the basis for storing scheduling, billing, diagnostic data, and patient records. Such databases are transaction-optimized as opposed to real-time analysis, typically built using SQL. Data is available only to specific terminals on the hospital network and is manually entered by staff or migrated from standalone systems. While reliable, this centralized system could be a handicap with the heightened need for scalability and real-time information.

Figure 1. Types of Legacy Healthcare Systems.

Figure 1. Types of Legacy Healthcare Systems.

The system usually has separate modules for various services like patient registration, appointment management, laboratory results, pharmacy, and billing. Since there is no rigorous integration of these modules, employees might have to input the same information in separate systems, leading to inefficiencies and the increased possibility of errors. HL7 standards are shared interfaces that enable the modules to speak to each other and provide for minimum data sharing. However, current demands such as telemedicine, remote patient monitoring, and mobile health apps cannot be met due to the fact that it is inflexible.

Besides, there is minimal support for interoperability with other insurance companies, healthcare organizations, or analytics systems. Reporting and analytics applications capable of deriving meaningful insights from data are undermined by generally static and template-dependent tools. Security measures that only use role-based access controls and basic user authentication may lag behind existing cyber threat protection standards. Therefore, the necessity of free data exchange and greater patient loads are putting pressure on existing HIMS, and hence there is a trend towards more sophisticated and integrated ones.

With centralized databases and independent modules for central services like patient registration, billing, and diagnostics, traditional Hospital Information Management System (HIMS) architectures supply a paradigm for handling critical hospital operations. They are constrained by their low scalability, inadequate data integration, and lack of ability to interoperate, yet offer reliability and fundamental functionality. The systems fallacy is apparent as the healthcare industry evolves in keeping with increasing demand for real-time access to information, sound analytics, and full compatibility with emerging technologies. To address contemporary and future challenges, hospitals must advance more durable, adaptable, and compatible systems capable of adjusting to the evolving requirements of modern health care delivery.

4.2. Meditech

Meditech is a Hospital Information Management System (HIMS) system used in the healthcare industry that is used to store patient data, conduct clinical processes, and monitor administrative processes. Meditech controls structured information in one relational database. Many of the features of the system can be leveraged by hospitals for registration of patients, lab operations, pharmaceutical services, and financial processing owing to Meditech's modular design. Still, since these modules often operate independently of one another, data has to be entered manually across systems, resulting in errors and inefficiencies. Though it may utilize standardized protocols such as HL7 for finite data exchange, the primary emphasis lies in transactional processes, without the capabilities of real-time analytics and advanced decision-support (Medical Information Technology Inc, n.d.).

While Meditech is reliable for mission-critical operational requirements, it puts into perspective the limitations of legacy HIMS systems. Its fixed reporting capabilities rely on pre-designed templates, limiting the flexibility to support sophisticated analytics or forecasting models. Moreover, interoperability issues resulting from historical implementations make it even more challenging to integrate external systems, such as sophisticated patient engagement solutions or telemedicine systems. Though more recent Meditech systems have begun to incorporate cloud-based capabilities and sophisticated user interfaces, the majority of hospitals currently use outdated Meditech systems with no sophisticated capabilities like machine learning and cognitive technology. As such, they lack the ability to effectively handle the growing demand for personalized care, real-time information access, and sophisticated medical analysis (Medical Information Technology Inc, n.d.).

4.2. IBM Watson Architecture Design

The layout below displays the architectural diagram of IBM Watson on the business intelligence and predictive analysis layer.

Figure 2. IBM Watson Architecture Design.

Figure 2. IBM Watson Architecture Design.

Architecture consists of three components that comprise domain specialization, cognitive services and reporting component. Domain specialization specializes in the system for a specific industry or task. Models are specialized algorithms or constructs for the domain. Annotations are the tags or metadata that are added to enhance data for relevance. Content is the actual domain specific data that the system operates on, in contrast.

The next section discusses the cognitive services provided by IBM Watson Analytics. There are 4 components in this section namely perceiving engine, reasoning engine, relating engine and learning engine. These services together make it possible for IBM Watson to work as an AI and machine learning tool.

Finally, IBM Watson Analytics will create a report of whatever it has analyzed. It will also provide a key performance indicator (KPI) to show its efficiency in performing a certain task. It also possesses predictive capability based on its cognitive performance to study and learn from its sets of data.

4.3. Microsoft Azure Architecture Design

The architecture design depicts the architectural design of the Microsoft Health Bot service used solely for healthcare digital solutions. The architecture consists of a number of key components: Clients, Messaging Pipelines, the Organized and Law-Abiding Healthcare Bot Service Customer, the Integrated Healthcare Intelligence, Cognitive Services, Customer Backend & Electronic Medical Record or EMR, the Healthcare Bot Control Console, and assistance from Customer's Administrators, Coders and Conversation Architects. The adaptive graded table is actually the core part and each of these sub-facets plays a specific role in the efficient running of the healthcare bot (Heyduk, A. 2020).

The End Users are the patients or consumers of the Health Bot system, seeking information on health, to confirm symptoms, or decide which physician to consult. The bot itself talks directly to these users' health concerns first as the initial channel of communication.

Conversation Channels are the most top-level interfaces that connect the End Users and the backend representation of the bot. They comprise smart phone, PC, smart speaker and instant messaging application through which the bot can be accessed from any device since it offers an extra versatility of how the individuals interact with the bot.

The core component of this infrastructure is the Dedicated and Compliant Healthcare Bot Service Tenant that acts as a dedicated cloud platform of healthcare providers for Microsoft Azure. This guarantee dealing with data is in accordance with healthcare legislation like HI USA's HIPAA that protects dealing with identity related health information. Under this tenant is the Built-in Healthcare AI that adds targeted healthcare components to the features of the bot. The module has the following; Credible Triage Protocols to help guide the user on how to report symptoms, Medical Content for delivering standardized and quality health information, NLP for Healthcare to process medical expressions, and Compliance Construct & DSR to deliver data security and compliance. Taken as a whole, the characteristics allow the bot to respond to healthcare related questions with the appropriate information.

Cognitive Services further upgrade the bot's interaction behavior using Microsoft real-time cloud services with speech and language processing labels. Of course, cognitive services increase the bot's capability to understand the inputs received from a user – thus ensuring conversations become smoother and more fluent.

The Healthcare Bot Management Portal is an administrative interface by which healthcare professionals are able to install and configure the bot. Through this manner, administrators and developers together with conversation designers can craft various scenarios, specify links, and observe the performance of the bot so that the organization may place the bot's response better in the context of the organization’s health-related objectives.

Backing up the back-end, Tenant Backend & EMR (Electronic Medical Record) makes patients' electronic records available. With FHIR, the bot can interact with EMRs and can aid in appointment scheduling, results and health advice alerts.

The cognitive architecture maintains secure interaction via APIs among different parts. End-user interaction with the bot is implemented via devices such as the mobile phones and the desktop via secure APIs that probably implement encryption while transferring data thereby protecting them in case of any attack. It runs within a compliant and distinct service tenant in order to separate health care information from the everyday mishaps and stay compliant with regulations such as HIPAA (Health Insurance Portability and Accountability Act). APIs associated with the Tenant Backend and Electronic Medical Records (EMR) are secured using the right authentication protocols so that all the medical information flowing through them is safe.

Interoperability with intelligence services like NLP for medical care is heavily dependent on API security levels to ensure interaction with medical data and triage activities to be secure from data exposure. The APIs also allow it to have constrained use of medical AI features like compliance constructs and triage procedures. Also, the Tenant admin, developer and conversation designer used Healthcare Bot Management Portal can be accessed by only using the RBAC. APIs in the portal keep secure communication with backend and dynamically change the bot. The architecture also comprises Compliance constructs and Data Subject Rights (DSR) to manage the rules of health care. Request handling APIs related to Compliance for patient data deletion or access contain inherent strong security controls to safeguard patient's rights as well as data security. Lastly, Tenant Admins, Developers and Conversation Designers are involved in deploying, managing and defining Healthcare Bot capabilities through the Healthcare Bot Management Portal. They make the bot's responses official, increase the rent and healthcare scenarios, maintain the functional integrity of the bot, and have legal and organizational adherence to healthcare facilities.

Health Bot cycle initiates at End Users that initiate it through Conversation Channels. All this information then flows to the Healthcare Bot service tenant and the in-built care AI capabilities empowered with functionalities for triage, content, and NLP (Natural Language Processing). Cognitive Services enhance this interaction by building blocks of natural conversation based on improved dependency on language and speech. The app can securely and effectively access and use patient information by interacting with the Tenant Backend & EMR. Hence, it responds to issues that concern health facility support. The control and adjustment of the processes the bot performs is up to the developers, admins, and designers that handle the process via the bot's administrative area in a way that meets organizational and regulatory requirement.

4.2. Data Storage Design

Figure 3 above is the data storage architecture that is predominantly used in the cloud infrastructure. The flow of this architecture is from the users which are using multiple types of devices, for example, mobile phones, laptops, and desktops. Data flow will be triggered when devices will be connected to the internet where cloud is, in this architecture connection will be established by Cloud Service Provider and having an account with security profile, the security message flow can be set up and monitored to give control access based on identity that is linked with the message (IBM, 2023a). Apart from that, all the security message flow will be sent to the Cloud Storage Servers and it is receivable by the server along with the users. Additionally, an optional third-party auditor can be involved in monitoring the security message flow from the users to the server received, the reason why a third-party auditor can be involved is that it is present to be utilized as the quality management system which is to have a company's set of requirements must be met (Hammar, 2015).

4.2. System Proposal

IBM Watson and Microsoft Azure are the systems selected due to their efficiency in the industry. Despite both systems having weaknesses, both systems have utilized proper cognitive services to function within the industry. Architectural diagrams of both systems as well as proposing a new system architecture that can address the weaknesses of the aforementioned hospital information management systems will be compared within this section.

IBM Watson Architecture for HIMS

Traditional HMS concentrate on performing operational and administrative functions like scheduling, billing, regulatory filings, and keeping patient records. Though they perform well with maintaining structured data in place, they are poor with knowing and developing knowledge from unstructured data, i.e., image reports or physicians' notes. Clinical decision-making is usually slow and inefficient because of these constraints, which force existing HMS to rely on manual data retrieval and lack user-friendly search functionality. Moreover, they offer no support for proactive patient engagement, resource optimization, or diagnostics, forcing medical personnel to rely heavily on their experience without direct assistance from predictive insights.

These systems are restricted to rudimentary security controls such as encryption and access controls and lack advanced data protection features such as predictive threat detection since they lack cognitive abilities. Because these systems cannot forecast patient volumes or staff requirements or maximize resource allocation, the lack of analytics and decision support tools impacts operational efficiency. Hospitals can shift from reactive to proactive healthcare management by leveraging cognitive technologies, allowing them to harness real-time analytics, improve diagnostic support, improve patient engagement, and streamline processes through the optimization of resources based on predictive insights.

IBM Watson's health application architecture is capable of consuming, analyzing, and producing insights from healthcare information using a series of main components. The Data Ingestion Layer consumes patient data from various sources such as electronic health records (EHR), imaging diagnostics, laboratory tests, and wearable sensors. This information is then analyzed using Watson's Natural Language Processing (NLP) capability, which extracts meaningful information from unstructured data such as doctors' notes, medical transcripts, and patient feedback. Watson's Machine Learning Models are optimized for applications such as clinical decision support, predictive analytics, and medical image analysis, thereby increasing the accuracy of diagnostics and personalized therapy recommendations.

• Microsoft Azure Architecture for HIMS

With a variety of specialized parts, Microsoft Azure's health platform offers scalable, cloud-based architecture to facilitate integration, analysis, and sharing of health information. With Data Integration & Storage in Azure Data Lake, store centrally data from medical sources such as lab systems, EHRs, and Internet of Things health devices. For the support of healthcare professionals, Microsoft Azure's Cognitive Services in particular, Text Analytics for Health, cleans raw data and extracts relevant information from clinical notes.

• Suggested Design for a Better HIMS

Microsoft Azure's strong data storage, interoperability, and scalability features are combined with IBM Watson's advanced natural language processing (NLP) and diagnostic capabilities in the suggested architecture of an improved Hospital Information Management System (HIMS). The architecture promotes diagnostic accuracy by combining these two platforms and subjecting unstructured clinical notes and patient comments to IBM Watson's natural language processing (NLP) for analysis. In the meantime, Microsoft Azure solves the problem of unifying data from various sources by offering secure, scalable storage and FHIR-based APIs to facilitate seamless interoperability of healthcare systems. With this dual configuration, the hospitals would be able to leverage the infrastructure of Azure for effective data management and healthcare data standards compliance and IBM Watson's dedicated analytics for clinical decision support.

• Proposed SystemArchitecture

The proposed system Architecture is comprised of 4 major layers like the Top Layer which interfaces with users, the Middle Layer which deals with data processing with IBM Watson and Microsoft Azure, the lowest layer which provides data storage and finally the security layer which offers data reliability and protection.

Figure 5. Proposed Simplified System Architecture.

Figure 5. Proposed Simplified System Architecture.

• TopLayer

The top layer of the architecture includes the dashboards and the data sources, this allows fast live data review for the users.

Figure 6. Top Layer of System Architecture.

Figure 6. Top Layer of System Architecture.

The system can be accessed using any network device. Different users can make use of different interfaces like the medical practitioner, visitors and patients. A medical practitioner can include nurses, surgeons, doctors, lab scientists and other medical professionals. For the patients, it includes the already hospitalized patients as well as the already home-treated patients by a professional medical nurse. The visitors include possible stakeholders who are investing in the medical institute, visitors who are wishing to see a patient and visitors who wish to book a consultation with a physician.

Due to the good design, laboratory researchers can provide the laboratory results to the doctors and patients immediately after the test has been carried out in an effort to minimize waiting time. This allows the patients to understand their condition more and provides the doctors with more information to make decisions with.

Input data to the system are medical equipment such as magnetic resonance imaging (MRI), X-ray, wearable devices and equipment that track a patient's vital signs. In addition, other input data sources available on the Internet such as weather conditions, humidity level and temperature levels can make the system predict the onset of a disease based on the current situation in the world. For example, a devastating storm could predict a great chance of a fever from historical patterns. In addition, geographic data help track the spread of some diseases over a period and help hospitals make proper decisions while buying drugs or providing promotion of some treatment to provide quality services to the population.

• Middle Layer

Data will be transferred between both Artificial Intelligence systems to provide security of data and a better analysis of the data without biasness.

Figure 7. Data flow for Cognitive Systems.

Figure 7. Data flow for Cognitive Systems.

When IBM Watson will request necessary information from Microsoft Azure. Microsoft Azure will track all the data sources and collect information to be fed to IBM Watson. Microsoft Azure will anonymize by stripping away any personally identifiable information (PII) from the data before sending the data for processing. IBM Watson will then cross-match the data and forecast based on past incidents cross-matched with current real-time information from data sources. With model training in IBM Watson, the system is able to make sound forecasts on symptoms and other hospital management information such as expected number of patients for the day or the likely number of available beds/rooms by the end of the day. These predictions can help the patients, as well as the doctors, to make better information-based decisions.

If the user enters the user interface and they wish to see live vitals, one can derive the data from the source of the data. But if the user wishes to analyze the data, they can get real time analysis and predictive analysis about their health, along with health feedback through a chatbot through Natural.

Figure 8. Work delegation for IBM Watson and Microsoft Azure.

Figure 8. Work delegation for IBM Watson and Microsoft Azure.

The figure provides the allocation of the task assignment of the cognitive systems to create an automated system using the AI tools and APIs of IBM Watson and Microsoft Azure. IBM Watson shall be used in the majority of model training and generation. It shall provide the corpora of the system, using taxonomies and ontologies to define diseases and symptoms. IBM Watson Analytics also provides modules like perceiving engine, reasoning engine, relating engine and learning engine which can provide analytics services to the system. IBM Watson's NLP algorithm will allow it to communicate information to the users, which shall act as the frontend of the entire system.

On the other hand, Microsoft Azure works behind the scenes of the system by merging data, managing data storage and security. Due to the common use of Microsoft Azure, it knows how to properly structure data from different data sources. In addition, making the system read patient information that is sensitive is not a major risk since the system's enhanced security. System updates provided by Microsoft allow Azure to defend against emerging cyber attacks in order to keep the patient data safe. Microsoft Azure will also be used in an attempt to further fortify the system by keeping watch on server behavior in an attempt to stop intruders from collecting personal details.

The following table distinguishes the roles of the systems:

Table 2. Roles of IBM Watson and Microsoft Azure.

Component	Microsoft Azure	IBM Watson
Primary Role	Data Management, Data Integration and Data Security.	AI-driven Analytics, Predictions, Natural Language Processing (NLP).
Data Handling	Collects, organises, and securely stores data from data Sources.	Processes anonymised data received from Microsoft Azure for analysis and prediction.
Anonymisation	Removes sensitive patient information before sending it to IBM Watson.	Operates only on anonymised data and has no access to personally identifiable information (PII).
Security	Implements encryption, access controls, firewalls and intrusion detection.	Relies on Microsoft Azure;s anonymised data for secure operations.
Predictive Analytics	Supports IBM Watson by managing the data for	Performs trend analysis, generates diagnostic
	analysis.	suggestions and predicts health outcomes.
Model Training	Not involved.	Continuously trains and improves models using filtered real-time data.
Chatbot Integration	Supports IBM Watson by managing the data for chatbot operations.	Powers the chatbot with its NLP algorithm for booking, symptoms checking and general inquiries.
Real-Time Data	Supplies live, filtered data from sensors and devices to the dashboard.	Analyses live data to provide actionable insights and predictions to the dashboard.
Dashboard Interaction	Feeds real-time data directly to the dashboard for user interactions.	Provides analytics and chatbot responses to the dashboard for user interaction.
Adaptability	Uses AI to find patterns in data formatting and security logs.	Adapts models based on new medical data to improve accuracy and performance.

Table 2. Roles of IBM Watson and Microsoft Azure.

Component	Microsoft Azure	IBM Watson
Primary Role	Data Management, Data Integration and Data Security.	AI-driven Analytics, Predictions, Natural Language Processing (NLP).
Data Handling	Collects, organises, and securely stores data from data Sources.	Processes anonymised data received from Microsoft Azure for analysis and prediction.
Anonymisation	Removes sensitive patient information before sending it to IBM Watson.	Operates only on anonymised data and has no access to personally identifiable information (PII).
Security	Implements encryption, access controls, firewalls and intrusion detection.	Relies on Microsoft Azure;s anonymised data for secure operations.
Predictive Analytics	Supports IBM Watson by managing the data for	Performs trend analysis, generates diagnostic
	analysis.	suggestions and predicts health outcomes.
Model Training	Not involved.	Continuously trains and improves models using filtered real-time data.
Chatbot Integration	Supports IBM Watson by managing the data for chatbot operations.	Powers the chatbot with its NLP algorithm for booking, symptoms checking and general inquiries.
Real-Time Data	Supplies live, filtered data from sensors and devices to the dashboard.	Analyses live data to provide actionable insights and predictions to the dashboard.
Dashboard Interaction	Feeds real-time data directly to the dashboard for user interactions.	Provides analytics and chatbot responses to the dashboard for user interaction.
Adaptability	Uses AI to find patterns in data formatting and security logs.	Adapts models based on new medical data to improve accuracy and performance.

Finally, the storage system is advised to incorporate a cloud-based storage system to provide data size and traffic flexibility. Cloud based storage systems can provide high availability to data, data reliability that guarantees compliance with regulatory needs, flexibility and scalability to manage different requirements with less effort and cost, and maintainability to be a solid data storage architecture (Tahir et al., 2020).

Figure 9. Overall System Architecture.

Figure 9. Overall System Architecture.

In summary, the overall system architecture can be shown as above. The green arrows demonstrate the connectivity and flow of data that allows the system to work flawlessly.

• Bottom Layer

The infrastructure proposed is an integrated, scalable, and secure cloud-based system for cognitive computing and healthcare data processing. Microsoft Azure Virtual Machines are used to provide reliable computing capacity, with AWS cloud servers performing lightweight event-driven tasks to provide multi-cloud flexibility and redundancy. Azure, IBM, and AWS are utilizing data integration and governance solutions to improve data management and security.

• Proposed System Validation

This system addresses all the diagnostic objectives of all hospitals by integrating cognitive systems, providing accurate diagnostics, attractive interfaces, automatic processing, patient safety, and enhancing decision-making in hospitals. The solution is a combination of IBM Watson's cognitive analytics with Microsoft Azure's cloud-based scalable services to enhance the accuracy of hospital diagnoses. It offers accurate diagnostic predictions and insights from a variety of sources and facilitates real-time predictive analytics. The technology improves decision-making with actionable insights. The user-friendly interface includes user-specific dashboards for different sets of users, and patient information remains secure with Azure's strong security features. Repetitive jobs are automated, removing the workload from healthcare personnel, resulting in enhanced productivity. With such cutting-edge technology, hospitals would be able to effectively tackle current and future healthcare challenges.

5. Implementation Plan and Challenges

The article details the roll-out in a structured manner of a Hospital Information Management System (HIMS) that combines IBM Watson and Microsoft Azure's cognitive capabilities, determining development stage, anticipated challenges, fallback strategies, and cost estimate.

5.2. Implementation Plan

The system development will need a formatted timeline to indicate and lead the group of employers how the development will be conducted. In this implementation plan, a Gantt Chart is used to indicate the tasks and how long the task needs to be completed. There are also different phases of the development which will be highlighted in the project and as the employers are implementing the Gantt Chart, it can be stated that the formation of the chart is such that it is a waterfall.

Figure 10. Gantt Chart for system deployment.

Figure 10. Gantt Chart for system deployment.

Gantt Chart is very effective when applied to represent the task which desires to be achieved in that particular time. For example, in the first phase of the project, a lot of planning and development will be done in that phase because it is the first part of the system development, and also the longest part because most of the visualization will be done in this phase too. Besides, as the development has moved to the next level, the flow will decrease slowly as an indication that the project has been going smoothly since all of the objectives and deadlines have been fulfilled in the process of working on the project.

The phases covered in the hospital system development as mentioned in the Gantt Chart are:

Phase 1: Project Initiation, Requirement Analysis and System Design. The majority of the planning, designing, and requirements needed will be placed here.

Phase 2: Development. Here is where the system will be developed once it has been completed from the project initiation. Some of the activities that will be performed here will include Cognitive System Development, Frontend Development, and Backend Development.

Phase 3: Deployment and Testing. In this phase, the system should be fully complete in order to be tested in another department environment and any bugs or errors should be corrected so as to carry out any changes before the deployment of the system. Once the deployment is done, the system developers should oversee everything concerning the system, for example, Quality Deliverables and Project Performance Tracking.

Phase 4: Training & Support, Maintenance, and Project Close & Further Maintenance. This is the last couple of phases that are reserved for giving a briefing to the department employees on how the new system will function. Additionally, this phase is also for the system developers to maintain the system throughout the operational duration of the department, and it is for closing the project and ensuring that the system will work efficiently by developing plans that can further enable the system to be more flexible in the future.

• Challenges and Contingency Plan

Adopting a new system in an organization is full of challenges most of the time. The challenges impact day-to-day operations and productivity if not addressed as early as possible. Lack of expertise and system downtime are some of the challenges. Data migration is also one of them.

• Data Migration

This challenge arises subsequently to the introduction of the new system. The risks involved could lead to loss of data or even data corruption in already saved files. This, in addition to the challenges while operating on legacy systems with unsupported data formats, worsens the situation. Ineffective performance of the process may lead to further problems such as delays or lack of complete data that would significantly affect day-to-day operations.

This can be handled by making backups of the data before one starts the process of migration. If something is wrong while migrating, the company can recover. Additionally, the company should carry out data profiling before it can start the process of migrating the data so that only important data is migrated. This will also eliminate data anomalies which will also help in having correct, complete and consistent data. Besides, such methods can create higher data quality in the new system.

• Lack of Expertise

In introducing any new system, it is necessary to make the users of the system familiar with its functioning. Any system that is introduced will need technical know-how and experience. If this experience is lacking in the employees, the company will need to rely on costly outside experts. Worst of all, they will implement the system wrongly which can result in errors. One of the solutions to this issue would be to include staff training. Training the staff in the system functionality would be necessary for the system to function well in the organization. Furthermore, the system developers can design a document that will act as a guide to the system. This will ensure that the organization would not have to employ expensive consultants to use their system.

• System Downtime

System downtime while deployment can interrupt critical operations. An example of interruption in critical operation is a delay in patient care. Hospitals must operate round the clock to treat patients since hospitals must continually dispense prescriptions and react to a change in a patient's condition. Also, a system downtime will put the staffs' work more difficult to cope with the situation which will result in less productivity. Also, this problem would lead to loss of revenue as hospitals wouldn't be able to process insurances or service charges.

To resolve the system downtime, the company would have to perform phased deployment which will reduce the impacts on operations. This is to deploy pieces or phases of the new system slowly into the existing system. Secondly, the company should perform a planned downtime where the developers would have to estimate traffic and then schedule deployment when there is the least traffic. Additionally, the business would have to provide one week's prior notice of the downtime to allow employees to make preparations for it. This will reduce business disruption as well as increase employees' resilience.

• Cost Analysis

A comprehensive cost analysis was made to determine an approximate overall cost of the system being proposed, both from development and post-deployment viewpoints. All the costs were translated with respect to the exchange rate of 1 USD = 4.46 MYR, valid at the date of writing.

During development, costs are categorized under infrastructure, API integration, implementation, security and compliance, customer support, and miscellaneous expenditure. Infrastructure costs include the deployment of Microsoft Azure Virtual Machines, AWS Lambda (as a Platform as a Service), Azure Blob Storage, and Microsoft Fabric. Five instances of Microsoft Azure's H8m virtual machine (with 8 cores, 112 GiB RAM, and 1000 GiB storage) were selected for the aim of achieving high computational efficiency for a price of $903.74 per instance per month, totaling RM 20,153.40. AWS Lambda was chosen for backend processing with the estimated requirement of 5 billion GB-seconds of compute, costing $75,000 or RM 334,500. For the storage of unstructured data, the Hot tier in Azure Blob Storage was chosen at 20 TB per month, costing $368.64 or RM 1,644.15. For structured data management, Microsoft Fabric's SKU F4 was chosen at a cost of $321.20 a month or RM 1,432.55.

API integration fees aim at IBM Watson and Microsoft Azure offerings. For processing 150,000 Natural Language Understanding (NLU) items using IBM Watson NLP API for $0.003 per item, the amount was calculated as $450 or RM 2,007.55. Apart from that, IBM Watsonx Assistant's Plus plan, priced at $140 a month (RM 624.40), was chosen for chatbot development, totaling four months at RM 2,497.60.

Implementation costs were calculated by manpower and training. 10 system integration engineers at RM 7,000 a month for four months total RM 280,000. 20 developers for RM 6,000 a month total RM 480,000 for system development. Five trainers at RM 4,000 a month were employed to train internally and cost RM 20,000. Security and compliance costs included the use of Microsoft Entra Suite and Entra ID P1 for 35 users at $630 per month or RM 11,239.20 for the development period. A base Azure VPN, used only in the last month, had a cost of $26.28 or RM 117.21. To ensure quality assurance, there was one software test engineer employed per month of RM 7,100, amounting to RM 21,300 for the development period.

Customer support expenses included IBM Watson and Microsoft Azure training sessions. The IBM Watson Discovery training of 10 engineers was RM 462 per person, amounting to RM 4,620. The Microsoft Azure AI training for 10 developers at RM 2,500 per person amounted to RM 25,000. Miscellaneous was RM 1,276 (RM 319 per month for four months), workspaces' rental for four private suites RM 1,500 per month each (RM 24,000), and operational supplies RM 1,000 per month (RM 4,000). An additional RM 10,000 for redundancy costs for unforeseen challenges.

Post-deployment costs involve monthly subscription rates, maintenance, man power, and other operations costs. Monthly subscription charges were kept for various services. H8m virtual machine on Azure was retained under a 1-Year Savings Plan costing $752.27 a month or RM 40,261.80 a year. AWS Lambda usage was increased to 10 billion GB-seconds of compute capacity, which amounted to $144,200 or RM 643,132 annually. Storage need was raised to 50 TB a month in Azure Blob's Hot tier costing $885.76 a month or RM 47,406 a year. Microsoft Fabric was updated to SKU F32, priced at $5,139.20 a month or RM275,049.96 annually, to address the escalation of structured data.

In addition, IBM Watson NLP API usage increased to 1,000,000 items per month at a cost of $1,500 or RM 80,280 annually. The IBM Watsonx Assistant Plus plan was still suitable at RM 624.40 monthly, which equated to RM 7,492.80 annually. The Microsoft Azure Health Bot still utilized the standard plan at $500 monthly (RM 2,230), and the annual cost was RM 26,760.

System maintenance was estimated at RM 10,000 annually for assistance in updates, patches, and performance enhancement. Manpower needs fell slightly at 10 developers at RM 6,000 a month (RM 60,000 a month) and five trainers at RM 4,000 a month (RM 20,000 a month), and hence an annual manpower cost of RM 960,000. Redundancy costing RM 60,000 per annum to accommodate failover systems, backup, and redundancy in infrastructure was then granted to back these facilities.

Figure 25. Network Bandwidth Price.

Figure 25. Network Bandwidth Price.

• System Maintenance Costs

System maintenance cost is really important to regularly update the system so that we ensure the system runs smoothly and securely. This cost includes software patches, security update and also the performance optimization. We have estimated and allocated a total of RM 10,000 annually, specifically for system maintenance.

• Manpower Costs

For the post-deployment phase, there will be slight adjustments happening to the numbers of employees. During this phase we will not require a system integration engineer. Besides that, we will be reducing the number of developers from 20 to 10 developers. The average salary of developers is RM 6,000 so the total monthly salary for the developers is RM 60,000. There will be 5 staff trainers working, so the total salary for them is RM 20,000 because the average salary for each of them is RM 4,000. Thus, the total monthly manpower cost is RM 80,000 which is RM 960,000 annually.

• Miscellaneous Costs

To ensure system reliability and to avoid any unnecessary downtime during the post-deployment phase, we have allocated a budget of redundancy cost. This covers the expenses of developing and maintaining failover solutions, backup systems, and extra resources to protect the infrastructure from unplanned outages. We have allocated a total amount of RM 5,000 per month or RM 60,000 a year, to make sure we are well prepared to handle any problem we might face in the future.

The annual cost after deployment will be as follows:

Table 4. Annual Post System Deployment Cost Breakdown.

Category	Details	Cost for 12 Months	Sources
Monthly Subscription Costs	Microsoft Azure Virtual Machines	RM 3,355.15	Source
	AWS Cloud-based Servers (PaaS)	RM 643,132	Source
	Azure Blob Storage	RM 47,406	Source
	Microsoft Fabric	RM 275,049.96	Source
	IBM Watson NLP APIs	RM 80,280	Source
	Watson Assistant for Chatbot	RM 7,492.80	Source
	Microsoft Azure Health Bot Services	RM 26,760	Source
	FHIR API	RM 7,163.16	Source
System Maintenance Costs	Regular updates for the system	RM 10,000	Source
Manpower Costs	Developers	RM 960,000	Source
	Staff Training		Source
Miscellaneous Costs	Redundancy Costs	RM 60,000	Source
Total	RM 2,120,639.07

Table 4. Annual Post System Deployment Cost Breakdown.

Category	Details	Cost for 12 Months	Sources
Monthly Subscription Costs	Microsoft Azure Virtual Machines	RM 3,355.15	Source
	AWS Cloud-based Servers (PaaS)	RM 643,132	Source
	Azure Blob Storage	RM 47,406	Source
	Microsoft Fabric	RM 275,049.96	Source
	IBM Watson NLP APIs	RM 80,280	Source
	Watson Assistant for Chatbot	RM 7,492.80	Source
	Microsoft Azure Health Bot Services	RM 26,760	Source
	FHIR API	RM 7,163.16	Source
System Maintenance Costs	Regular updates for the system	RM 10,000	Source
Manpower Costs	Developers	RM 960,000	Source
	Staff Training		Source
Miscellaneous Costs	Redundancy Costs	RM 60,000	Source
Total	RM 2,120,639.07

• Ethical and RegulatoryConsiderations

This chapter explores the ethics of implementing a cognitive system on Hospital Information Management Systems (HIMS) and its regulatory considerations when making diagnosis on a patient’s wellbeing using an artificially intelligent algorithm.

Data

ata Privacy and Transparency

Integrating AI into hospital diagnostics has the potential to improve accuracy, efficiency, and patient outcomes. However, it raises important ethical problems, notably around data privacy and security. Hospitals rely on large amounts of sensitive patient data to train AI systems, which increases the danger of breaches or unauthorised access. This raises concerns about the effectiveness of current data protection policies and whether they are adequate to secure sensitive health information. Furthermore, patient consent becomes an important issue because many people may not fully understand how their data will be used, raising questions about informed consent and data ownership. (FutureLearn. 2023). Sharing data with third-party AI providers, even if anonymized, may jeopardise patient confidentiality if proper measures are not in place.

Another significant moral and legal issue is transparency in AI decision-making. Since many AI models, particularly those built on intricate algorithms like deep learning, function as "black boxes," it might be challenging for medical practitioners to comprehend how particular diagnostic recommendations are produced. Trust difficulties may arise from this lack of interpretability, particularly if the AI produces biassed or inaccurate results. For example, an AI diagnosis system may disproportionately impact specific patient groups if it misidentifies symptoms as a result of biassed training data. (Corn, J,2024). To guarantee that patients and healthcare professionals can trust the technology, hospitals must implement explainable AI models that can offer concise explanations for their results (Barth.S,2023)

Regulatory frameworks for AI in healthcare are still growing, complicating the integration process. Many jurisdictions lack AI-specific rules, forcing hospitals to traverse a patchwork of guidelines that may fail to completely address the unique difficulties AI presents. For example, present medical device rules may fail to take into consideration the iterative and adaptive character of AI systems that evolve over time. Furthermore, liability worries arise when errors occur; establishing who is responsible, whether developers, healthcare professionals, or hospitals, can be legally difficult. Hospitals must maintain compliance with changing legislation and lobby for clear regulatory standards in order to create an organised path for AI adoption.

Ultimately, a multidisciplinary strategy combining technologists, ethicists, legislators, and medical practitioners is needed to address these issues. To protect patient data, hospitals must invest in cybersecurity and prioritise strong data governance procedures. To guarantee successful and moral integration, it is equally important to train healthcare professionals to comprehend and analyse AI outputs. Legislators should create thorough rules that strike a

balance between patient safety and innovation, including rules pertaining to liability, data security, and openness. Hospitals can fully utilise AI while upholding trust and making sure patient welfare always comes first by proactively addressing these ethical and legal issues. (Cordero.D,2023).

• Biases in DiagnosticAlgorithms

There are numerous clinical algorithms which are inherently faulty, either due to intentional prejudice in their design or because the algorithms were developed using biassed datasets, making it crucial to address algorithmic discrimination (Shachar and Gerke, 2023). As an example, if an algorithm is designed to distinguish between a fungal infection and a rash that was trained on mostly light-skinned individuals, the algorithm could misdiagnose patients with darker skin compared to the test set. The health algorithms have to cater to a multitude of populations from different cultures and locations, each with their distinct socio-economic characteristics and lifestyles and an AI model must account for this variety (Panch, Mattie and Atun, 2019). The disparity in data availability across all socio-economic categories could potentially lead to inadequate forecasts for under-represented populations. Algorithmic bias does not account for clinical contexts only. Biases in administrative context may include resource allocation such as workforce management, drug inventory management and bed management.

The sources of these biases could be grouped up into three categories including measurement errors, selection bias and feedback-loop bias (Hoffman and Podgurski, 2021).

Large datasets in the context of big data are used for training machine learning algorithms which may include absent or inaccurate data (Shah, Steyerberg and Kent, 2018). These measuring errors can be defined as the discrepancy between the actual measurement of interest and the measured value. These inadequate data quality can result in suboptimal AI algorithm performance, often articulated as the “garbage in, garbage out” (GIGO) concept. The Electronic Health Records (EHR) of minorities and economically disadvantaged individuals are susceptible to incomplete data owing to the issues such as lack of insurance, transportation barriers, childcare responsibilities, communication barriers, and insufficient access to any primary care providers. This discovery may result in AI models failing to identify illnesses or health hazards, hence impairing the provision of precise treatment (Hoffman and Podgurski, 2021). Marginalised groups, such as immigrants and those with poor socio-economic status, are more prone to get treatment in educational clinics that are more vulnerable to misclassification and measurement inaccuracies. Hence, the model could

inaccurately learn to provide poor treatment to patients of low socioeconomic backgrounds, influenced by implicit biases (Gianfrancesco et al., 2018).

Selection bias occurs when the training dataset is not representative of the overall population, leading to AI outcomes that lack generalisability, particularly due to the under-representation of disadvantaged groups (Hoffman and Podgurski, 2021). AI models that are designed to predict readmissions can be developed using under-inclusive datasets, which can be at a disadvantage for hospitals that serve low-income or non-white populations, as hospital performance is associated with these readmission rates (Joynt Maddox et al., 2019). The skewed demographic can lead to an uneven access to proper healthcare attention.

Lastly, a feedback-loop bias in AI-powered clinical decision systems reinforces historical discrimination, leading to errors affecting women, older adults, and minority ethnic groups, a situation aggravated by biassed datasets (Arslanian-Engoren, 2000). An example can be seen when there is an increase in government subsidies for healthcare. The presence of these subsidies will lead to an increase in the discovery of diseases and the number of cured patients compared to other times regardless of the existence of these diseases before the subsidiary. The AI model has to collect data from more than just internal sources in order to comprehend trends and identify prominent factors that affect the medical sector.

With the usage of Microsoft Azure to filter out data that could provide biasness, IBM Watson would be able to create a more representative model. Additionally, the system’s broad range of data sources allows it to understand the current world situation better to avoid feedback-loop biases.